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