W3C home > Mailing lists > Public > public-exi@w3.org > September 2015

RE: Comments on JSON Schema of XSLT working group

From: Takuki Kamiya <tkamiya@us.fujitsu.com>
Date: Wed, 23 Sep 2015 15:12:37 -0700
To: "Peintner, Daniel (ext)" <daniel.peintner.ext@siemens.com>
CC: "public-exi@w3.org" <public-exi@w3.org>
Message-ID: <23204FACB677D84EBD57175AB7B5A71C02E5829C2FF1@FMSAMAIL.fmsa.local>
Hi Daniel and all,

As types such as decimal, integer and dateTime are commonly assumed
in many use cases if not all, it is sensible to have them available
in a manner that makes their usage as efficient as possible.

Therefore, I agree with the current approach of making them all
explicit in the schema and avoid depending on xsi:type castings.

Furthermore, I think we expect the schema to be used in strict mode 
most of the time because valid JSON documents translate into valid EXI 

If that is the case, we may want to consider using nested elements to 
represent some typed elements to group them together. Nested elements 
do not cost extra with strict EXI grammars. For example, gYearMonth, gYear,
gMonthDay, gDay and gMonth can be grouped within <lessCommon> element.
The benefit is to make the representation of more common types even
more efficient by making the bits to distinguish them fewer.

Thank you,

Takuki Kamiya
Fujitsu Laboratories of America

-----Original Message-----
From: Peintner, Daniel (ext) [mailto:daniel.peintner.ext@siemens.com] 
Sent: Tuesday, September 15, 2015 6:41 AM
To: public-exi@w3.org
Subject: Comments on JSON Schema of XSLT working group


let me be the first to move a technical discussion to the public mailing list.

In the recent past we have been analyzing various ways to support JSON data in EXI. One straight-forward approach is to map JSON data to XML [1] by making use of an XML Schema [2] just like XSLT 3.0 does.

In the ideal case we could just use this schema "as is". However, we have been studying the schema [2] and would like to propose an extension so that EXI can make use of its datatype representations (i.e., represent dateTime values like "2014-02-04T18:50:45" more appropriately [3] than just as String).

Attached a diffed version of my proposed changes (see diff.htm). The HTML shows in orange the changes. On the left hand side one can see the original and the right hand side there is the updated XSD.

Please let me walk through the proposed changes and/or comments.

(*) The three orange sections are about the element "other" and its type "otherType". This opens EXI the possibility to use specific type-codecs for certain values. e.g., one can use the hexBinary element to encode binary data instead of xs:string or integer values encoded as integers and not as xs:double et cetera.

(*) The attributes "escaped" and "escaped-key" are XSLT specific and not necessary for EXI but do not hurt either.

I personally think these changes are important to have an optimal and easy EXI encoding.

An alternative to the current changes is about changing the type of element string from "j:stringType" to "xs:anySimpleType". This allows one to use the <string> element and cast it to an alternative type. e.g., <string xsi:type="xs:dateTime">2014-02-04T18:50:45</string>.
That said, it is possible but less compact and also less simple to implement.

Let us discuss next what is the appropriate way to proceed and get in touch with the XSLT group.


-- Daniel

[1] http://www.w3.org/TR/xslt-30/#json
[2] http://www.w3.org/TR/xslt-30/schema-for-json.xsd
[3] http://www.w3.org/TR/exi/#encodingDateTime
Received on Wednesday, 23 September 2015 22:13:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 23 September 2015 22:13:26 UTC