From: Oren Ben-K. <or...@be...> - 2007-05-05 17:56:18
|
I just noticed that for some inexplicable reason, in JSON "\/" is the same as "/". No idea why they added escaping the perfectly innocent slash character, but it is in their spec. We'll need to add "\/" as a valid escape sequence in the YAML spec to maintain being a JSON superset. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@be...> - 2007-12-30 09:23:13
|
Ingy has brought to my attention that Marc Lehmann has written in http://search.cpan.org/dist/JSON-XS/XS.pm#JSON_and_YAML about another incompatibility between JSON and YAML: > Please note that YAML has hardcoded limits on (simple) object key lengths that JSON doesn't have, > so you should make sure that your hash keys are noticeably shorter than the 1024 characters YAML allows. This refers to the 1K key limit YAML uses to avoid unbound lookahead in _block_ context: --- # Lookahead required to distinguish between: - "very long key string": value - "very long non-key string" ... We can lift this restriction inside flow mappings: --- { "always a key without need for lookahead":value } ... This should complete the changes requires to make YAML 100% compatible with JSON. We hope :-) I have been remiss updating the spec, but I have done some work cleaning up and debugging the productions (the corrected set is available as part of the YamlReference Haskell package and can also be run using http://dev.yaml.org/ypaste for testing and reporting issues). I will fix these to lift the 1K key limit in flow mappings, and will resume updating the spec to match. Have fun, Oren Ben-Kiki |
From: Andy B. <yam...@th...> - 2007-05-06 08:36:33
|
On Sat, 2007-05-05 at 10:56 -0700, Oren Ben-Kiki wrote: > I just noticed that for some inexplicable reason, in JSON "\/" is the > same as "/". No idea why they added escaping the perfectly innocent > slash character, but it is in their spec. We'll need to add "\/" as a > valid escape sequence in the YAML spec to maintain being a JSON > superset. 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. Pages 18-20 of ECMA-262 (dated '99, is that the latest?) doesn't define slash as an valid escape character. I assume you are suggesting to add "\/" as yielding "/" on input only, and not suggesting that "\/" be emitted when generating a YAML string for "/"? 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". -- Andy Bakun <yam...@th...> |
From: Oren Ben-K. <or...@be...> - 2007-05-06 13:04:37
|
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 |
From: Oren Ben-K. <or...@be...> - 2007-05-07 14:44:05
|
I don't see how using "\/" instead of "/" helps when embedding JSON in HTML... It seems to me that placing JSON anywhere that isn't a CDATA section won't work anyway (even then you'd have to be careful not to end the section, just like when embedding JavaScript code). What am I missing? On Sun, 2007-05-06 at 19:36 -0700, Douglas Crockford wrote: > I think Oren's interpretation is correct. JSON allows the "\/" so that JSON text > can be embedded in HTML. If an application is not embedding data in HTML, then > there is no reason to use the "\/" form. |