XSLT Alternative through XPathScript

So much for XSLT. Because Sergeant has added something to AxKit, that doesn't have anything to do with the original XSLT: XPathScript, a scripting language, that works on XML documents just like an XSLT processor, only differently... Especially the famous DPH (Desperate Perl Hacker) will be delighted and looking forward to going ahead. The XPathScript module - to be found in

Apache::AxKit::Language::XPathScript

- makes it possible to tie XML sources to a script via referencing a style sheet. This, on the other hand, generates the target document from HTML code and some embedded Perl lines enclosed in ASP manner (<% ... %>). Script files have the suffix xps and are of type application/x-xpathscript. What this is all about, the webmaster must explain in detail in httpd.conf. [list1.html Listing 1] contains a line, which tells Apache what to do with files of type xps:

AxAddStyleMap \
application/x-xpathscript Apache::AxKit::Language::XPathScript

All files of type application/x-xpathscript will be processed by the module XPathScript.

Of course, there is neither time nor space enough to discuss this scripting language in depth (although the web, in a way, provides as much space as anyone could need). Two examples shall at least show, how XPathScript works. Again, we'll use the dictionary from above. Now it references a different kind of style sheet:

<?xml-stylesheet href="dictionary.xps" 
type="application/x-xpathscript"?>

There is a difference in both attributes compared to earlier examples: because of the scripting language the "style sheet" gets the suffix xps as well, and the type may not be text/xsl (reason see above). Right at the beginning and towards the end the XPathScript listing 6 shows simple HTML sequences, which are meant to build up the document. In between you see the Perl code determining the rest of the output.

First the script puts the sum of all entry nodes into the variable $entry. This is done by

(findnodes("/dictionary/entry"))

The following for-each block contains a few print statements which display the acronym and the term of each entry. You don't have to write the print statements exactly as here, other ways are possible (yes, TMTOWTDI :-).

Once findnodes has done its work (found the entries), it is the method findvalue of $entry, which looks for acro and term in the node-sets found by findnodes - and displays them.

XPathScript's capacities, as had to be expected, do reach beyond simple print seuquences. The mixture of HTML and XPathScript in listing 6, for instance, can be avoided, as you can see in listing 7. This is, because XPathScript knows a hash called $t, which expects an element's name as a key, one of the sub keys, listed in the sidebar "Sub key". In a last field you should add the desired output. Statements like

$t->{'acro'}{pre} = '<strong>';
$t->{'acro'}{post} = '</strong>';

determine for each element acro that it will have a prefix of <strong> and a suffix of </strong>. In other words, it should be displayed in a bold font weight. As Sergeant writes regarding his own articles (done with DocBook), you can put together script-particles like above to process complex documents. Thus, it is sensible that XPathScript has implemented (at least) file include of the Server-side Includes (SSI) - not more for the time being.

In different ways Listing 6 and listing 7 extract a list of acronyms and their meaning. No linking here, yet.

Once you have written quite a lot of these statements, you can include them via

<!-#include file="fewtags.xps"->

What's missing here is: complex applications. In his guide XPathScript - A Viable Alternative to XSLT? Sergeant shows a few examples. The rest is probably as easy as pie, at least for Perlians or DPHs ...