RE: #Announce published JXML schema, an XML schema for repres

Thanks to both online and offline suggestions,  I’ve updated the specs with the following changes (and tested my toolkit)

Lower case elements

Cleaned up the XSD a bit to use direct types instead of trivial restrictions.

Made null an actual empty element

Still thinking about the string escaping issue.   I was unaware that JSON allowed NUL values in strings, I need to ponder that.

( as well as other Unicode values unallowed in XML even as entities).

This is a minor piece of the framework of a much more comprehensive JSON/XML transformation project I’m working on, so should not be confused with arbitrary XML<->JSON bidirectional transformations.  That’s another beast entirely which I’m trying to tame.

Thank you all for the feedback !

On 03/02/2011 14:08, David Lee wrote:

I’ve had this working for a while but finally got around to publishing the specs.

http://xml.calldei.com/JsonXML

This is currently implemented in the xml2json and json2xml commands in xmlsh (http://www.xmlsh.org)

The goal of this schema is a direct mapping in XML to the JSON data model,  NOT a “nice XML transformation of JSON”.

( I’m working on that separately which I hope to publish later this year).

This is extremely simple (intentionally) and should be easy to implemented in most languages.

----------------------------------------

David A. Lee

dlee@calldei.com

http://www.xmlsh.org

Looks good. I share John's aesthetic objections to upper-case element names.

It would be easy enough to add to the schema the constraint that the names of members in an object must be unique.

It seems rather odd that BOOLEAN should be an enumerated string rather than an xs:boolean.

It also seems odd to use trivial restrictions of xs:double and xs:string rather than using xs:double and xs:string themselves.

You get slightly better schema-aware XSLT and XQuery processing capability if you make "value" an abstract element heading a substitution group, rather than a choice group (it means you can match it using "schema-element(value)").

You need to say whether strings are held in JSON format (with backslashes) or are unescaped. You're damned if you do, damned if you don't: if you try to do unescaping then you hit the nastiness that JSON can contain \0 which can't be represented directly in XML.

We're working on parse-json() and serialize-json() for XSLT 3.0 right now. At present we're converting to new map/array data structures rather than XML trees, but this could well be an alternative.

Michael Kay
Saxonica