OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: Options for a JSON CSDL format



What about JsonML?




From: Handl, Ralf [mailto:ralf.handl@sap.com]
Sent: Monday, 22 September 2014 7:28 p.m.
To: odata@lists.oasis-open.org
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!


        In preparing for battle
        I have always found that plans are useless,
        but planning is indispensable.
- Dwight D. Eisenhower




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]