Re: [Yaml-core] JSON Compatibility

[Clark C. E. <cc...@cl...>]

Although JSON compatibility is nice, most JSON parsers accept the
following content, {"one":"1",two:"2","three":3,four:4} and hence, to
make sure we don't have any hiccups in these four cases is important.
In particular, we have two cases, 10:20 and a:scalar which although they
do not conflict with the above uses, could be confusing if they have a
different meaning than what is expected.

On Thu, Apr 13, 2006 at 12:57:41AM -0700, Ingy dot Net wrote:
| On 12/04/06 18:01 -0100, Oren Ben-Kiki wrote:
| > - Allow the use of date/time values in flow collections (10:20).

I'm OK with still allowing 10:20 as a valid unquoted scalar (as a
in-flow sequence value or mapping key).  But it isn't essential.

| > - Allow people to type foo:bar and foo:2 as key/value pairs (as a side
| > effect, this solves JSON comatibility, but that's a fringe benefit; we
| > can do JSON compatibility in other, simpler ways).

This is a nice goal, although I'm happy with foo:bar becoming illegal
due to its historical difference.

| > - Allow Perl::Module as a key, at least in block mappings, because a
| > ton of CPAN .yml files use that.
| > - Allow unquoted URLs, especially "http://whatever"

Ok; but really neither of the above must necessarly be unquoted
within a flow collection.

| 1) Valid JSON streams (or at least common JSON streams) are valid YAML.

Ok.  See above though: {"one":"1",two:"2","three":3,four:4}

| 2) In *flow* collections only, we need to allow a key/value pair to be
| separated by a colon without a following space.

It would be nice, due to the above cases; however, I don't care about
key:value as much, but Oren pointed out that implicit typing of times
in this context would be icky: [! "10:20" ] 

The other case is ISO dates, 2005-12-06T12:32:45 is another case.

| This is actually being generous. YAML supports key/value pairs in both
| flow mapping and sequences. JSON only has them in mappings.

Well, this isn't true due to map-in-seq format.

| 3) We don't need to change *block* collections at all.

Agreed.

...

| 5) Forbid a colon in a plain key in a flow collection.
| 
| This is simple as far as rules go. It means that using times and urls
| as keys (in flow collections ONLY) requires quoting them, and that
| foo:bar is just an error. An error that keeps you from shooting 
| yourself in the foot.

I like this option.

| It also prevents:
|     [10:20, 10:30, 10:45]

Yep.

| 6) You can omit the space after the colon in a key/value flow collection
| separator, IF AND ONLY IF the key is quoted.

The problem is, there are lots of Javascript out there that is passing
as JSON... ie, most JSON parsers accept the mapping above.

| The only thing it doesn't solve is {foo:bar} ambiguity.

Yea.  Make it illegal.

On Thu, Apr 13, 2006 at 09:22:48AM -0700, Oren Ben-Kiki wrote:
| > 5a) Forbid a colon in a plain key in a flow *mapping*.
| 
| Today we have three sets of restrictions on plain scalars -  outside
| flow, inside flow, and keys. What you suggest is that we bump it up to
| four - flow-key, flow-value, block-key, block-value.

Can't we make it simpler.... not worse?  I'd rather give up
some usability to make it more regular; although this conflicts
with Brian's good observation that we don't require flow and block
to use the same productions.

| block-value: Can't start with an indicator, can't contain ": ",
|              can't contain " #".
|
| flow-value: As above, but also can't contain [ { , } ]
|
| block-key: As above, but one-line and limited to 1K chars
|
| flow-key: As above, but can't contain any ":".

Under these proposed rules:

  - {key:value} is illegal
  - [key: value] means [{"key": "value"}]

Good.
  
  - [key:value,10:20] means ["key:value","10:20"]

I think this is problematic: splitting hairs.  To be compatible
with JSON we need:

  - {"key":3}
  - {"key":"value"}
  - {"key":true}

To be compatible with common Javascript usage that claims to be 
JSON (and just about every other JSON parser handles):

  - {key:3}
  - {key:true}
  - {key:"value"}
  - {"key":3}

I'm still undecided.

Clark