Re: [xml-dev] XMON

Michael, what is a "JSON tree"? I suppose you mean the data model used to capture the content of JSON text.

Many people take it for granted that a tree of nested arrays and maps is the *natural* way to capture JSON data. (JSONiq is a variant on that theme.) Be this as it may, yet I know from daily experience that it can be tremendously impractical when dealing with really complex data, with many tree levels and very many items. So the choice of a tree of arrays and maps is certainly not always the best one. As we all know - there are also various implementations of parsing JSON data into an XML node tree. A good example is the BaseX extension function json:parse. The resulting documents are as a rule excellently readible, hardly less than ordinary XML data, and the ease of processing is of course exactly the same as when dealing with original XML. You can say things like //offer[.//flight/@isDirect] - and this means say in a half line what would otherwise require much more code, which is less readable, more brittle and much more difficult to maintain.

This is not only a question of "tool chains" enabled (XPath, XQuery, XSLT), in my opinion there is more to it. It means that JSON data parsed into a node tree representation are intuitively, and globally unambiguously, addressable: like XML data.

With kind regards,

Hans-Juergen

Michael Kay <mike@saxonica.com> schrieb am 11:25 Donnerstag, 4.Mai 2017:

It would probably be a good idea to re-read the FtanML proposal at

https://www.balisage.net/Proceedings/vol10/html/Kay01/BalisageVol10-Kay01.html

I don't think it got everything right, but I think it contains some good ideas along these lines.

At the level of tree models I have come to realise that there is a fundamental difference between XML tree models and JSON tree models that has nothing to do with the differences in syntax: XML trees have parent pointers, JSON trees don't. As I tried to show in my XML Prague paper last year, this has surprisingly far-reaching effects on the design of a transformation language.

http://archive.xmlprague.cz/2016/files/xmlprague-2016-proceedings.pdf

Michael Kay

Saxonica

On 4 May 2017, at 07:37, Rick Jelliffe <rjelliffe@allette.com.au> wrote:

XML was ascendant for 10 years and overhyped. The second 10 years of its life its has been descending to be merely used where it is appropriate, which is the best any technology should hope for. Classic hype cycle, I guess.

But in order to thrive, I think it needs to grow and morph into something more. What is the low hanging fruit, that would give a great increase in functionality with the maximum ability to connect to existing technology by small shims?

I would suggest it is to embrace JSON as doing a different but compatible thing to elements and content (apologies if I am just repeating someone else's suggestion): lets prune and embrace!

<?xmon?>

<some-element xml:id="me" class="plenty'
   {
       "name":"Rick", "age":856, "city":"Sydney"
   }
>Hello •<b>World</b></some-element>
<?checksum 0x12356775756?>

I.e., UTF-8, DTD-less, namespace-less XML allowing some well-defined version of JSON in start-tags after attributes. Prefixes useable for open standard vocabularies.

Not WF XML or JSON, but trivially convertable to XML by putting the JSON into an first element <json> or to JSON by pulling in each fragment, or whatever. But the intent would be to use an extended DOM with JSON nodes.

It allows JSON to be used with mixed content and schemas. The XML parts can be accessed with XPath as usual, and so Schematron, RELAX NG, XSD etc come along for the ride.   I expect XSD would be overkill, in that you we can use syntax to express the type rather than needing some kind of post-schema-validation-infoset.

Regards
Rick Jelliffe