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

If the argument is just, "do exactly what JSON is doing," then why not just
use JSON?  I don't see what YAML offers at all in that case.

Best,
Geoff

On Wed, Mar 2, 2016 at 12:53 PM, Andrey Somov <[email protected]>
wrote:

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

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