RE: JSON Schema

Hi Michael,

Thank you for communicating with us the conclusion of the discussion.

Given that, in today's EXI telecon, we discussed which option we should 
choose to take to go forward.

EXI at its current version 1.0, still strictly depends on XSD version 1.0. 
Therefore, use of xs:override does not seem to be an option for us.

We are aware that XSD 1.0 has xs:redefine, however, the use of it does not 
appear very attractive at this point because the feature is deprecated in 
XSD 1.1.

We further discussed, given that the size of the schema is relatively small, 
the expected the task of maintaining the whole schema ourselves would not be
very costly. Therefore, we now tend to conclude the best option may be to
create our version by adopting the whole schema from XQuery/XSLT then tuning
it inline by hand. We plan to use separate target namespace for it to avoid 
confusion in the future.

Best regards,

Takuki Kamiya
Fujitsu Laboratories of America



-----Original Message-----
From: Michael Kay [mailto:mike@saxonica.com] 
Sent: Tuesday, October 27, 2015 10:33 AM
To: Peintner, Daniel (ext)
Cc: public-xsl-wg@w3.org; public-exi@w3.org; Public Joint XSLT XQuery XPath
Subject: 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 Wednesday, 11 November 2015 18:14:20 UTC