Merging XML Files Using the XML DOM

The LitWare design team had two choices when they designed the PT application's dynamic localization:

• Use the XML DOM embedded inside HTML pages with the <OBJECT> tag to retrieve data from the lingo.xml file and insert it into the application's HTML files. This approach creates the user interface as needed, and does not necessarily create persistent HTML pages.
• Use the XML DOM within a COM object to merge the nonlocalized XML files with the lingo.xml file and generate localized HTML output. This approach builds the HTML files just once and stores them in the application's directory for the locale for which the files were built.

The first option preserves the distinction between HTML as presentation and XML as data; however, application performance would suffer with this approach because each request for a page requires a merge. Also, many browsers do not support the full range of XML technologies, so clients would require Internet Explorer 5 or an equivalent browser.

The developers chose the second option because the XML merge can take place within a compiled COM object; however, this option requires an entire set of nonlocalized XML pages to function as templates for the HTML pages the Lingo object generates. This shifted the burden from run time to design time, from the user to the developer, but the HTML Data Refinery tool greatly facilitated the conversion of HTML to XML.

To create the HTML files that present the PT application's user interface, the Lingo component merges the lingo.xml file with the nonlocalized XML file that contains the template for the screen the browser has requested. Using the XML DOM, the Lingo component instantiates an instance of each file and matches elements in each file by the values in the LID attribute, which is described in Nonlocalized XML File Elements. The Lingo component then writes the results of the XML merge into an HTML file that it stores in the application's directory for the language of the browser that requested the page.

The following illustration shows the process of building the application's locale-specific HTML files, in this case for German language users. When the build process starts, only the lingo.xml file resides in the application's de (HTML abbreviation for standard German) directory. When a user selects a language from the Build menu, the application loads lingo.xml into an XML document object and iterates through the globalized XML template files inserting values from lingo.xml into each file. When the build process is complete, the de directory contains a set of application HTML files; these files are sent to browsers with German language settings.

In addition to the XML files (the globalized template XML files and the lingo.xml files), the merge process also uses an XML schema. Schemas extend the function of the DTD but are more flexible to work with than DTDs, because schemas themselves are written in XML. (DTDs follow their own syntax, which means you need to develop another skill set to use them.) This schema, LingoSchema.xml, defines the structure, elements, and attributes that can appear in the PT application lingo.xml and UI template files. The schema derives from the XML Namespace, urn:schemas-microsoft-com:xml-data, and is referenced in the Document element <UIElement> in the lingo.xml files. Using LingoSchema.xml explains the implementation of the schema file in the XML merge.

This merge happens only once for each language. When the administrator selects a language from the Build menu, the application creates a new set of HTML files to populate the application's frameset and stores them in the directory for that language.

XML Merge: Assembling Form Views begins the discussion of how to implement this feature.

Organizing and Managing PT Application Files describes in detail the files the application creates.