Re: [JSON] Tiny Proposal

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 11:39:57 UTC