XML template engine

A XML template engine (or "XML template processor") is a specialized template processor for XML input and/or output, working in a XML template system context. There are two main types:
* "XML-suite standards" compliant engines:
** "XSLT engines", named also "XSLT processors"
** "XQuery engines", named also "XQuery processors"
* Others, like Web template engines

XSLT processors

XSLT processors may be delivered as standalone applications, or as software components or libraries intended for use by applications. Many web browsers and web server software have XSLT processor components built into them.

Most current operating systems have an XSLT processor installed. For example, Windows XP comes with the MSXML3 library, which includes an XSLT processor.

Optimizations

Early XSLT processors had very few optimizations; stylesheet documents were read using the Document Object Model and the processor would act on them directly. XPath engines were also not optimized.

By 2000, however, implementors saw optimization opportunities in both XPath evaluation and template rule processing. For example, the Java programming language's Transformation API for XML (TrAX), later subsumed into the Java API for XML Processing (JAXP), acknowledged one such optimization: before processing, the XSLT processor could condense the template rules and other stylesheet tree information into a single, compact Templates object, free from the constraints and bloat of standard DOMs, in an implementation-specific manner. This intermediate representation of the stylesheet tree allows for more efficient processing by potentially reducing preparation time and memory overhead. Additionally, the formal API allows for the object to be cached and reused for multiple transformations, potentially providing higher performance if several input documents are to be processed with the same XSLT stylesheet. Parallels are often drawn between this optimization and the compilation of programming language source code to bytecode: the stylesheets are said to be "compiled", even though they don't usually produce native programming language bytecode; rather, they produce intermediate structures and routines that are stored and processed internally. [ [http://www-128.ibm.com/developerworks/xml/library/x-xslt2/ Saxon: Anatomy of an XSLT processor] - An article describing the implementation and optimization details of a popular Java-based XSLT processor.]

In contrast, Eugene Kuznetsov (DataPower, IBM) and Jacek Ambroziak (Sun Microsystems: XSLT, Ambrosoft: Gregor/XSLT) have, independently, created the industry's first genuine optimizing compilers to output executable binary output. The approach has two major benefits: 1) the transformation executable can be run anywhere: servers, mobile devices, embedded environments lacking memory for the complete interpreter/compiler system, and 2) the transformation performance may reach the highest possible levels. The optimized compilation approach will lead to fastest transformation execution only when complemented by equally careful runtime system design!

XPath evaluation also has room for significant optimizations, and most processor vendors have implemented at least some of them, for speed. For example, in <xsl:if test="/some/nodes"> the test will evaluate to true if /some/nodes identifies any nodes, so evaluation can stop as soon as the first matching node is found; continuing to look for the entire set of matching nodes would not change the result. Similar optimizations can be undertaken when processing xsl:when and xsl:value-of, as well as expressions relying on, either implicitly or explicitly, string(), boolean(), or number(), and those that use numeric and position()/last()-based predicates.

Implementations

: "Some of these are only libraries for specific programming languages, but some form the basis for command line or shell script utilities for one or more operating systems. Such utilities are either bundled with the libraries or independently maintained, and some are incorporated into other applications, such as database engines and web browsers, in order to add XSLT functionality to them. With the exception of web browsers, such utilities and applications are not listed here." :; Implementations for Java:: [http://xml.apache.org/xalan-j/ Xalan-Java] :: SAXON by Michael Kay:: [http://ambrosoft.com/ Gregor/XSLT] optimizing compiler and runtime by Jacek Ambroziak:: [http://www.blnz.com/xt/ XT] originally by James Clark:: Oracle XSLT, in the [http://www.oracle.com/technology/tech/xml/xdkhome.html Oracle XDK] :; Implementations for the .NET Framework:: Saxon .NET [http://weblog.saxondotnet.org Project Weblog] , an IKVM.NET-based port of Dr. Michael Kay's and Saxonica's Saxon Processor provides XSLT 2.0, XPath 2.0, and XQuery 1.0 support on the .NET platform.:; Implementations for C or C++::: [http://xml.apache.org/xalan-c/ Xalan-C++] :: libxslt the XSLT C library for GNOME:: [http://www.gingerall.org/sablotron.html Sablotron] , which is integrated into PHP4:; Implementations for Perl::: [http://search.cpan.org/~msergeant/XML-LibXSLT-1.57/LibXSLT.pm XML::LibXSLT] is a Perl interface to the libxslt C library:: [http://search.cpan.org/~pavelh/XML-Sablotron-1.01/Sablotron.pm XML::Sablotron] is a Perl interface to the [http://www.gingerall.org/sablotron.html Sablotron] processor:; Implementations for PHP::: [http://no.php.net/manual/en/ref.xslt.php XSLT] is the PHP4 interface to the [http://www.gingerall.org/sablotron.html Sablotron] processor:: [http://no.php.net/manual/en/ref.xsl.php XSL] is the new interface to XSL introduced in PHP5. The extension uses the [http://xmlsoft.org/XSLT/ libxslt] .:; Implementations for Python::: 4XSLT, in the [http://4suite.org/ 4Suite] toolkit by Fourthought, Inc.:: [http://codespeak.net/lxml/ lxml] by Martijn Faassen is a Pythonic wrapper of the libxslt C library:; Implementations for Ruby:: [http://raa.ruby-lang.org/project/ruby-xslt/ Ruby/XSLT] is a simple XSLT class based on libxml and libxslt:: [http://www.rubycolor.org/sablot/ Sablotron module for Ruby] is a ruby interface to Sablotron:; Implementations for JavaScript::: [http://goog-ajaxslt.sourceforge.net/ Google AJAXSLT] is an implementation of XSLT in JavaScript, intended for use in Ajax applications.:; Implementations for specific operating systems::: Microsoft's MSXML library may be used in various Microsoft Windows application development environments and languages, such as Visual Basic, C, and JScript.:: Microsoft offers a new XSLT processor in the System.XML component of the .NET Framework.:; Implementations integrated into web browsers: (Comparison of layout engines (XML)):: Mozilla has [http://www.mozilla.org/projects/xslt/ native XSLT support] based on TransforMiiX.:: Safari 1.2+ has native XSLT support, but Safari 1.2 is [http://developer.apple.com/internet/safari/faq.html#anchor21 unable to perform XSL transformations via JavaScript] , a limitation that does not occur in Mozilla or Internet Explorer, or Safari 3. This limits the capabilities of Ajax applications that would run in Safari 2. Safari's (all varsions?) XML-parser is also not standards-compliant; it will parse XML strings according to "HTML" rules. Therefore, under certain circumstances, it will omit data from the DOM tree if it encounters malformed "HTML" — even though it actually encountered valid "XML". These errors will propagate to XSL-processed DOM trees.:: X-Smiles has native XSLT support.:: Opera has partial native XSLT support since Version 9. Notable exceptions include the absence of the document() function.:: Internet Explorer 6 supports XSLT 1.0 via the MSXML library (described above). IE5 and IE5.5 came with an earlier MSXML component that only supported an older, nonrecommended dialect of XSLT. A newer version of MSXML can be downloaded and installed separately to enable IE5 and IE5.5 to support XSLT 1.0 through scripting, and if certain Windows Registry keys are modified, the newer library will replace the older version as the default used by IE.

References