Re: [Yaml-core] JSON compatibility

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

On Sun, 2007-05-06 at 03:32 -0500, Andy Bakun wrote:
> I assume you are suggesting to add "\/" as yielding "/" on input only,
> and not suggesting that "\/" be emitted when generating a YAML string
> for "/"?

Yes. Well, you would be _allowed_ to generate "\/" but it wouldn't be
the recommended practice. In general the rule should be to use the
shortest form for presenting each character - that is "a" and not
"\x61", and similarly "/" and not "\/".

> I agree, this is extremely odd.  Additionally, the definition of a
> string, in both the graphical representation and the simple BNF on the
> right, is internally inconsistent, as the straight through path doesn't
> mention solidus in the exceptions; or solidus is classified as a control
> character.

ASCII, and for that matter Unicode, have a formal definition of what
"control characters" are, and "/" isn't one. This doesn't make it
inconsistent; instead I simply read the JSON spec to say that both a
simple "/" and a "\/" are allowed. Odd, but there you have it.

> Pages 18-20 of ECMA-262 (dated '99, is that the latest?) doesn't define
> slash as an valid escape character.

However:

> By ECMA-262, which I presume JSON is meant to be fully
> compatible with, "\z", where z is not an already specified escape
> character, yields the literal "z".

So interpreting "\/" as "/" is valid under ECMA-262.

Luckily for us, the JSON spec does not say that an unspecified "\z" is
interpreted as "z". This allows us to use our richer set of escape
sequences and still be compatible with it. So JSON is a (compatible)
subset of ECMA-262, YAML is a (compatible) superset of JSON, but YAML is
incompatible with ECMA-262.

I'm CC-ing this to json.org, to ensure we are doing the right thing.

Have fun,

	Oren Ben-Kiki