Taking this further, both approaches can be combined into a "Domino detoured round-trip." Office users create documents, which are then processed and modified by a Domino server and reloaded by other Office users. This could be as simple as putting disclaimers inside every Word document mailed out of the organization or a complex document management system.

XML cautions
XML's a fluid and fast-developing set of standards. Therefore, there's much more to saying that Office saves data using XML than at first appears. The DTDs, which are supplied to describe the "grammar" of Office XML, admit on their headers that they're well formed, but not strictly valid. Microsoft claims that Office pushes the boundaries so far that these DTDs are simply the best attempt. However, since Microsoft's also attempting to supplant DTDs with its own version of XML schemas, it's possible some of Microsoft's own corporate agenda is baked into their DTD version.

One important point to note is that the base format for Office documents is an XML variant known as XHTML. As it sounds, this is a combination of HTML and XML, the main advantage of which is that it can be read by any Web browser, whereas pure XML files can currently be read only by Internet Explorer 5. The document's also made XML compatible by adding extra tags onto certain of the standard HTML tags (which will be ignored by simple Web browsers) and by adhering strictly to the XML coding conventions. The latter means that there can be no unclosed tags, such as the common HTML <P> tag for paragraph. All tags in an XML document must be either in matching pairs (e.g. <P> and </P>), or in the special format <P/> to indicate that they're unmatched tags. Note -- Office documents will only read HTML and XHTML documents -- unlike Internet Explorer 5 they won't interpret pure XML files, which will be imported as if they were plain ASCII text files.

XML data will be encountered in three main different forms inside Office documents:

• As additional custom parameters on standard HTML tags, as demonstrated in the November 1998 article.

• As paired custom tags, such as <PivotTable><Name>PivotTable4</Name>...</PivotTable>.

• As "escaped" XML parameters to Office Web Components.

For example, a pivot table expressed in XML can be passed as one long parameter to the object. Escaped XML means that all special characters are transformed into escaped codes (e.g. "<" becomes "&lt;", ">" into "&gt;", tabs into &#9 and new lines into &#10;&#13). Needless to say, this doesn't make for readable source documents!

Tag collisions
There are hundreds of new custom tags, plus attributes for standard HTML tags, defined to cope with the various object models within Office. Since it's possible for any given document to have a number of different types of XML source within it, there has to be a way of coping with the possibility of overlapping in the names given to tags (e.g. if there's a different syntax for the NAME tag of a PivotTable and for a chart. The standard XML manner of dealing with this is implemented within Office, and is called XML NameSpaces. This is one of the simpler parts of XML, and consists simply of a declaration of a prefix and an associated schema. All tags or parameters prefixed thus are known to be from a particular schema.