Why Have Multiple Translation Tables?

Version 1.2 of xmltr added support for multiple translation tables.

Before this, only a single translation table could be passed to xmltr.TranslateTree(), which required all translation rules to reside within the same translation table.

This presented a limitation if you wanted to do a variety of translations of the same content within a web site. For example, there might be a “standard” translation which translates xml markup into HTML for web pages. Another translation might act as a filter which extracts and compiles entries for an index page. In this case it is likely that some of the translation rules will be the same for both these translations (e.g. basic text formatting) and the former single-translation-table scheme required duplication of translation rules, which quickly became unwieldy to maintain.

How it Works

Under the new system of multiple translation tables, you can factor translation rules into two or more translation tables. When you call TranslateTree(), you pass a list of translation table addresses (instead of a single scalar translation table address). Xmltr then searches each translation table in turn to find the translation rule which matches a particular tag pattern. The first translation table in the list is the first one searched, and so on.

Wildcard or default translation rules in any translation table will take precedence over translation rules (of any kind) in subsequent translation tables — i.e. if a wildcard or default translation rule in a particular translation table matches the tag pattern, then the search terminates, and subsequent translation rule tables are not searched for a match.

For this reason, it makes sense to put default translation rules into the last translation table in the list so that all translation tables are searched for a match before the default translation rule is invoked.

Techniques for factoring translation rules into multiple translation tables

Here are some suggestions for using multiple translation tables:

	If you need to do a variety of translations on the same source data, factor out the translation rules which are common to all translations and put them in a translation table by themselves (called “global” perhaps).
	You may need a different default translation rule for different translations. For example, translating page content may require a default translation rule which generates a diagnostic message about a missing translation rule for a specific tag pattern. Filtering data to compile an index may require a default translation rule which simply ignores (i.e. translates to nothing) content which is not required in the index.
	This requirement can be met by placing each default translation rule in its own translation table and passing the appropriate “default rule table” as the last table in the list of translation tables.
	When using “sameas” translation rules, the tag pattern you define can match a rule in any of the supplied translation tables. You are not limited to matching a rule in the same translation table as the “sameas” rule. For example, you might wish to use a “sameas” rule to “alias” the translation of a very specific tag pattern to a more general translation rule in a more “global” translation table.
	Translation of entities can also benefit from multiple translation tables. Version 1.2 of xmltr introduced entity tables in addition to entity translation scripts. When you use entity tables, xmltr will search successive translation tables until it finds a match for the entity. Hence, you can factor entity translations across a series of translation tables, with the most generic entities appearing in the most generic translation table.

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 Tue, 7 Nov 2000