AW: Comments on JSON Schema of XSLT working group

All,

during the telecon yesterday the question was raised whether EXI streams generated with the original XML schema (schema-for-json.xsd) can be parsed by EXI processors using the updated XML schema (schema-for-json-exi.xsd).

I did check that and the answer is "no". One example in Strict mode is as follows.
e.g., after the "map" element  the following events are expected

0. key
1. map
2. array
3. string
4. number
5. boolean
6. null
(7. other)
7 (8). EndElement

The new element "other" causes the event code length to change from 3 bits to 4 bits.

A similar issues pops up in non-Strict mode.

-- Daniel





________________________________
Von: Peintner, Daniel (ext) [daniel.peintner.ext@siemens.com]
Gesendet: Dienstag, 29. September 2015 14:18
An: Takuki Kamiya
Cc: public-exi@w3.org
Betreff: AW: Comments on JSON Schema of XSLT working group

Hi Taki, all,

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

I agree with your statements. If we do not have any further comments I suggest getting in touch with the XSLT working group to get their feedback..

> [...]
> 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.

This is definitely something we should consider. Nevertheless, I also think it would introduce slightly more complexity and we should take into account also this aspect.

Thanks,

-- Daniel





________________________________
Von: Takuki Kamiya [tkamiya@us.fujitsu.com]
Gesendet: Donnerstag, 24. September 2015 00:12
An: Peintner, Daniel (ext)
Cc: public-exi@w3.org
Betreff: RE: Comments on JSON Schema of XSLT working group

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
instances.

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

All,

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.

Thanks,

-- 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, 7 October 2015 08:42:31 UTC