Re: Is there a slim YAML?

What do you mean by ignore? Ignore the entire document, or ignore a part of
the YAML? To do the latter requires that you actually parse what you
subsequently ignore, so it seems not what you want.

What is your specific use case (where you say "for our purposes" above)? I
don't know of any parsers (for any syntax, not just YAML) that put error
messages into the thing they are parsing.

On Sat, Nov 15, 2014 at 11:26 PM, mofo syne <[email protected]> wrote:

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

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk

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