Re: [Yaml-core] Re: Can a YAML 1.x specifcation really fix JSON compatibility?

[Oren Ben-K. <or...@be...>]

> Burt Harris wrote:
> >   - I guess my second error probably amounts to a bug in my parser.
> >     I thought for sure a space following the comma list separator
> >     was required.   Was this a change between YAML 1.0 and 1.1?

Yes, and this was part of why we bumped up the number - we broke
compatibility. In practice, we weren't aware of implementations that
actually used the "1,234" in practice, so we figured this isn't a
major issue.

> > I'm still a little unclear about your statement that there is an
> > ambiguity between YAML 1.0 and YAML 1.1 documents.   I may have
> > misinterpreted the following line in the specification:
> >
> >     A version 1.1 YAML processor should accept documents with an
> >     explicit "%YAML 1.1" directive, as well as documents lacking
> >     a "YAML" directive.
> >
> > I had read this to mean that a YAML 1.1 processor should treat
> > Documents lacking a YAML directive as YAML 1.0, and that all YAML
> > 1.1 processors should support YAML 1.0 syntax.  This would is match
> > the approach XML 1.1 took to prevent any ambiguity.

I'll definitely add that to my todo list in fixing the spec. The above
is NOT what we had in mind... the idea is that each YAML 1.1 parser
has some "default" YAML version in mind and uses that in the absence
of proof to the contrary (such as an explicit %YAML directive). YAML
1.2 parsers (if/when they exist) may use a different policy, such as
the one you describe.

As Ingy dot Net <in...@tt...> wrote:
> I don't think YAML is so interested in avoiding the ambiguity. It's not
> really a big deal in practice. Documents without tags and directives
[and 1,234 integers]
> will parse the same in 1.0 and 1.1. Documents without a directive would
> typically be used in a small domain, where you could just assume the
> producer and consumer are the same.
And I would add: where you usually can use a small script to fix any
compatibility problems when migrating to YAML 1.1.

Remember YAML 1.0 is deprecated. Since common implementations are 1.0
(e.g. libsyck), this means simply avoiding problematic constructs
(%YAML:1.0, 1,234, and tags) - which AFAIK is the default behavior.

YAML 1.1 is pretty solid and stable. Other than the (very minor) JSON
tweak we hadn't had a good reason to touch it in about a year now, and
there is a new wave of implementations arriving for it. Unlike Clark I
have no burning passion to break compatibility and go to YAML 1.2, and
at any rate this won't happen any time soon. If/when it does, we will
certainly place a lot of thought into compatibility and migration.

Ingy also said:
> People seem to think that YAML documents should be able to stand on
> their own and be unambigous, and if you find some yaml lying on the
> ground, you can pick it up and use it safely. But this is not the case.

I agree this is what people expect, and I think that to a large extent
this is the case - and *should* be the case. The transition from 1.0
to 1.1 was painful but luckily there was a small enough installed
base, the changes were very minor, the features in question were so
rare and the triviality of a one-shot sed/awk/perl script to fix the
problem all combined to us simply ignoring the migration issue. This
will not be the case when migrating to a hypothetical YAML 1.2 :-(

> A YAML document must have a context. "context" could also be thought of
> as "schema". Two processors can't just start talking to each other in
> YAML without and agreed upon context or schema.

It is true there is a world of difference between what you can do with
a YAML document of a known "schema" and a YAML document you just pick
up from the ground. That said, one of the great advantages of YAML is
that you can still do a whole lot of useful stuff for "unknown" YAML.

Finally:
> YAML achieves its human friendliness, by leaving parts of the
> information model in the hands of the application.

This is a crucial point. YAML *always* chose readability over all
other considerations, and the above is part of what we have to pay.
Human beings are incredibly context-aware, and computers are very much
the opposite. Bridging the gap isn't easy. I think we did a pretty
good job at it, but you'll *always* be able to find some stressed
seams where some of the gap shows through.

Have fun,

    Oren Ben-Kiki