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

The ONLY argument to keep complex keys:
I am alone, I do not exchange my YAML documents with anybody else. I know
what I do.

For this usecase we do not need YAML. Everyone is free to serialise to any
personal data format.
We only need to agree on a standard when we talk to each other.


>But then, as others have pointed out, how should people serialize objects
that include mappings with non-scalar keys?
Fail. With the message - radically improve your data structures.
Do exactly the same what JSON is doing. Simplicity rocks.

Cheers,
Andrey


On Wed, Mar 2, 2016 at 6:25 PM, Geoff Adams <[email protected]> wrote:

> But then, as others have pointed out, how should people serialize objects
> that include mappings with non-scalar keys?  YAML is an attractive
> serialization format to me because it is plain-text readable, and I can use
> it to store scientific data in a way that allows me to always be sure I can
> inspect my data by eye with a text editor even if something has gone badly
> wrong on the software side.  Arbitrary restrictions on what data can be
> serialized make the format less useful to me.
>
> Best,
> Geoff
>
> On Wed, Mar 2, 2016 at 12:18 PM, Andrey Somov <[email protected]>
> wrote:
>
>>
>>
>> On Wed, Mar 2, 2016 at 6:06 PM, Geoff Adams <[email protected]>
>> wrote:
>>
>>> I wrote a libyaml wrapper for Matlab, a language which doesn't even have
>>> a real native mapping type (or didn't until very recently, and it's sort of
>>> kludged on), meaning there's no native type to easily represent mappings
>>> with scalar keys which aren't strings.  However, the most common YAML
>>> mappings, with scalar string keys, can be naturally represented with
>>> Matlab's struct type, and 95% of the time this is definitely what the user
>>> wants.  I chose to provide a generic representation, where YAML mappings
>>> are represented in Matlab as a list (cell array in Matlab parlance) of
>>> key-value pairs, as well as a specialized representation for those mappings
>>> which Matlab can represent as structs, and allowed the user to select which
>>> is appropriate for the application.  This same strategy is applied for
>>> non-scalar keys.
>>>
>>> I think this is a more appropriate strategy for parsers in languages
>>> which do not offer a simple native-type representation of non-scalar
>>> mappings (or any other useful YAML feature). If your users are telling you
>>> you need to change your YAML because they can't parse it, the problem is
>>> that their parser is not standards-compliant, not that the full YAML spec
>>> is impossible to implement in their language.  Any language that offers at
>>> least nested mixed-type lists (or some other representation of a mixed-type
>>> tree) should be able to represent any YAML document, even if that
>>> representation is less "natural" than it would be in a different language.
>>>
>>> Short version, don't drop useful features from YAML 2.0 just because
>>> they're inconvenient to implement in some languages.  If it can work in the
>>> arbitrary mess that is Matlab, it can work in your language.
>>>
>>
>> I do not say that we should drop it because it is  inconvenient to
>> implement in some languages.
>> I say that it should not be there at all !!!
>> This is the same as implicit types (http://yaml.org/type/index.html)
>> which will be fortunately dropped. If something can be done, does not mean
>> that it should be done.
>>
>>
>>
>>> Best,
>>> Geoff
>>>
>>
>>
>

------------------------------------------------------------------------------
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

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core