Re: YAML 1.2/1.* vs YAML 2.0

along these lines ...
> 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".

I'll revisit some examples (from 10 years ago):

---
color: #c0c0c0
title: Hanna Reitsch: Hitler's Female Test Pilot
chapter: 1[tab]Aviation
...

---
Creator: Baldowski, Clifford H., 1917-
Title: You crazy communist! You trying to get us all killed?, [1962].
Online Publisher: [Athens, Ga.] : Digital Library of Georgia, 2002
Original Material: Savannah, Ga. : Commercial Lithograph & Printing Co., 1917
...

Feeding these into http://ben-kiki.org/ypaste/ seems to indicate that
some of them are DWIM, while others are not.

In short, in an "ini" format (speaking loosely), the above might look like this:

[1]
color: #c0c0c0
title: Hanna Reitsch: Hitler's Female Test Pilot
chapter: 1[tab]Aviation

[2]
Creator: Baldowski, Clifford H., 1917-
Title: You crazy communist! You trying to get us all killed?, [1962].
Online Publisher: [Athens, Ga.] : Digital Library of Georgia, 2002
Original Material: Savannah, Ga. : Commercial Lithograph & Printing Co., 1917

and on each line, everything from the first colon to the newline is
the value of the key preceding the colon.  YAML doesn't do this for
reasons that require some knowledge of the YAML specs.  Getting this
to consistently DWIM in YAML is easiest fixed by requiring quotes,
e.g.,

---
color: "#c0c0c0"
title: "Hanna Reitsch: Hitler's Female Test Pilot"
chapter: "1[tab]Aviation"
...

---
Creator: "Baldowski, Clifford H., 1917-"
Title: "You crazy communist! You trying to get us all killed?, [1962]."
Online Publisher: "[Athens, Ga.] : Digital Library of Georgia, 2002"
Original Material: "Savannah, Ga. : Commercial Lithograph & Printing Co., 1917"
...

But in that case, it's easy to say, "Well then, why not just use
JSON", which has arguably a shallower learning curve.

I'm saying all this in the spirit of, "What is your least favorite
part of YAML", which for me is the fact that one of the goals of YAML
is *not*:

YAML documents are easily writable by humans.

Because, I'm sorry, they are not.  :-)

The second part of the above quote is, "and how would you fix it"

Honestly, I don't know.  Maybe an iYAML profile (Apple be damned)?  Or
maybe eYAML would handle this?

Since I first brought this up, I've been using an "ini" config format
with embedded JSON where needed (my own monster), and that has worked
okay for me.  I *want* YAML to meet my needs.  But lack of the
"writable" goal means it doesn't.

Best regards,

Brad


On 3/3/16, Oren Ben-Kiki <[email protected]> wrote:
> 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