Re: YAML 1.2/1.* vs YAML 2.0

On Thu, Mar 3, 2016 at 6:21 AM, Peter Murphy <[email protected]> wrote:

> As I observe, the problems that people have is with the multiplicity
> of ways to present the same information, and the issues some of those
> ways have.


+1. Note that some of the examples (such as the boolean problem) is due to
people using YAML1.1 and ignoring the pretty explicit YAML1.2
failsafe/JSON-compatible/"Core" schema spec. A "Core"-schema YAML1.2 parser
does not have this specific problem. But some problems (such as the folded
blocks) remain.

 The removal of composite keys requires a change to the YAML _content

> model_, on the other hand, and so it becomes impossible to represent
> the same thing that used to be representable in YAML.


+1 again. IMVHO we will not drop composite keys. If you don't want them,
don't use them. If your application doesn't support them, reject inputs
that use them. But they are there for those who do need them and I don't
see them going away.

IMO YAML2.0 w/o composite keys isn't YAML2.0, it is JSON2.0. If that's what
people need - great! there have been several attempts to move the JSON spec
forward, and doing so while keeping YAML compatibility in mind would be
nice; we should ensure that YAML2.0 would be a superset of JSON2.0 - if
there is such a thing.

In 10 years, we basically didn't hear any request for truly new features,
which I take to mean that the basic design is good - especially the data
model. I don't want to touch that part. We did get a lot of complaints
about the difficulty of parsing, and people just didn't use some of the
stuff (folded blocks, %TAG, ...).

So the way I see it, YAML2.0 should be basically YAML1.2 minus the stuff
that people turned out not to use in the past 10 years, with the goal of
making parsing as simple as we can make it. I'd like to spend some time on
figuring out how to make the spec friendly for parser generators, for
example. The main problem is the pesky indentation rules. Maybe we can do
something about that.

I very much like Ingy's proposal of replacing folded blocks with something
based on ".

I think lots of people use | blocks though (I certainly do) so I'd be
careful modifying that. I like the idea of dropping the explicit
indentation integer and replacing it with the location of the | on the next
line - that's a much more elegant, and I don't think people use |2 that
much. We might be able to simplify/get rid of chomping while at it, by
using "-alone-in-the-next-line for a chomped literal block, so we'll be
able to get rid of |- as well. That's probably not used much either.

Getting rid of directives also makes sense - basically, keeping the same
data model but saying "this data is provided externally to the parser, we
don't mandate how this is done". This would simply the syntax.

Doing some sort of schema language would help - "we don't mandate how the
data is specified, but a recommended way is to allow loading a schema file
in this format". Again, this needs more thought.

There are probably other proposals along these lines. We should spend some
time actively polling people for ideas. "What is your least favorite part
of YAML, and how would you fix it".

Making it explicit the type repository is 1.1 and not 1.2 and people
shouldn't use it is also important. It is creating misconceptions (repeated
in this thread), e.g. about booleans, which are simply not true in 1.2 -
but implementations get it wrong anyway.

An actually useful ANSI-C reference implementation (some efficient
low-level tokenizer/streaming parser), usable as a basis for higher level
libraries, would be great.

For me, that's basically "it".

This means YAML2.0 would "just work out of the box" for "almost all" the
configuration files out there (and there are a *lot* of these). I think
that's important. We did something similar when moving from 1.1 to 1.2.

Ingy may have a very different notion for YAML2.0 though - if so, I'd call
the above YAML1.3. I don't see it as a revolution, I see it as an
evolution. We should reawaken Clark and see what his take on this is...

Have fun,

Oren Ben-Kiki

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

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