From: Ingy d. N. <in...@in...> - 2014-11-16 02:40:12
|
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 <mof...@gm...> 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 > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > |