[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
[xsl] XSLT 3.0 JSON processing -- a few comments from a friend
Subject: [xsl] XSLT 3.0 JSON processing -- a few comments from a friend From: "Dimitre Novatchev dnovatchev@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Wed, 7 Jan 2015 19:49:52 -0000 |
I recently had a chat with an old friend and among other things he expressed some thoughts on the current capabilities of XSLT 3.0 to process JSON. With his kind agreement, I am publishing these thoughts intact. Would appreciate feedback from anybody: 1. What of the below points you agree with, why? 2. What of the below points you disagree with, why? 3. Can you propose a better solution? > In case your interested, here's my honest opinion about XSLT 3.0's JSON implementation... > This is from my perspective - working with systems that heavily utilise JSON both for external facing > APIs and internally within our systems (both for storage and data interchange within a micro- > services architecture. > > The only way to read JSON is to convert it to XML - using the json-to-xml() function. > There are several issues with this... > > ( a ) the JSON must be passed as a whole string to that function (no means to stream it in) > > ( b ) the XML produced is rather ugly (see http://www.w3.org/TR/xslt-30/#json-to-xml-mapping) - if > anyone working in the XML domain saw that representation of data they'd probably laugh... where > the type of data becomes the element name and the name of the data becomes an attribute value... > yack! > > ( c ) for some odd reason the design of this deceided to use the word 'map' to describe 'object'. Whilst > they are the same thing, the vast majority of people using JSON would refer to it as an 'object' (see > http://json.org/) > > ( d ) JSON can use any unicode character in strings, e.g. U+0000 and U+000C (form-feed) are legitimate > characters in a string. I don't see how XSLT can possibly accomodate this as it follows the allowable > characters in XML - which exclude such codepoints. > > The other issue that I have with the incorporation of JSON > into XSLT 3.0 is that I think it has been done without consideration to the ecosystems in which JSON > tends to live. > JSON is often used as a data interchange format within RESTful APIs - which is the 'modern' way to > integrate systems. Indeed, many APIs will offer the choice between XML and JSON. > But here's where it falls over... in such systems, the data from RESTful style APIs is delivered over > HTTP... and utilises the HTTP protocol. The only way in XSLT to utilise HTTP is to use the document() > function et al - but these functions do note expose the required capabilties to adequately deal with > communication with a HTTP base API - for example, no way to set request headers or read resonse > headers (and no way to determine the status code of responses). > This also means that, even for an XML based web-service, XSLT does not provide a coherent way to > deal with modern RESTful style web-services -- Cheers, Dimitre Novatchev
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Saxon.js on the server?, Rob Koberg rob.kober | Thread | Re: [xsl] XSLT 3.0 JSON processing , Michael Kay mike@xxx |
Re: [xsl] Saxon.js on the server?, Rob Koberg rob.kober | Date | Re: [xsl] XSLT 3.0 JSON processing , Michael Kay mike@xxx |
Month |