 |  |
| |
In this chapter, we have discussed the features that may make the components defined in a schema reusable and flexible. This is definitely something to look for, but the impact of this effort is limited to the conception and maintenance of schemas and has little or no impact on the documents themselves. Even though application designers often see XML instance documents as tightly coupled to their schema and to the application for which they were first created, the life span of documents often exceeds the life span of their applications and schemas. XML documents or fragments are also often reused in other contexts, or serve as a container in which other information is added to create combinations that their original author never imagined.
Opening XML vocabularies to facilitate and control such evolution is quite challenging and goes beyond designing open schemas. It requires a different perspective on what an XML document is and has an impact on the way to code the applications (which should, for instance, be as tolerant as possible of unexpected elements and attributes). Grammar-based schemas, such as W3C XML Schema, have a basic problem with open vocabulary: everything that has not been explicitly allowed is forbidden, and the schemas are effectively "closed by default."
If we define the openness of a schema as the ability to modify the content model explicitly defined by the original schema without defining a new schema (we already covered the modification of the content model through a modification of the schema in the earlier section Section 13.1, "Extensible Schemas"), the tools that we have at hand are the substitution of type through xsi:type and the wildcards.
This kind of openness is allowed by default. A number of applications that use complex type derivations by extension, simple type derivations by union, or are using building blocks that have not specified block or blockDefault attributes, could probably be quite surprised by a substitution of type in the instance document.
Beyond these cases of "unexpected" openness, defining extension of the complex types used to define our elements that can be substituted in the instance documents through the xsi:type attribute can be an initial approach to open the schema while keeping control over surprises. In this case, the xsi:type attribute can be processed by the applications to determine which kind of extension they are facing.
Namespaces and wildcards are the most powerful tools we can use to create open schemas. Many vocabularies (such as W3C XML Schema) allow attributes that have a namespace other than the target namespace in all their elements, while keeping tight control over both unqualified attributes and attributes from their namespace. The values of the processContents attribute (lax, skip, and strict) can be adjusted to provide the level of openness you find best adapts to your schema. skip is completely open, strict requires supplying schemas for the namespaces that are found during the validation, and lax is a medium-level constraint.
Elements from other namespaces are often considered more intrusive than attributes and can be kept within containers. This is also what W3C XML Schema does for its own vocabulary, allowing any element from any namespace within xs:appinfo. Other vocabularies, such as Relax NG or RSS 1.0, simply accept any element that has a namespace other than its target namespace.
Although this practice allows a great deal of flexibility for embedding unexpected information in instance documents, note that the fact that there is no special value to specify "any namespace except those which are defined in the consolidated schema" limits its applicability when several namespaces are defined together.
If we mention xsi:type here, shouldn't we mention substitution groups also? Yes and no. Yes, because using them is a good way to define several alternative content models. However, no, because they can be used only if they have been defined in a schema. However, xsi:type can be used even if the schema makes no special provision for them. Despite similarities, substitution groups truly belong to flexible schemas much more than to open schemas.
|  | |
| 13. Creating Extensible Schemas |  | 14. Documenting Schemas |
Copyright © 2002 O'Reilly & Associates. All rights reserved.