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

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