he general-purpose XML transformer and/or validator discussed here, named "XmlTransform" operates on an arbitrarily deep directory tree containing files you want to transform. As output it optionally generates multi-level indices and can even add navigational linkages.
XmlTransform's validation capability is reasonably straightforward; it lets you ensure that the set of XML files used for a transformation are valid according to specified XML schema. You may elect to validate input files, output files (after transformation), or both.
The program's transformation capability is more interesting. One common application of a transformation engine is as a pre-processor, a very handy thing indeed when designing web pages.
Pre-Processors and HTML
Modern, well-formed HTML is a flavor of XML called "XHTML," which has subtle but important differences
from plain HTML. XmlTransform can transform XML files to web pages quite effectively. In fact, it can generate any arbitrary XML output that you tell it to, but because the process is easier to visualize with a concrete file type such as HTML that you probably already know, the discussion here focuses on HTML generation.
So what is a pre-processor and why is it useful? Maintenance is the primary resource consumer on any software project—often requiring more resources than the original design and implementation of the project. A pre-processor can help reduce maintenance costs. For example, assume that you maintain a corporate web site that displays a logo of a certain size on every one of its 509 plain-vanilla HTML pages. If the corporation suddenly decides to get a new look—new letterhead, new typefaces, and oh, yes, a new, differently sized logo, you would need to edit each of the 500+ pages to display the new logo image. While the amount of work involved in such a change might vary, depending on how the pages are set up, the point is that changes do occur that cause frequently occurring web page elements page to need periodic updating.
That's where pre-processors come in. Just like a style sheet lets you define something once and reuse it over and over, a pre-processor does the same thing for anything
in your web pages, not just styles. You could, for example, create your own XML <footer>
element, and then generate the pages, replacing the <footer>
element marker with this XHTML code (including the comments):
<!-- BEGIN footer -->
alt="XYZ logo" width="143" height="25"/>
XYZ Corporation -- © 2008 All rights reserved
<!-- END footer -->
The replacement process is the key. To render an instance of a <footer>
element in your source file to the above expanded code fragment in your target XHTML file, you must transform
the source, specifying precisely how to render it in XSLT. Here's the XSLT code that would output the HTML shown above:
<img src="image/logo.gif" alt="XYZ logo"
width="143" height="25" />
<div style="float:right">XYZ Corporation -- ©
2008 All rights reserved</div>
Though you could get some mileage out of the XSLT file included with the downloadable sample project
, familiarity with XSLT is crucial to use XmlTransform effectively. The bulk of your efforts revolve around creating the XSLT code that drives the transformations. Designing clean, useful XSLT does take some effort, but it can be quite useful in the long run.
Setting up XmlTransform involves defining a custom XML dialect for your source files that encapsulates all the common elements you use, and then creating an XSLT mapping file that specifies how your particular dialect maps to XHTML (or whatever target XML dialect you wish). The initial setup takes some time, but after you've set it up, changing a logo (or a copyright notice, or any other common element throughout your site) is a simple matter of making a single change in the XSLT file, and then regenerating your output files.
|Figure 1. The XmlTransform Engine At Work: The primary XSLT operation is shown in the center, but you could also invoke schema validation on source or destination trees; the various engine options give you substantial control over how your tree is manipulated.|
illustrates how XmlTransform operates. The diagram packs a lot of information, but considering it piece by piece will make it more digestible.
The goal is to map a source tree (upper left) to a target tree (lower right). Look for the three yellow boxes, labeled "Schema validator" and "XSLT engine." Those are the active components controlled by Boolean command-line switch options (denoted by the valve switches in the figure) to turn the various paths on or off. Specifically, these active component options are: xslTransform
, and validateOutputToSchema
. Figure 1
shows all options with a dotted outline. Some of the other options shown, such as inExtension
let you specify different file extensions as your source and target file extensions, respectively.
For example to transform xml to HTML, you'd use .xml
as the inExtension
as the outExtension
. Finally, you need to be able to provide a source tree location (sourcePath
) and a list of directories that should be transformed (dirList
) and indicate where to place the output files (targetPath
). In Figure 1
, the items included in dirList
are indicated in the figure with red rectangles in the source tree. The non-selected directories are shown crossed out in the target tree, since those were not included. There are a number of other parameters that you need to consider, though most default to some reasonable value.
XmlTransform provides two other, powerful benefits to simplify maintenance: generating summary or contents pages and adding navigational connections. These are discussed in the next two sections.