GerixSoft

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:

I am astonished of FOR XML feature in MSSQL. Oracle, despite claiming they had XML support first, has nothing like that; and XML support in PgSQL and MySQL is just ridiculuos:

In my previous article "What XSLT Processor is the Fastest?" I have benchmarked performance of MSXML, XslCompiledTransform, Saxon, Xalan and XSLTC processors. The test case was XML Pipeline transforming 14mb XML file — Saxon was the winner.

In this article, I will explain why Saxon wins, despite MSXML is implemented in C/C++ and .NET XslCompiledTransform is compiling.

What is the fastest XSLT processor on the planet?

• Is it MSXML because it is implemented in C/C++??
• Is it .NET XslCompiledTransform because it compiles XSLT stylesheets??
• Or perhaps it is Xalan XSLTC :)

Why just not benchmark...

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).

XSLT name() function is evil and should be avoided just like GoTo.

For example, it is very bad to write

The XML Pipeline in XSLT technique requires every xsl:template and xsl:apply-templates in the chained stylesheet to have mode attribute.

This could be simplified if XSLT would allow specifying mode in xsl:include. So <xsl:include href="link1.xsl" mode="link1"/> would mean "use link1 as default mode in link1.xsl":

In this article I will show the most efficient way of implementing XML Pipeline using native XSLT capabilities.