Bundled Ant means (almost) no extra downloads, and the recently added ${ps} editor variable for the path separator for the current platform means that a single “External Tool” definition works for both Linux and Windows (where previously I needed two definitions that differed only in using “:” or “;”). Continuing with the trick of using <oXygen/> editor variable names in the Ant build file, the command line  that I use (with line breaks added for clarity) is:

java -Dant.home="${oxygenInstallDir}/tools/ant"
-cp "${oxygenInstallDir}/tools/ant/lib/ant-launcher.jar"${ps}
"${oxygenInstallDir}/tools/ant/lib/ant.jar"${ps}
"${oxygenInstallDir}/tools/ant/lib/ant-trax.jar"${ps}
"${oxygenInstallDir}/lib/saxon9ee.jar"${ps}
"${oxygenInstallDir}/lib/saxon9-ant.jar"
org.apache.tools.ant.launch.Launcher
-f ${pd}/tests/build-xspec.xml -Dpd=${pd} -Din=${cfne} run

The only extra download is saxon9-ant.jar, which I added to my <oXygen/> installation so I could use a Saxon-specific Ant task. You can still run Ant, but not the Saxon Ant task, from <oXygen/> if you don’t have it, and it may yet come with a future release.

The talks are:

• What XSL 2.0 means for implementers and users — Discusses the changes that will have to take place under the hood of any XSL formatter that supports XSL 2.0 and what those additional capabilities can bring to your stylesheets.
• Real time, all the time, ragtime XML — An update on the capabilities of Xcruciate.

• Testing XSLT — An update and expansion of my previous talk on testing XSLT presented in less time.  How can that be?  Simple, really: put more in the conference paper, direct attendees to the paper, and spend more of the presentation doing demonstrations.
• Imagining, building and using an XSLT virtual machine — The why and what of the open source Xcruciate XML-based server.  Or the why, what, and Howe of Xcruciate, since I’m the second presenter with Mark Howe of Cyberporte, who provides the ideas behind Xcruciate and its related projects.

Does anybody know of an open source toolkit that can produce that sort of graphical representation?

This example is from the <oXygen/> “project” that I used for organising the exercises for my “Testing XSLT” tutorial at XTech 2008. The tutorial exercises included using <oXygen/> as one of three ways to profile XSLT stylesheets, but I set up an <oXygen/> project that includes the XML and XSLT files for all exercises, too, so things would ‘just work’ (a useful feature considering the tutorial was allocated half the time originally proposed). The project included several “External Tool” definitions, including several for running Ant. This example is the setup for an external tool for running the Tennison Tests XSLT unit testing framework:

The complete command line is:

java -Dant.home=${pd}/apache-ant-1.7.0
-cp ${pd}/apache-ant-1.7.0/lib/ant-launcher.jar:${oxygenInstallDir}/lib/saxon9.jar
org.apache.tools.ant.launch.Launcher -f ${pd}/build-tennison-tests.xml -Dpd=${pd} test

Extensions beyond the necessarily simple example in the <oXygen/> documentation include:

• Using an “Editor variable” for the working directory. Using ${cfd} executes the command in the directory of the current file, but you could also use the project directory (${pd}), your home directory (${home}), or the <oXygen/> installation directory (${oxygenInstallDir}, though it’s likely you can’t and/or won’t want to create files there).
• Running Ant (nearly) independently of the operating system. The documentation example uses ant.bat, which is fine for Windows users, but I didn’t know which operating systems the people would be using. Running Ant via Java works the same way for all platforms unless you need more than one jar file in the classpath. With multiple jars, you need the OS-specific path separator (‘:’ for Unix/Linux, ‘;’ for Windows), so I had to make a Windows-specific version of this external tool that was identical except for the path separator. (Note that Ant is located relative to the project directory in this example because I included Ant in the software bundle for the exercises, again because I couldn’t be sure what the attendees already had installed.)
• Using jars from the <oXygen> lib directory. This usefully saved me from having to install additional copies of the jars and, if you’re being maximally <oXygen/>-centric, it ensures that you get consistent results whether running the same transform in <oXygen/>’s debugger, profiler, or transformation scenarios or in the external tool.
• Locating the build file relative to the project directory. The -f ${pd}/build-tennison-tests.xml makes Ant use that particular build file (out of several) in the project directory, irrespective of the current working directory.
• Using <oXygen/> editor variables in the Ant build file. The -Dpd=${pd} defines an Ant ${pd} variable that has the same value as the <oXygen/> ${pd} editor variable. This value defined on the command line overrides the default value set in the build file. You can do the same for as many of the <oXygen/> editor variables as you need; for example, you could use ${oxygenInstallDir} when you want to use jars from <oXygen/>’s lib directory in classpaths in Ant. The other thing you need to do is define the variables in the Ant build file, e.g.:

  <!-- <oXygen/>-related properties. -->
  <property name="pd" value="."/>
  <property name="cfd" value="."/>

The build file is still usable outside <oXygen/>. In the ordinary case, you would have Ant installed in a common location (rather than one copy per project) and would have the ant executable on your path. Since my ordinary Ant has Saxon in its classpath, I can run the same command in the project directory as:

ant -f build-tennison-tests.xml test

or from any other directory (for slightly more effort) as:

ant -f path/to/pd/build-tennison-tests.xml -Dpd=path/to/pd test

In the Unicode Standard 2.0, there was no mention of U+FEFF with UTF-8, either in the section on the BOM or in the appendix defining UTF-8.

In the Unicode Standard 3.0, section 13.6, “Specials”, includes:

Although there are never any questions of byte-order with UTF-8 text, this sequence can serve as signature for UTF-8 encoded text where the character set is unmarked.

In the Unicode Standard 5.0, section 3.10, “Unicode Encoding Schemes”, includes:

While there is obviously no need for a byte order signature when using UTF-8, there are occasions when processes convert UTF-16 or UTF-32 data containing a byte order mark into UTF-8. When represented in UTF-8, the byte order mark turns into the byte sequence <EF BB BF>. Its usage at the beginning of a UTF-8 data stream is neither required nor recommended by the Unicode Standard, but its presence does not affect conformance to the UTF-8 encoding scheme. Identification of the <EF BB BF> byte sequence at the beginning of a data stream can, however, be taken as a near-certain indication that the data stream is using the UTF-8 encoding scheme.

So in the Unicode Standard it’s gone from irrelevant to useful to “Oh, if you must”.

(BTW, in other reinterpretations, “Unicode Encoding Scheme” results from splitting the meaning of “UTF”, and the use of U+FEFF to indicate non-breaking is deprecated these days.)

The Unicode FAQ both lists its use as a signature and says to avoid its use where “byte oriented protocols expect ASCII characters at the beginning of a file“. However, I don’t think that XML necessarily counts as one such byte oriented protocol.

The Cygwin xsltproc and xmllint complain when you use them with files containing Windows drive names in system identifiers, so the second time it happened, I wrote a simple XML catalog file to map the Windows drive names to the Cygwin paths.

Put this as the contents of /etc/xml/catalog (not catalog.xml!) and the Cygwin xsltproc, etc., will handle Windows drive names:

<?xml version="1.0"?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<rewriteSystem
systemIdStartString="file:///C:/"
rewritePrefix="file:///cygdrive/c/"/>
</catalog>

You will have to add a suitable rewriteSystem for each additional drive that you use.

XML is just a linear syntax for unranked, ordered and labeled trees.

XML—which amounts to some fundamental Lisp data structures reinterpreted by people with bad taste brainwashed by inflexibility.