Other Considerations

Here are several items we considered when drafting our specification.

Remove the :

We could have actually removed the ':' that separates the object key and value. We tried it. It worked. But the code was difficult to read. It was too relaxed. The ':' makes it very clear to the human reader if the items are object keys, object values, or array values. FYI, it looked like this:

[
    { name object1 value o1value } { name object2 value o2value }
]

The colon requirement does not add too much noise, and can actually take the place of the required space.

[
    { name:object1 value:o1value } { name:object2 value:o2value }
]

So given the fact the the colon does not bloat the code, we did not remove it.

Unquoted spaces in object keys

This would be easily parsable:

{ my key : 'my value' my other key : 'my other value'}

But too difficult to read, and inconsistent between keys and values.

Allow commas in objects and string values

We could have allowed commas in unquoted object names and string values, when not in lists:

this,is,a,test

{this,is,a,key : this,is,a,value}

Too relaxed... So given the fact the the comma does not bloat the code, we did not remove it.

Allow { and [ if not preceded by whitespace or starting a string

Once again, too relaxed.

{ 
    foo{bar : goo}bar
    a[b : c]d
}

Leave out the [ ] and , from arrays

Yep, too relaxed. This syntax makes it difficult to catch faulty input. It is difficult for the user to notice lists in multiline text blocks. Dropping the commas saves no space. And a single value creates ambiguity between either a value or array of a single value.

one two three "hello world"
four

instead of

[one, two, three, "hello world", four]

["one", "two", "three", "hello world", "four"]

Optional Comment Mode

This would have allowed us not to put // and /* into the reserved words list, hence allowing those combinations to be put into simple-keys and simple-values.

One important reason for this would be for URLs to not need quotes:

{ url: http://www.foo.com }

But the URL has ':' too, so no loss there.

Numbers

We considered NAN, +INF, -INF. The problem is that they can't be encoded into JSON, hence not parsed by JSON parsers, and not converted round trip. If your application needs these values use number or string, and check if the type is a number or string representation after parsing.

[ 10 nan inf -inf ]

[{v:10} {v:nan} {v:-inf} {v:inf]