Re: Is there a slim YAML?

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