Re: JSON Schema

Daniel (and the rest of the EXI group)

We discussed this today in the joint XSLT/XQuery group telcon, and I was asked to respond on behalf of the joint groups.

Achieving reuse of common pieces of specification is obviously a good idea in principle, but there can be practical difficulties.

The most obvious technical difficulty on our side is that the specification of the fn:xml-to-json function uses this schema to define the domain of the function; the function produces well defined output if the input conforms to this schema, and throws an error otherwise. Defining the function’s domain would become much more complicated if the schema were to contain extensions defined for a different purpose.

There is also, we think, a non-technical issue concerning the difficulty of maintaining change control of an artefact like this in which multiple groups have a shared interest.

I have considered whether, perhaps, the requirement could be met by defining suitable extension points within the schema. For example, the xs:choice elements within arrayType and mapType could be extended with wildcards: <xs:any namespace=“##other” processContents=“lax”/>. However, even this would require some change to our function specification to explain how to handle the additional possibilities that this schema allows, which would not be welcome at the present stage of development.

We would suggest that you instead consider defining your schema as a variant of ours, defined using the XSD 1.1 xs:override mechanism.

I hope this provides a way forward.

Regards,

Michael Kay




> On 1 Oct 2015, at 14:52, Peintner, Daniel (ext) <daniel.peintner.ext@siemens.com> wrote:
> 
> Hi XSLT folks,
> 
> I am getting in touch with you on behalf of the EXI working group.
> 
> 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 our 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 for EXI the possibility to use specific type-codecs for certain values. e.g., one can use the base64Binary 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 and I also think we should avoid having different schemas.
> Hence we would like to start discussing these issues with you to get further feedback.
> 
> 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
> <diff.htm>

Received on Tuesday, 27 October 2015 17:34:13 UTC