Re: minimal YAML recommendations?

mofo,

I read those over. One thing to note is that JSON is not a serialization
language, per se. You can't give JSON an arbitrary data object and expect
it to serialize it. YAML is a serialization language. It was built as such;
to be able to serialize any data object. You can of course work out a
scheme to serialize any data with JSON, but you could also do that with XML
or English. I actually did this with JSON. It's called JSYNC.

JSON is a simple exchange format for very common data structures.

I'm not sure what things you use YAML for. People seem drawn to YAML for
config stuff, but imho the INI format is better most of the time. In the
early days of creating YAML we didn't think it was really that great for
config. The TOML thing is really just a INI variant. For some reason they
compare it to YAML, but TOML isn't a serialization language at all.
Programs only read it, they don't write it (AFAIK).

I'm interested in continuing this conversation of simplifying YAML and
having named reductions. I'm not sure profile or embedded YAML have quite
the right feel, namewise.

Schema refers to type resolution. So you can have different schemas that
make the same YAML mean different things, but Schema can't limit the
syntax. That would be under the domain of Grammar. So a YAML Lite (or
whatever we called it) would adhere to a subsetted Grammar and a certain
Schema.

Thanks for stopping by IRC. I wish we could have been there the same time.
Perhaps we can work out a time to meet up.

Ingy

On Sat, Jan 31, 2015 at 4:11 AM, mofo syne <[email protected]> wrote:

> Btw, the lack of parsers that "only adhere to default schema"...
>
>    - all implementations would adhere to it by default
>
> Would that be an issue with branding? (a dirty word for marketing to
> users). If so then maybe instead of saying "default schema", we could
> define it as a profile. Much like how Java defines different profiles for
> different platform types "mobile profile" vs "desktop profile". So in this
> case of a parser that only supports the "default schemas". Would this name
> suffix?
>
> Embedded YAML - eYAML
>
> We can of course have other profiles later for those that need a better
> mix of capabilities, between eYAML vs Full YAML.
>
> -----
>
> Anyway thanks for the wiki. I added two pages that summarizes the two
> concepts discussed in this email.
>
> https://github.com/yaml/YAML2/wiki/eYAML - Embedded YAML profile.
>
> https://github.com/yaml/YAML2/wiki/YamlToJSON - Type/Model preservers VS
> Type/Model Strippers.
>
> -----
>
> Hopefully that covers everything, if you got a better idea, or can improve
> upon the above two pages. Please do. I would really like to see this
> happen. As it would increase YAML2 adoption rate, if it's easily included
> within other programs (or maybe even batteries included in python etc...)
>
> On Sat, Jan 31, 2015 at 5:21 PM, Oren Ben-Kiki <[email protected]> wrote:
>
>> On Sat, Jan 31, 2015 at 1:01 AM, Ingy dot Net <[email protected]> wrote:
>>
>>> Hi mofo,
>>>
>>> Oren, I always consider the 3 main additions from JSON to be:
>>>
>>>    - Types (Tags)
>>>    - References (Anchor / Aliases)
>>>    - Keys (can be any node, not simply strings)
>>>
>>> Also:
>>>
>>>    - Multiple documents per file/stream.
>>>
>>> Those are all model changes. The major syntax changes are:
>>>
>>>    - Block form (no {} [])
>>>    - Quoting styles (esp NoQuotes)
>>>    - Comments
>>>
>>> Yes, I was sloppy. I packed all the model changes together as
>> "deserialization control". You are of course correct.
>>
>>> The YAML spec is a little over complicated but I started this wiki to
>>> discuss making YAML 2.0, simply be a reduction of the current YAML:
>>> https://github.com/yaml/YAML2/wiki#yaml-20-proposals
>>>
>> The main one is getting rid of the folded scalars. Merging it with the
>> quoted one is an interesting idea.
>>
>>> There are quite a few documents on the net that people base modern
>>> implementations on taht should probably be removed. People end up all over
>>> the place on default schema (typing of unquoted strings). eg the string
>>> *Yes* being loaded as a boolean. http://yaml.org/type/bool.html is the
>>> culprit. Sometime after we published this we agreed that by default only
>>> (true false null) and unquoted numbers should be loaded as non-strings.
>>>
>> Yes. We got rid of all that in 1.2 but I guess the habit stayed...
>>
>>> In YAML, any node can be loaded as almost any object. It all depends on
>>> the "schema" being used. We've been bad at making a best practices
>>> document. In general, people make implementations where the schema is at
>>> least agreed upon within the Load/Dump functions of that particular
>>> framework. In a better world:
>>>
>>>    - there would be a clear default schema
>>>
>>> I think the 1.2 spec provides a clear default schema...
>>
>>>
>>>    - all implementations would adhere to it by default
>>>
>>> There's the rub.
>>
>>>
>>>    - we would have a schema language
>>>
>>> Yes, that would be nice. There are JSON schema proposals, ideally we
>> should superset them.
>>
>>>
>>>    - implementations would be schema aware and have the ability to
>>>    load/dump accordingly
>>>
>>> In the Perl world there exists a YAML::Tiny, which is a
>>> non-yaml-core-approved but heavily used and useful thing that is the spirit
>>> of this topic. It's doc has a mini spec:
>>> https://metacpan.org/pod/YAML::Tiny#YAML-TINY-SPECIFICATION
>>>
>> It would be nice to update it to be 1.2 compatible; that would allow it
>> to use bool, for example, and I think resolve some of the other issues.
>>
>>> I started a parser generator project called Pegex that is easy to port
>>> to any language that has regex support. The primary idea is to make
>>> grammars that are really easy for people to read and maintain, and that
>>> create parsers in 20 languages at once. Here's a Pegex grammar for JSON and
>>> also JSONY (a JSON variant I helped create):
>>>
>>>    - https://github.com/ingydotnet/json-pgx/blob/master/json.pgx
>>>    - https://github.com/ingydotnet/jsony-pgx/blob/master/jsony.pgx
>>>
>>> These grammars have released implementations. My unfinished goal is to
>>> do a YAML grammar for Pegex, so at least we can have a set of
>>> implementations based off the exact same document.
>>>
>>  Not sure I follow the syntax there. The main PITA in the YAML spec is
>> that we can't use INDENT/UNDENT because of the way that '- ...' behaves.
>> Explicit keeping track of indentation then becomes an issue.
>>
>>> If you'd like to chat more, find me in #yaml on irc.freenode.net
>>>
>> It has been dead for so long... What is your time zone these days? I'm in
>> Israel.
>>
>
>

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

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