[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

XSLT 3.0 JSON processing -- a few comments from a frie

Subject: 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
 XSLT 3.0 JSON processing -- a few comments from a frie
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

Dimitre Novatchev

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.