Re: [JSON] Semantics of JSON

Peter,

I put this on the wiki and tried to fill in some more details, hopefully addressing your comments:
http://www.w3.org/2011/rdf-wg/wiki/TF-JSON/Semantics_of_JSON

I would appreciate if those with more JSON experience (Manu? Nathan?) could have a look over the “Practical considerations” section.

Best,
Richard



On 25 Mar 2011, at 13:16, Peter Frederick Patel-Schneider wrote:

> 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 16:29:36 UTC