Office 2003 XML

Limitations of Word 2003’s XML Support

As you’ve probably already figured out, there are some serious limitations to this first version of Word’s custom XML schema support. To conclude the chapter, we’ll explicitly address some of these, if for no other reason than to assure you that, no, you’re not missing something.

Schemas and Namespaces

In Word 2003’s world view, there is a one-to-one correspondence between schemas and namespace URIs. The schema library can contain only one schema for a given namespace URI. In fact, Word uses “schema” as basically synonymous with “namespace URI.” Considering the fact that it is the namespace of a given XML document’s root element that determines what onload “XML data view” stylesheet to apply, this means that there are two important limitations to keep in mind:

• You cannot create two separate editing solutions (using different schemas) that have the same namespace URI

• Any XML document you wish to edit in Word must have a namespace, which rules out, for example, Docbook.

This assumes that you need the onload stylesheet to be applied automatically without the user’s intervention. If you are willing to force users to manually browse for the XSLT stylesheet to apply, then it is possible to overcome both of these limitations. Depending on your users, it may or may not be feasible to rely on their doing this. Also, if you want on-the-fly schema validation to work, your stylesheet will need to transform the source XML document into an XML document that is in a namespace that uniquely identifies an XML schema in the schema library. In that case, you would also need to provide an onsave XSLT stylesheet to change or remove the namespace when the user saves the document. However, these are burdens on the developer that can be overcome with a bit of cleverness. In the end, the real question is whether it’s feasible to require users to manually find the appropriate onload XSLT stylesheet each time they open a particular type of XML document. If not, then you’ll have to stick to using a unique namespace for each document type’s root element.

Tip

This problem is somewhat alleviated by the fact that Word, when it opens an arbitrary XML document, also lists any XSLT stylesheets referenced through the xml-stylesheet PI, in its list of “XML Data Views.” For instance documents that don’t use namespaces, this is the only way to automatically associate the document with an XSLT stylesheet. If you’re willing to include an xml-stylesheet PI just for the sake of Word, then this may effectively solve this bootstrapping problem without requiring too much user intervention.

Document Protection Doesn’t Go Far Enough

Document protection is an independently introduced feature in Word 2003. It is not tightly integrated with the XML editing features. It is up to the developer to maintain common boundaries between permission areas and custom XML tags.

Formatting restrictions are all or nothing. You can’t distinguish between the allowed styles for one field and the allowed styles for another. There is no way to associate particular styles with particular elements except through the use of Smart Documents.

Also, while formatting restrictions prevent the user from applying direct formatting and from using any forbidden styles, it does not prevent the user from inserting tables, images, or other objects.

Document Protection Conflicts with Multiple Views

Editing restrictions unfortunately don’t play nicely with XML data views. They are excessively sticky. In other words, once the default onload stylesheet has been applied, Word fails to update the document protection settings for the loaded document when it applies another view as elected by the user. In the press release template, for example, the default view has editing restrictions turned on. If the user tries switching to the “Data only” or some other view, Word chokes and is not able to make the transition correctly. Conversely, when the default view does not have editing restrictions turned on, they won’t be turned on when the user switches to a different view either, regardless of whether the other view defines editing restrictions to be in force. Effectively, you have to choose between using document protection and providing multiple editing views for the same document type. This is most likely buggy behavior exploited by the press release template. Hopefully it will be addressed soon in a future update.

Only One View at a Time

Once the user has begun editing a document after selecting a particular XML data view, they cannot subsequently change the view. This limitation is more a logical consequence of Word’s architecture for editing XML than it is a particular deficiency of the product. The reason it is impossible to change the view is that the WordprocessingML document that’s a result of the onload stylesheet retains no knowledge of the source document from which it was derived. Once the user makes a change to it, there is no way to automatically propagate those changes back to the source document. It could have tried to apply the document’s default save settings to reconstruct the document, but this doesn’t necessarily make sense for all of the use cases that the custom Word XML functionality is designed to support.

Contrast this with InfoPath’s “mapping” approach, which uses XSLT to define a single, round-trip mapping between the source document and editing view, allowing users to switch views while in the middle of editing. See Chapter 10.