Re: YAML 2.0: drop arbitrary nodes to be used as keys

On 3/2/16, Andrey Somov <[email protected]> wrote:
> On Wed, Mar 2, 2016 at 6:55 PM, Osamu TAKEUCHI <[email protected]> wrote:
>
> If someone has ever complained, that proves there is actually some
>> application
>> that uses the ability of YAML to store a hash with complex keys, isn't
>> it?
>>
>>
> You missed the whole idea of my argument against complex keys.
> Of course it is used by someone.
> But is should _not_ be used. Every project will find another solution.
> Community wins.

I too want YAML to be the best YAML, for serialization and for human
readability (and human writability).

I have been thinking about an actual use case (perhaps you can link to
a few of the "many issues" you say SnakeYaml users have faced... real
issues, rather than stated preference, can galvanize opinion):

I saw a graph many years ago, which was of countries, with debt on X
axis, some other national wealth indicator on Y axis, and each country
was a dot, with the size of the dot representing some third piece of
data. The country name was also displayed.

Of course, the application representing such a graph could "index"
with country name, or with point location pairs (x,y), or even with
just a specific value (just x, or just y, or just the third value -
the size of the dot). So there are a few options, superficially.

BUT, to -limit- the possible keys, could limit the optimal
representation format for the application - for example, there might
be more than one graph, with the same set of dots, but with alternate
sizes for some alternate piece of data, where the X and Y are the same
(the "natural" basis of the graph) - and so, disallowing point (x,y)
keys in the serialization format then imposes on the application doing
the serializing a need to work around that limitation, choosing a
"key" which is other than ideal, and/ or which may even introduce
undesirable characteristic - e.g. unnecessary data duplication (which,
if the data could be edited by humans, is definitely to be avoided,
and definitely more so with human data editing you want the "most
natural" representation/ serialization format, of that data).

Even hash maps and trees can be simulated or "simplified" to lists
(e.g. to "simplify the syntax") - even strings are just a list of
characters. The point is, to simplify, but to not over simplify for
the particular target use case. YAML has certain targets. JSON has
certain targets.

It may well be, that what you (and I and others) could really benefit
from is a JSON 2.0. I don't know for sure, just hypothesizing. I have
been somewhat disappointed over the years of the lack of widespread
adoption of YAML which I assumed for so long (and still assume, may be
naive) should happen - and then, the indignity of it all, this
pipsqueak upstart JSON leaps onto the scene and half the world gapes
in awe, like come on, that's ridiculous! So perhaps there is room for
something a bit different to either, although perhaps it's better to
call it JSON 2 or YAML 2.

Good luck all,
Zenaan

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140