RE: Options for a JSON CSDL format

Ralf,

 

What about JsonML?

 

  http://www.jsonml.org/

 

From: Handl, Ralf [mailto:]

Sent: Monday, 22 September 2014 7:28 p.m.

To: 

Subject: Options for a JSON CSDL format

 

Hi all,

 

I see two ideas floating around at the moment:

1.      
Define a loss-less JSON representation of CSDL, use JSON Schema to define the JSON $metadata format

2.      
Make use of JSON Schema itself to generate schemas for the various JSON message formats that result from a given CSDL document

 

The first option is along the lines of what we do with the current XML format: we defined a “custom” representation of the logical CDSL constructs, and we defined this representation
 with XML Schema. 

 

We did not (yet) try to derive XML Schema files for the various XML (Atom) message formats from the logical data model represented in CSDL XML.

 

One way to go would be to tackle 1) first, then go for 2) by adding e.g. new top level resource $schemas containing the schemas for each message (e.g. Customer, Collection
 of Customer, Product, Collection of Product, …). This $schemas could be a single “document” with “chapters” for the individual messages, or a “folder” with lots of “schema files” inside.

 

 

For 1) we already have two suggestions: the experimental XSLT transformation linked in
https://issues.oasis-open.org/browse/ODATA-589, and the internal _javascript_ representation used by the Apache Olingo OData Client for _javascript_ (http://olingo.apache.org/doc/_javascript_/index.html)
 and its precursor datajs (http://datajs.codeplex.com/).

 

Both are straight-forward translations of XML to JSON, and consequently rather similar to look at. An optical difference is that odatajs/datajs translates all CSDL terms
 into lowerCamelCase, i.e. “entityTypes” instead of “EntityTypes” etc. A more substantial difference is how annotations are represented: odatajs/datajs continues with a straight-forward translation whereas the XSL transformation uses OData JSON’s style for
 inline annotations, e.g. “@Core.Description”:”This is a description”.

 

 

What further ideas and suggestions do we have?

 

Thanks in advance!

--Ralf

 

        In preparing for battle

        I have always found that plans are useless,

        but planning is indispensable.

        - Dwight D. Eisenhower