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
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--