[oslc-cm] [oslc-core] Problem with OSLC v1 style JSON representations

[Steve K Speicher]

Dave wrote on 03/03/2010 12:51:51 PM:

> In the OSLC v1 specs, the JSON representations do something that seems
> unusual and problematic to me. Here is an example of the type of
> representations we specify in the v1 specs:
> 
>     {
>         "rdf:about": "http://example.com/sillyness/2314",
>         "dc:title": "Silly example BR549",
>         "dc:creator": "John Bonham",
>         "dc:creator": "Keith Moon"
>     }
> 
> One of the most attractive features of JSON is that JSON data can be
> easily parsed into JavaScript objects (see also
> http://www.json.org/js.html) but our representation prevents this from
> working for two reasons:
> 
> 1) The use of colons in the field names does not work in JavaScript; a
> JavaScript variable cannot have a colon in its name.

For reference, I believe the OSLC v1 spec you are referring to is: 
http://open-services.net/bin/view/Main/CmJsonFormatV1

It actually can have a colon in the name, you just can't access using 
shorthand.

Take for example "dc:title", 
for simplified legal JavaScript/Java identifiers you can do the shorthand:
        changerequest.title
though the alternate method is legal and more flexible:
        changerequest["dc:title"]

In our Rational products we make extensive use of this and explicitly 
allow custom attribute identifiers like 
"com.ibm.team.apt.attribute.complexity", which require the lengthier 
notation regardless of namespaces.

> 2) We allow multivalued properties, but you cannot have two variables
> with the same name in a JavaScript object.

I'm not aware of this limitation, as it the sample you give above is legal 
JSON.  I'd have to check with someone who has more experience with this 
but haven't heard of any issues with this.

> If you take a look at the OSLC Core Spec draft section below you can
> see what I am proposing as an alternative to the v1-style JSON
> representations. It does not suffer from the above two issues:
> 
>    http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT?
> sortcol=table;up=#JSON_Representation
> 

At first read, it seems like it is avoiding JSON constructs to invent some 
of its own and there is additional levels of indirection.  As you point 
out, you'd have to ensure you access the properties in a predefined way. I 
will do a more in depth look at this when I can.

- Steve