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.
2003’s world view, there is a one-to-one
correspondence between schemas and namespace URIs. The
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
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
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
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.
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 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.
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.
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
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.