W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2011

Re: [JSON] Tiny Proposal

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 05 Apr 2011 19:55:44 -0400
Message-ID: <4D9BAC00.1090507@digitalbazaar.com>
To: RDF WG <public-rdf-wg@w3.org>
A long-delayed set of responses to Andy...

On 03/24/2011 09:43 AM, Andy Seaborne wrote:
>> 1: Constrain JSON [1] to be an (optionally nested) sequence of one
>> or more objects (where one, no enclosing [] is needed).
> 
> I'm not convinced nesting is needed.  Instead, what about a flat
> JSON-[] array of data objects with fields. Linking is up to the app.
> 
> Nesting means there are two ways to write one thing.

Our company is convinced that nesting is needed. That is, we tried the
no-nesting route and our JavaScript developers rejected it. It's seen as
a weakness in the language if what is easy to nest in JavaScript, is
suddenly forbidden in RDF in/on/with JSON.

Just because there are two ways to write one thing doesn't necessarily
mean that is a bad thing. Sometimes, writing it one way is more
efficient/practical/clearer than writing it the other way. That is,
there are multiple ways to express things in TURTLE, HTML+RDFa, etc. -
and that is often seen as a strength, not a weakness.

>> There are currently three JSON grammar serializations, which one
>> should this Working Group use as the basis for the RDF/JSON
>> serialization:
>> 
>> * RFC4627: http://www.ietf.org/rfc/rfc4627.txt * ECMA-262 5th
>> Edition:
>> http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf
>> * json.org: http://json.org/
> 
> How do they differ? Are there real world examples of collisions?

I thought that Peter asserted that they differ - I don't know how they
differ. Perhaps an allusion to the backslash-escaping "/" when you don't
need to?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The PaySwarm Vocabulary
http://digitalbazaar.com/2011/03/31/payswarm-vocab/
Received on Tuesday, 5 April 2011 23:56:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:41 GMT