Re: [JSON] Tiny Proposal

Hi Peter, and anybody else finding confusion around JSON,

Please do familiarise yourself with section 15.12 of the ECMAScript-262 
[1] specification which covers JSON, it's relations to the rest of 
ECMAScript-262 (the thing most people mean when they say "javascript") 
including terms like "key" and "value" and also the parsing and 
stringification rules:
   [1] 
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf

Best & Hope that helps,

Nathan

Peter Frederick Patel-Schneider wrote:
> From: Nathan <nathan@webr3.org>
> Subject: Re: [JSON] Tiny Proposal
> Date: Wed, 23 Mar 2011 15:26:23 -0500
> 
>> cc-RDF WG
>>
>> Peter Frederick Patel-Schneider wrote:
>>> From: Nathan <nathan@webr3.org>
>>> Subject: Re: [JSON] Tiny Proposal
>>> Date: Wed, 23 Mar 2011 14:38:31 -0500
>>>
>>>> Peter Frederick Patel-Schneider wrote:
>>>>> From: Nathan <nathan@webr3.org>
>>>>> Subject: [JSON] Tiny Proposal
>>>>> Date: Wed, 23 Mar 2011 13:14:00 -0500
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Here's a tiny proposal:
>>>>>>
>>>>>> 1: Constrain JSON [1] to be an (optionally nested) sequence of one or 
>>>>>> more objects (where one, no enclosing [] is needed).
>>>>> Do you mean here that no arrays are allowed at all?  Why?  Can't arrays
>>>>> turn into lists?
>>>> Yes arrays are allowed, as for lists how would one distinguish between 
>>>> multiple values and a list?
>>>>
>>>> x y "a", "b", "c" .
>>>> x y ( "a" "b" "c" ) .
>>>>
>>>> would both be
>>>> {
>>>>   "@id": "x",
>>>>   "y": ["a","b","c"]
>>>> }
>>> No!  This would be the second.  The first would be
>>>
>>> {
>>>   "@id": "x",
>>>   "y": "a",
>>>   "y": "b",
>>>   "y": "c"
>>> }
>> Sadly that's valid JSON, but can't be parsed, 
> 
> Huh? If it is valid JSON then certainly it must be parsed!
> 
>> as it would parse to:
>>
>> {
>>   "@id": "x",
>>   "y": "c"
>> }
> 
> I don't understand how some input can "parse" to some other input.
> 
>> Overriding the previous two values, each object can only have one unique 
>> key.
> 
> Umm, where is this behaviour specified?
> 
> [...]
> 
>>>>>> 2: constrain object keys [I think that you mean names here] to be strings with no white space
>>>>> Why?  IRIs should be able to handle (escaped) white space so I don't see
>>>>> what the problem is.
>>>> Specifically I'm referring to the "string" in
>>>>   pair
>>>>    string : value
>>>>
>>>> from the JSON spec, less formerly this would be the "key" in the below:
>>>> {
>>>>    "key": "value"
>>>> }
>>> Where is this from?  I don't see "key" anywhere important in JSON.
>> The "string" in the above pair ( string : value ) is commonly referred 
>> to socially as the "key" in a "key"/"value" pair, also property, 
>> attribute and so forth.
> 
> I would really like a document that puts all this down.   Otherwise how
> can the WG determine what should be done with respect to JSON?
> 
>>>> JSON allows whitespace in the keys:
>>>> {
>>>>    "key foo bar": "value"
>>>> }
>>> Sure, but isn't this just
>>>
>>> [ <...key%20foo%20bar> "value" ]
>> well we haven't defined if it is or is not :) we could also treat it as 
>> syntax sugar for multiple space separated keys, as with relLists in HTML 
>> rel="key foo bar".
> 
> Is this actually allowed in JSON?  If so, where is it stated?
> 
> [...]
> 
>>>>>> 5: add recognition for a special "@vocab" property who's value is an IRI 
>>>>>> (when present, each key [name?] in that object is concatenated to the @vocabs 
>>>>>> value to form the IRI of the property)
>>>>> What @vocabs value?  Is @vocabs something special for JSON?  
>>>> @vocab singular sorry, special to this proposed data/media type.
>>>>
>>>>> Perhaps you mean that "@vocab" is something like a local base URL.
>>>> like @vocab in RDFa:
>>>>   http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#A-vocab
>>>>
>>>>> What about namespaces?
>>>> no namespace support proposed.
>>> Hmm.  Why not?
>> In all honesty, to preserve the beloved . notation in JSON.parse'd 
>> output, and because certain would be adopters (like the browser vendors 
>> and HTML5 WG) have a /real/ problem with the indirection, spanning way 
>> back to the HTML5/XHTML2.0 split and general hatred of @xmlns. Sigh, the 
>> issues run deep throughout the communities.
> 
> What . notation?  I haven't seen any JSON document that talks about it at all.
> 
>> An alternative is:
>>  
>> http://www.w3.org/2011/rdf-wg/wiki/JSON_Syntax_Options#TERMs_.28with_colon_allowed.29
> 
> 
> 
>>>>> What about the special properties?  Are these expanded this way?  (They
>>>>> can't be, of course.)  But then, why not just do something like have
>>>>> prefixes and then rdf:type can be treated just like any other property?
>>>> This was a specific trade-off, see:
>>>>  
>>>> http://www.w3.org/2011/rdf-wg/wiki/JSON_Syntax_Options#TERMs_.2B_Single_Vocab
>>> What other limitations are there in this proposal?  I think that it
>>> would be a good idea to list them all.
>> will do, if there's any point that is!
> 
> Well, they need to be laid out sometime (and soon, I think).  Otherwise
> how can the WG decide whether the proposal is worthwhile?
> 
>> cheers,
>>
>> Nathan
> 
> peter
> 
> 
>

Received on Thursday, 24 March 2011 13:39:31 UTC