13.3. XT

James Clark has been a driving force in specification design and authorship for markup technology. He was instrumental in the codification of the W3C specification for XSLT as its editor and was also principle author of the W3C specification for XPath. His processor, XT, is universally acknowledged as far and away the leanest, meanest, and fastest. It was no small shock to the markup community when he announced that he is no longer building revisions and upgrades. There is a list at the end of this section of the limitations in XT, as documented on James Clark's Web site. There is good news, however; a group called 4XT is taking on the task of developing XT further, and their Web site, http://www.4xt.org, documents their efforts.

Clark's XML parser, XP, is also highly regarded and is the default in countless implementations for this reason. In addition, XP allows comments to be passed to the application.

XT is designed as a filter for SAX, the Simple API for XML. It is a parallel technology to the DOM and has some distinct advantages over DOM, apart from the wide industry base of preference for SAX. XT takes the stream of SAX events from the XML processor e.g., XP as input, and outputs them to the result tree as an additional stream of SAX events.

It is well worthwhile to begin with XT simply due to its speed, and then move to another processor if and when additional functionality is required. Note that while XT conforms meticulously to the W3C specification for XSLT and XPath, as you might expect from a processor born of the editor for both specs, it does not implement all of the spec, most notably and regrettably omitting support for key(). In addition, <xsl:fallback>, <xsl:namespace-alias> element, the extension-element-prefixes attribute, and the element-available() function are not implemented. The optional third argument to format-number() and the <xsl:decimal-format> element are not supported. XT does not allow access to the namespace axis and you cannot add the xsl:exclude-result-prefixes attribute to literal result elements (it is allowed on the document element, however).

XT has a simple executable for Windows that runs in the same way as Instant Saxon. If you use it with a JVM other than the Internet Explorer engine, you will need to modify CLASSPATHS. When you download XT from Clark's site, the XP processor comes with it, so we will describe the installation of both together.

13.3.1. Installing XT for Windows

Download the xt.exe file from James Clark's site at http://www.jclark.com. You do not need to add any extra parsers or to modify PATH or CLASSPATH, provided you have IE 4+ (IE 5 recommended) on your Windows 95, 98, or NT/2000 machine. Unzip the file in a directory where you plan to use XT and you are ready to go.

To run Instant XT on Windows, select Start, Applications, MSDOS, and in the window, run it with the following syntax:

xt source.xml stylesheet.xsl output.xml [name=param]

The name is a name value for inserting a parameter's value at runtime, with the syntax of param=value, with name as the parameter's name declared in <xsl:param>, and value as whatever value you assign at runtime. In place of the parameter, you can stipulate the name of your output file.

13.3.2. Installing XT and XP on UNIX

If you are running XT, you will need the JDK 1.2 (1.1.6+ will do, but is not recommended) installation, described in Chapter 12. You will also need XP, which is included with the download of the XT processor from James Clark's site. The core program for working with the objects is a JAR file, xt.jar, which you must include on your CLASSPATH. We will continue to work with the model introduced in Chapter 12, which assumes you will put this in a /usr/bin directory, likely called /usr/bin/XT.

If you have followed the instructions above, you will have JDK 1.2.2, which will work fine. The following examples assume that you will use the default xp.jar XML processor and that you have put it in your directory with Saxon.

At the very least, you must include xt.jar and xp.jar on the system CLASSPATH. Thus, where you had a basic “." you would modify it as follows:

13.3.3. Installing XT and XP on Macintosh

First, you need to download the Java for Mac that has JBindery. It comes with the MRJ SDK. You can find the MRJ 2.1 SDK (Macintosh Runtime for Java Software Development Kit) for free at http://developer.apple.com/java/text/download.html#sdk (it takes a few minutes from home, less on Ethernet). Now install it by double-clicking the icon and following all the automatic presets. When it's done, you will see the MRJ SDK 2.1 directory on your hard drive, with a JBindery folder (if not, trash MRJ, reinstall with custom, and select all components).

Now you need the files for XT, from James Clark's site. Be sure to choose the Java versions, not the Windows. You will need XT and XP. Get them from http://www.jclark.com/xml/xt.html, or get direct anonymous FTP from ftp://ftp.jclark.com/pub/xml/xp.zip and ftp://ftp.jclark.com/pub/xml/xt.zip. Unzip these and put all the XT files in one folder called “xt” inside the JBindery folder which is nested several folders inside of the MRJ folder (inside MRJ is a folder called Tools, and one called Application Builders. It is inside the Application Builders where you will find the JBindery folder) on your hard drive. Do the same with XP (except put its files in the JBindery folder in their own folder called “xp”).

If you want to make your own applets after you have more experience with XSLT, and change the input and output filenames, just run JBindery itself and change the filenames in the Command window, as shown in Figure 13-1.

Then Save as Application in the JBindery folder with whatever name you wish, which means you can then run these applets by double-clicking the application (that is, as long as you are not changing the input, stylesheet, and output filenames).

You may also encounder Not Found/Directory Path errors. That comes from a trickier screen. If you look at the JBindery window, the lefthand icon list has a Properties icon, and this could be a source of troubles. You need to add the following two lines to the bottom left and bottom right windows (it'll spill over the viewable space of the window, so type carefully), respectively:

If done correctly, it should look like the window in Figure 13-2. The top large window fills in of its own accord as you use JBindery.

You should also have the appropriate .jar files in your CLASSPATH window. Assuming you've unzipped stuff all to the JBindery directory, your window should look like Figure 13-3.

If it does not, use the Add .zip File button to select the appropriate .jar files, as shown through the Finder interface it provides.

It's important to remember that you will primarily use the JBindery folder while you're learning. Over time, as you gain confidence, you will likely want to work with different directories and the JBindary folder will likely get very crowded!

13.3.4. XT Extensions

XT implements one extension element: <xt:document>, and one extension attribute: xt:nxml. It also includes three extension functions: node-set(), intersection(), and difference().

The XT namespace must be declared if any extensions are to be used. The following example shows the proper way to declare the XT namespace:

xmlns:xt="http://www.jclark.com/xt"

13.3.4.1. The xt:nxml Extension Attribute

The xt:nxml value for the method attribute on <xsl:output> enables certain specific non-XML characters to be output which simply using <xsl:output> with method set to text would not allow.

Using xt:nxml as the output method stipulates a number of subelements to mark characters for a sort of “escaping” so the processor and parser do not signal an error. These subelement are shown in Table 13-5.

James Clark's XT documentation shows the following example of using the xt:nxml method:

<xsl:stylesheet

  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xt:nxml" xmlns:xt="http://www.jclark.com/xt"/>
<xsl:template match="/">
<nxml>
<escape char="">\</escape>
<data>&amp;&lt;&gt;</data>
<control>&amp;&lt;&gt;</control>
</nxml>
</xsl:template>
</xsl:stylesheet>

This will generate the following output:

&<>\&<>

13.3.4.2. The <xt:document> Extension Element

The <xt:document> element is used to produce multiple output files from a single XML document instance. It has a mandatory href attribute whose value must be the relative URL for an output file. Its value can be interpreted as an attribute value template. In addition, all the same attributes that are allowed on the <xsl:document> element can be used with <xt:document>.The content of the <xt:document> element is a template, as shown in the following element model definition.

<!-- Category: instruction-element -->
<xt:document
  href = { uri-reference }
  method = "xml" | "html" | "text" | qname-but-not-ncname
  version = nmtoken
  encoding = string
  omit-xml-declaration = "yes" | "no"
  standalone = "yes" | "no"
  doctype-public = string
  doctype-system = string
  cdata-section-elements = qnames
  indent = "yes" | "no"   media-type = string >

  <!-- Content: template -->
</xt:document>

See Section 13.4 for an example of an XSLT stylesheet designed for multiple-document output from either Saxon, Xalan, or XT.

13.3.4.3. The node-set() Extension Function

Function: node-set
							node-set
							($fragment)
						

This function takes a result tree fragment and converts it to a node-set. This function provides the ability to choose parts of the result tree while it is still in process and treat those parts with additional template rules. The function return type of this function is node-set, and its one required attribute is a node-set.

13.3.4.4. The intersection() Extension Function

Function: node-set
							intersection
							(node-set-1, node-set-2)
						

This function returns a node-set containing the nodes common to two node-sets. Nodes from the first argument that are also found in the node-set in the second are returned as a new node-set. This function has two required arguments, both of type node-set, and its function return type is also a node-set.

13.3.4.5. The difference() Extension Function

Function: node-set
							difference
							(node-set-1, node-set-2)
						

This function returns a node-set containing the difference between two node-sets. Nodes from the first argument that are not found in the node-set in the second are returned as a new node-set. This function has two required arguments, both of type node-set, and its function return type is also a node-set.

13.3.5. XT Limitations

James Clark list the limitations and known bugs for the XT processor as follows. The following features of the XSLT PR are not yet implemented:

• the element extension mechanism (the extension-element-prefixes and xsl:extension-element-prefixes attributes, the <xsl:fallback> element, and the element-available() function)

• keys (the <xsl:key> element, and the key() function)

• the <xsl:decimal-format> element and the optional third argument on the format-number() function

• the namespace axis

• forwards-compatible processing

• the xsl:exclude-result-prefixes attribute on literal result elements (the exclude-result-prefixes attribute on <xsl:stylesheet> is implemented)

• The xml output method ignores the encoding and cdata-section-elements attributes on <xsl:output>.

The following are some known bugs:

• Many errors that the XSLT specification requires to be reported are silently ignored.

• Comments and processing instructions occurring in the DTD are not excluded from the data model.

• The node() node-test does not work in match patterns (it does work in expressions).

• The document() function does not pay attention to the HTTP content-type header.

• The <xsl:import> element does not conform to the requirement that when xsl:include is used to include a stylesheet, any <xsl:import> elements in the included document are moved up in the including document to after any existing <xsl:import> elements in the including document.

• The HTML output method may get confused if you embed namespace-qualified XML elements with the HTML.

Improvement is needed in the following areas:

• The implementation of the <xsl:number> element is slow.

• Error reporting is often not as helpful as it might be.

• No error recovery is attempted after an error is reported.

• The document() function does not support fragment identifiers in URIs for any media types.