Re: [JSON] Semantics of JSON

From: Richard Cyganiak <richard@cyganiak.de>
Subject: [JSON] Semantics of JSON
Date: Fri, 25 Mar 2011 06:22:31 -0500

> On 25 Mar 2011, at 03:19, Peter Frederick Patel-Schneider wrote:
>> What I think is really needed for the WG to proceed much further is at
>> least initial drafts for:
>> 1/ effective syntax for JSON (RFC4627 gives the reference syntax, but
>>   what are the problematic parts of this syntax)
> 
> RFC4627 *is* the effective syntax.

So the WG can reuse member names in objects?  What about colons, etc.?
What about the numbers posted a while ago?

>> 2/ some notion of the meaning of JSON 
> 
> Is the following account of the meaning of JSON good enough, Peter? This
> is selective copy-and-pasting from RFC4627. I added the bits in [square?]
> brackets to assist the context-impaired. The only part that is
> problematic in this copy-and-paste effort is the SHOULD, because objects
> with duplicate names do not work as expected in many implementations.
> 
> 
> A JSON text is a serialized object or array.
> 
> An object is [an unordered collection of] zero or more name/value
> pairs. A name is a string. The names within an object SHOULD be unique.
> 
> An array is [an ordered [sequence?] of] zero or more values.
> 
> A value is an object, array, number, or string, or one of the following
> three literal names: false null true
> 
> Numeric values that cannot be represented as sequences of digits (such
> as Infinity and NaN) are not permitted.

Add in 

A string is a sequence of zero or more Unicode characters.

and maybe a few more low-level details and I would be happy with it.  In
fact, I expected that there would be a document that explicitly stated
this, but I've been hearing "RFC 4627 is only concerned with syntax",
which goes against using it to talk about the meaning of JSON.

However, I wouldn't then want anyone to say "Well, you can have multiple
values as long as one of them is null.  After all, null isn't a real
value."  or, more likely, "Null means that there is no value, so it can
be surpressed during parsing and serializing".

peter

PS:  I note the strange status of boolean in RFC 4627 and the weird
situation in the Parsers section.

Received on Friday, 25 March 2011 13:17:30 UTC