XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (731 page)

The above two rules handle standard dates and nonstandard dates respectively. We rely on the type annotation to distinguish the two cases. Note the call on
data(.)
: we want to test the type of the simple content of the

element, not the type of the element itself. So we need to call the
data()
function to get the content.

The final rule, below, is for text nodes within a

element. This uses the

instruction to replace newline characters by


elements, so that the line endings are preserved in the browser's display.

Putting It Together

We now have a stylesheet that can generate an HTML page for a single chosen individual. We don't yet have a working Web site!

As I suggested earlier, there are three ways you can work:

• You can do a batch conversion of the entire data file into a collection of linked static HTML pages held on the Web server.
  
• You can generate each page on demand from the server.
  
• You can generate pages dynamically at the client.
  

I'll show how to do all three; and in the second case, I'll describe two different implementations of the architecture, one using Java servlets and one using Microsoft ASP pages. The main differences among the three cases are in the way hyperlinks are constructed, and we'll achieve this by writing overlay stylesheets that change the relevant logic in the base stylesheet.

Publishing Static HTML

To generate HTML files for all the individuals in the data file, we need some kind of script that processes each individual in turn and produces a separate output file for each one. Here we can take advantage of the XSLT 2.0 capability to produce multiple output files from one input file. Many XSLT 1.0 products had a similar capability, but unfortunately each product used different syntax.

We'll need a new template for processing the root element, and because this must override the template defined in
person.xsl
, we'll need to use

to give the new template higher precedence.

Here is the complete stylesheet,
publish.xsl
, to do the bulk conversion. As well as generating an HTML page for each individual, it also creates an index page listing all the individuals grouped first by surname, then by the rest of the name.

In principle you should be able to run this stylesheet using any XSLT 2.0 schema-aware processor. At the time of writing, however, it doesn't work with Altova. It also hits a bug in regular expression handling when run using any version of Saxon-SA on .NET older than 9.0.0.2.

Assuming you have installed Saxon-SA and set up your classpath, and that you have downloaded the example files from the Wrox Web site, you should now create a new directory, copy the stylesheets and the XML data file into it, make this the current directory, and then run the command:

This assumes that the source files are in the current directory. The
-val
option is necessary to ensure that the source file is validated against its schema; the
-t
option is useful because it shows you exactly where the generated output files have been written. The
dir=d:\jfk
parameter gives the directory in which you want the HTML files to appear.

The specified directory should fill with HTML files. Double-click on the
index.html
file, and you should see an index of names. Click on any of the names to see the screen shown on page 1072, in glorious color. Then browse the data by following the relationships.

Generating HTML Pages from a Servlet

An alternative to bulk-converting the XML data into static HTML pages is to generate each HTML page on request. This requires execution of a stylesheet on the server, which in principle can be controlled using any server-side technology that will host XSLT: PHP, ASP.NET, Java servlets, or even raw CGI programs. However, as many of the available XSLT processors are written in Java, it turns out to be convenient to use servlets.

If you aren't familiar with servlet programming, it's probably best to skip this section, because there isn't space here to start from first principles. There are plenty of good books on the subject.

All the Java XSLT 1.0 processors (there have been at least five, though some are now rarely used) implement the JAXP API, which is described in Appendix E. This means you can write a servlet that works with any processor. Although the JAXP API currently only supports XSLT 1.0, there aren't that many differences at the API level between a 1.0 processor and a 2.0 processor, so you can use this API with minor tweaks to run an XSLT 2.0 processor such as Saxon.

We would like to accept incoming requests from the browser in the form:

However, for links between pages we can generate a relative URL to make the code independent of where the servlet is actually installed. This will be in the form:

The parameters included in the URL are firstly, the name of the data set to use (we'd like the server to be able to handle several concurrently), and secondly, the identifier of the individual to display.

So the first thing that we need to do is to generate hyperlinks in this format. We can do this by writing a new stylesheet module that imports
person.xsl
and overrides the template that generated the hyperlinks. We'll call this
ged-servlet.xsl
.

The
ged-servlet.xsl
stylesheet module is as follows. It has an extra parameter, which is the name of the tree we are interested in, because the same servlet ought to be able to handle requests for data from different family trees. And it overrides the
make-href
template with one that generates hyperlinks in the required format:

Note that in the XHTML document the ampersand in the URL will be represented as
&
. People sometimes get anxious about this, but it's the correct representation and all browsers will accept it. Most will also accept an unescaped ampersand, which is what many HTML authors incorrectly write.