Metadata in documents

Extensions
47

Below from mailing list from Ingy dot Net ingy@ingy.net

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=E2=86=92native

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/=E2=80=A6 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 =3D=3D Parser=E2=86=92Constructor
  • 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.perl.org to discuss further.

Cheers, Ingy