Xmltr works together with the blox xml parser from Technology Solutions to translate xml into other formats. Blox converts an xml source document into a “parse tree” inside the Frontier object database (ODB). Xmltr traverses the resulting parse tree and invokes a series of translation rules corresponding to each markup construct in the source document.

An Overview of Xmltr

Translation Rules

Translation rules can be defined in a number of ways — ranging from simple text substitutions to complex scripts which can perform arbitrary processing. For example, you might use a simple text substitution rule to translate markup tags denoting emphasized text into an HTML <b></b> tag pair. A script translation rule on the other hand might be triggered by a <page></page> tag pair to set up a web page object (complete with directives derived from xml tag attributes) within Frontier’s web site framework (WSF).

Rules are Context Dependent

Translation rules are triggered by the context of tags within the xml source document. For example, an <emphasis> tag inside a <par> tag might trigger a different translation rule from an <emphasis> tag appearing inside a <heading> tag. (In the first case, <emphasis> might translate to “bold formatting”, whereas within a heading which is already in “bold format”, <emphasis> might mean “add italic formatting as well”.) If you want to ignore tag context, you can define wildcard translation rules which apply irrespective of the context of the xml tag.

A Close Fit with the Frontier Environment

Xmltr leverages the strengths of Frontier by defining translation rules within tables in the Frontier ODB rather than via an external translation language. Translation rules thus have access to the full power of the Frontier scripting environment and can integrate closely with the xml parse tree, the Frontier Web Site Framework (WSF) and other Frontier suites and interfaces to external programs.

Potential Applications and Benefits of Using Xmltr

Perhaps the most obvious use of xmltr is as an adjunct to the Frontier Web Site Framework. You can author the content of your web site as text marked up with xml tags then translate your source document/s into one or more web pages which can then be published via the WSF.

The author believes this approach can have the following benefits over creating a web site directly in HTML or via Frontier “macros” within the Frontier ODB:

	You can define xml tags to capture arbitrary kinds of structure within your source documents and then translate this structure into HTML. Authoring directly in HTML on the other hand limits you to the pre-defined HTML structural elements.
	Translations can depend upon the context of tags within other tags in a document hence minimising the number of different markup tags required.
	By tagging your document’s abstract structure, you open the possibility of translation into forms other than HTML. For example you might choose to also translate into QuarkXpress or FrameMaker markup tags to produce a good-looking formatted pdf file for users to download and print.
	You can author your web site (or pieces of it) as a text file using your favourite word processor or text editor. When xml structured-editors become readily available, editing these documents will become even easier.
	Your investment in content will be less dependent on (or locked into) a particular publishing tool. You have the option of moving your source (with minimal modification) to other xml-based publishing tools in the future.

Numerous other possibilities also present themselves. For example, there is no reason why dynamic web sites served from Frontier (i.e. where content can be edited via a browser interface) could not be done using xml markup, with blox and xmltr inserted into the web site publishing chain.

Xmltr can also be used as part of a print publishing workflow system. Documents can be authored as text files with xml markup defining the structure and then translated using xmltr into a tool-specific markup language (e.g. LaTex or PageMaker, QuarkXpress or FrameMaker tags). The pdf version of this documentation was translated from the same xml source as the web site and formatted in PageMaker.

Why I Wrote Xmltr

Before taking on web site publishing, I’d been involved in print publishing for over twenty years and was familiar with markup based typesetting systems of various kinds.

It was clear from trying a number of the leading Mac and Windows-based web site authoring tools that the art of document assembly had taken a giant step backwards.

The notion of separating content from format, which had been understood for years in the print world, had been forgotten. The new web authoring tools required tedious manual hard-coding of formatting and construction of “pages” (whether through manual editing of HTML or via a wysiwyg interface).

Neither did these systems account for the need to publish content in a variety of formats — for example web pages and printed form (e.g. pdf).

When XML was introduced, it seemed the obvious tool for marking up content according to its structure. What was needed then was a simple translator from XML to publication markup. The arrival of the blox XML parser made such a tool possible within the Frontier environment.

This is the purpose of xmltr, which is described in the following pages.

The Frontier/blox/xmltr combination is a very effective, lightweight and flexible system for applying generic markup as part of a web or print publishing workflow system.

It leverages the strengths of the Frontier environment by using nested table structures to define translation rules and by allowing translation rules to be arbitrary Frontier scripts.

What About XSL? I’m aware of so-called “standard” translation languages such as DSSSL and its successor XSL which is being promoted as “the way” to translate XML. However I believe both these systems are unnecessarily complicated and a much simpler solution such as the one offered here will suffice for many purposes.

Things to Keep in Mind When Using Xmltr

Unless you have an xml editing tool which ensures files have correct xml syntax, you will need to exercise some caution in preparing xml source files.

The blox parser is a non-validating parser — it does not use a Document Type Definition (DTD) to define the allowable structure of the source document. Nevertheless, blox will catch xml syntax errors and unbalanced tags.

It is up to you to invent a suitable schema of xml tags to capture document structure and to apply these in a consistent way to ensure that tags balance and that the document syntax is valid xml.

It is up to you to anticipate the tag patterns which will occur in your document and to write corresponding translation rules. Xmltr will raise a ScriptError (and terminate the translation) if it encounters a tag pattern for which no translation rule has been defined (and for which there is no wildcard rule or default rule), so trial and error will quickly reveal missing translation rules.

Website built using Frontier and xmltr. Documentation also available in pdf format for offline reading. Copyright The Design Group Qld 2000. This page last updated Thu, 23 Aug 2001