There are some debates about declining use of XML and rising use of JSON. Some people love XML, some people love JSON. I love SAX: assuming SAX serializer/deserializers exist, anything can be treated as XML.
For example, you can write XSLT stylesheets transforming JSON: JSON SAX deserializer was already created by me in my previous article "How to Convert JSON to XML using ANTLR" and JSON SAX serializer is fairly easy to write. Once you have all that, you can transform JSON using XSLT:
This little tool will download HTML file produced by Mailman/Pipermail, convert it to XML, extract all hyperlinks to monthly archive files, download and concatenate these into one big file ready for import into Thunderbird.
In the previous article I have shown how to convert JSON to XML using XSLT 2.0 capabilities.
The problem w/ implementing parsers in XSLT, is conversion from flat structure to tree structure. XSLT was simply NOT created for such kind of conversions. For example, JSON to XML transformation is using XML Pipeline of mode1, mode2, mode3 to build a tree structure from a sequence of tokens generated by regexp in mode0.
I am pleased to announce XSLT Lint -- a tool for performing static code analysis of XSLT.
Idea of the project is to unscramble poorly coded XSLT, and patch the code accurately, so changes can be viewed nicely displayed line-by-line in file comparison tool.
In my previous article I have shown how to preprocess XSLT using custom SAX ContentHandler that transforms XSLT source code on-the-fly.
The reason SAX transformation was chosen instead of simpler XSLT transformation is because SAX transformations preserve line and column information: if you will make an error in a preprocessed XSLT, XSLT processor will report exact line and column position of the error; if XSLT preprocessing was implemented in XSLT, line and column information would be distorted.
The need to constantly write xsl: prefix, angle brackets, verbose instructions make XSLT syntax somewhat odd for a newbie. Though the fact that XSLT is also an XML is a big plus.
The question is, can XSLT syntax be refactored to resemble syntax of regular programming language, yet without losing compatibility w/ XML?
XSLT 2.0 is powerful enough to process even non-XML input. For example, I have created a transformation that converts JSON text to well structured XML output:
The xsl:include/@mode patchset I have developed to ease XML Pipeline in XSLT is not good. The major problem is it won't work on closed-source XSLT processors (Saxon PE/EE for example).