Re: Is there a slim YAML?

For our purposes it would be best if we could simply ignore rather than
throw an error for non recognized entries in YAML inputs.

A warning message can be emitted externally, or within the YAML ast if
possible.

This is since you might have the same document being run through various
parser capability. So you want some access at least, rather than all or
nothing. A 'cannot parse' entry is better in this case.
On 16/11/2014 1:08 pm, "Ingy dot Net" <[email protected]> wrote:

> NOTE: I sent this reply to Mofo a couple days ago but failed to reply to
> all.
>
> Hi Mofo,
>
> Thanks for bringing this up to the yaml-core mailing list. I'm not sure
> even where to start. I'll throw out some random points that come to mind:
>
>
>    - YAML was designed to be a full, cross-language, data serialization
>    language
>       - It is just a current state of affairs that people use it mostly
>       for trivial purposes like config files
>       - There *are* minimal (not yaml.org approved) YAML implementations,
>    that only exist in a particular language like Perl's YAML Tiny
>    <https://metacpan.org/release/YAML-Tiny>
>    - I started the YAML2 discussions <https://github.com/yaml/YAML2/wiki>
>    3 years ago to make YAML less complex without losing its powers
>    - I'm working on a Pegex based YAML implementation that will generate
>    parsers in all YAML languages from a single grammar
>    - There are only 3 major differences between YAML and JSON (at the
>    data model level):
>       1. References
>       2. Tags/types
>       3. Non-string mapping keys
>    - YAML implementations can be complete, full-stack, or minimal
>    text→native
>
>
> I think that the YAML spec documents cause implementor confusion because
> it is unclear what needs to be implemented. These are my opinions on what
> should be properly conveyed:
>
>    - The YAML 1.2 *syntax* as specced is correct. (Though a 2.0 could
>    make it simpler)
>    - The default schema should only support JSON types: Str, Num, Bool,
>    Null, Map, Seq
>       - ie no Date, Set, OMap or any other should be made available by
>       default
>    - Only true/false/null (from JSON) should be implicitly recognized.
>    Not the Yes/No/True/False/… options.
>    - Merge key is something that should only be available as a plugin.
>    This was just a idea we threw out, and for some legacy reasons some of the
>    implementors implemented it and some did not.
>
> It seems we need a YAML implementors guide. I'm thinking that what you are
> seeking could be part of this. I would encourage people not to fork YAML to
> a simpler form, but to simply make weaker/simpler implementations according
> to an agreed upon guide. Here are some basic thoughts on how this might
> look:
>
>    - *Format* is called YAML
>       - .yaml and .yml extensions are used
>    - *Implementations* can be called SimpleYaml or somesuch
>    - Basic *Loader* restrictions:
>       - Explicit Tags throw error on parse
>       - Flow forms throw error on parse (except empty [] {} which have no
>       block form)
>       - JSON schema as above
>       - Anchor/Alias throw error on parse
>       - Non-string (plain/quoted) keys throw errors
>       - No stack. Loader == Parser→Constructor
>    - *Dumper* restrictions:
>       - Dumpers must produce streams loadable by Loader above
>       - Streams must be loadable by any more complex loader
>
>
> In conclusion, there are ways to make YAML simpler on many levels without
> forking it. I personally am interested in discussing them.
>
> Consider joining #yaml on irc.freenode.net to discuss further.
> Cheers, Ingy
>
> PS It dawns on me 2 days later that partial implementations can be
> approved by yaml.org as long as:
>
>    - The Parser only *accepts* things that are valid YAML.
>    - The Parser rejects (hopefully with a helpful error message) things
>    that are valid YAML but not supported by this parser.
>    - Assuming the implementation has a Dumper
>       - The Dumper should only produce YAML that is consumable by the
>       Loader.
>
> In other words, there's no reason that you can't make partial YAML Loaders
> now, and call them such. As long as you are not introducing non-yaml texts
> into the world and calling them YAML, it's all good.
>
> On Wed, Nov 12, 2014 at 1:44 AM, mofo syne <[email protected]> wrote:
>
>> Question in point:
>> http://talk.commonmark.org/t/metadata-in-documents/721/24
>>
>> > I'd like to warn about YAML use. Though YAML is very nice for humans,
>> it's very difficult for correctimplementation. Placing it to spec "as is"
>> will create ass pain for client-side parsers. Mostly because of big size. I
>> say this, as author of js-yaml1 - the most popular js implementation.
>>
>> > It worth to "officially" restrict some YAML features like omap, set,
>> anchros, merge, custom types. That will make possible to create more fast
>> and compact parser for YAML subset. IMHO, it would be enougth to support
>> JSON types and (may be) Date.
>>
>> Was said by a vitaly from that page.
>>
>> I would like to know if there is a restricted subset of YAML, that is
>> suitable for embedding in other parsers with minimal size for a small
>> set of core syntax (but extendible).
>>
>> If there isn't. Then it is likely that commonmark may devise its own
>> YAML restricted variants, but that comes at a cost to consistency
>> across YAML implementations. So it is definitely in our interest to
>> have at least a common core restricted syntax of the most commonly
>> used YAML syntaxes (And a good way to degrade other more advance
>> features that is left out, but is still in the input YAML file).
>>
>>
>> ------------------------------------------------------------------------------
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Yaml-core mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/yaml-core
>>
>
>

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk

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