Status of this Document
This section describes the status of
this document at the time of its publication. Other documents may
supersede this document. A list of current W3C publications and the
latest revision of this technical report can be found in the W3C technical reports index at
http://www.w3.org/TR/.
This document is a public working draft, published
20 July 2007, of a document which when complete is expected to become a W3C
Working Group Note. It has been developed by the W3C XML Schema Working
Group, as part of the W3C XML Activity, to
illustrate the use of XML Schema 1.1 in defining XML languages.
XML Schema 1.1 introduces a number of new features intended to
make it easier to define XML languages which are flexible enough to
tolerate later revision in a forward-compatible way.
The current
draft is not complete, but it illustrates several techniques important
for the versioning of XML languages defined using XML Schema 1.1.
It will be updated to make it more complete and to reflect further
technical changes in the development of XML Schema 1.1.
Note that some examples given here illustrate constructs
not included in previous public working drafts of
XML Schema 1.1; the examples reflect the Working Group's
expectations about the content of the next working draft
of XML Schema 1.1.
The Working
Group has consensus that this draft should be published, but does not
necessarily have consensus on every aspect of the exposition.
Please send comments on this document to
the archived versioning mailing list public-xml-versioning@w3.org
(archive).
The English version of this specification is the only officially
maintained
version. Information about translations of this document is available
at http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlschema.
Publication as a Working Draft does not imply endorsement by the
W3C Membership. This is a draft document and may be updated, replaced
or obsoleted by other documents at any time. It is inappropriate to
cite this document as other than work in progress.
This document was produced by a group operating under the 5 February
2004 W3C Patent Policy. The group does not expect this document
to become a W3C Recommendation.
W3C
maintains a public list of
any patent disclosures made in connection with the deliverables
of the group; that page also includes instructions for disclosing a
patent. An individual who has actual knowledge of a patent which the
individual believes contains Essential
Claim(s) must disclose the information in accordance with section
6 of the W3C Patent Policy.
1 Introduction
This document, Guide to Versioning XML Languages using new XML Schema 1.1 Features, is intended to provide an easily approachable description of the new versioning features in the XML Schema definition language, and should be used alongside the formal descriptions of the language contained in Parts 1 and 2 of the XML Schema Recommendation. The intended audience of this document includes application developers whose programs read and write schema documents, and schema authors who need to know about the features of the language, especially features that provide functionality above and beyond what is provided by DTDs. The text assumes that you have a basic understanding of XML, Namespaces in XML, and XML Schema.
The guide is a non-normative document, which means that it does not provide a definitive (from the W3C's point of view) specification of the XML Schema language. The examples and other explanatory material in this document are provided to help you understand XML Schema, but they may not always provide definitive answers. In such cases, you will need to refer to the XML Schema specification. To help you do this, we provide many links pointing to the relevant parts of the specification.
The W3C Technical Architecture Group is working on a [TAG Finding Versioning Part 1] finding that provides a language-independent rationale and description of languages, extensibility, versioning, and compatibility, and an XML specific finding [TAG Finding Versioning XML]. They are suggested reading for these topics.
Creating and using multiple versions of a language is common and useful. As described in the Draft TAG finding, extensibility is a key contributor to versioning. It can enable forwards and backwards compatible versioning. The majority of this guide focuses on [XML Schema 1.1 Part 1] extensibility techniques that enable forwards-compatible versioning. In schema terms, this is when a schema processor with an older schema can process and validate an instance that is valid against a newer schema. This does not include any material that describes versioning in schema 1.0. Every example shown is in Schema 1.1 and is illegal in Schema 1.0 unless otherwise stated.
This guide focuses on describing the different ways extra content can be added to create new versions of a schema. These different ways reflects different conditions faced by schema authors. These conditions may manifest themselves as technical constraints (e.g. location of extension points where content can be added) or non-technical constraints (e.g. ownership over a schema).
XML Schema 1.1 contains a number of new extensibility mechanisms. The ones described in the March 2007 draft are:
Weak wildcards - permits wildcards adjacent to optional elements
Updated All Group - wildcards within All Group
Negative wildcard - exclude specific namespaces and names
Fallback To Declared Type - use declared type if xsi:type is unknown
Auto-insertion of wildcards
Not in Schema wildcard - a wildcard that allows anything not defined in the current schema
This document does not discuss the Post Schema Validation Infoset properties as that would result in a significantly less readable document.
This document does not discuss versioning of the schema language itself, such as how a Schema 1.0 processor should treat any of the Schema 1.1 constructs. This document only focuses on the increased versioning capabilities for users of Schema 1.1.
2 Wildcards
Let us start by considering a name instance. It describes a namens:
<personName xmlns="http://www.example.org/ns/personName/1">
<given>Dave</given>
<family>Orchard</family>
</personName>
As described in the Draft TAG finding, extensibility in the type is desired for versioning. Schema wildcards are a significant mechanism for allowing extensibility. Using XML Schema 1.1, the name owner might like to write a schema such as:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:complexType name="nameType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="given" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
The previous Schema is legal in XML Schema 1.1 but illegal in XML Schema 1.0 because of the Unique Particle Attribution Rule. The UPA constraint in schemas specifes that as a schema processor must always know which piece of the type delcaration (what the Recommendation calls a particle) is going to be used to validate each piece. In Schema 1.1, that rule is loosened, to always give priority to matching on explicit references to an element, in preference to matching a wildcard (<any/>).
One possible extension is adding a middle. It describes a namens:
<personName xmlns="http://www.example.org/ns/personName/1">
<given>Dave</given>
<middle>Bryce</middle>
<family>Orchard</family>
</personName>
The next version of the schema with middle name added might look like:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:complexType name="nameType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="given" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="middle" type="xs:string" minOccurs="0"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
This schema is illegal in Schema 1.0 and remains illegal in Schema 1.1 because there is a UPA (Unique Particle Attribution) rule violation with the additional optional middle and wildcard. In this case, an extension that was not a <middle> could match against the wildcard after given or before family.
However, Schema 1.1 has partially reduced the UPA constraints such that the following is now legal, and it will valid the previous 2 instances:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:complexType name="nameType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="given" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:sequence minOccurs="0">
<xs:element name="middle" type="xs:string" />
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
Alternatively, each of the elements could be wrapped in a sequence followed by a wildcard:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:complexType name="nameType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:sequence minOccurs="0">
<xs:element name="middle" type="xs:string" />
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:sequence>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
Another alternative is each of the elements could be a reference to a model group that is the sequence of the element followed by a wildcard:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:group name="given">
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:group>
<xs:group name="middle">
<xs:sequence>
<xs:element name="middle" type="xs:string" />
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:group>
<xs:group name="family">
<xs:sequence>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:group>
<xs:complexType name="nameType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:group ref="namens:given"/>
<xs:group ref="namens:middle" minOccurs="0"/>
<xs:group ref="namens:family"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
The wildcard construct enables authors to create schemas that are both forwards and backwards-compatible. The new schema is backwards compatible because it will validate old and new instances. The exception is instances that have content that is legal in the wildcard but not in the new content. An example might be a middle name that has element children or digits as content. However, that scenario means that an author created a middle name instance in the name namespace according to one schema AND an author defined a new name in the same namespace according to a different schema. Arguably there is an authority over the namespace that will prevent such clashes and so in practice this exception won't happen. Alternatively, we can make a slightly different compatibility guarantee, which is the new schema is backwards compatible with validate old and new instance where new instances do not have any extensions in the defined namespaces. The old schema is forwards compatible because it will validate old and new instances - of course it sees these as current and future instances.
The new schema is created by the replacement of a repeating wildcard in the original, with an optional-wildcard, optional-element, optional-wildcard sequence, in the later schema. The new schema explicitly states the entire new content model, including everything from the original schema as well as the new explicit declaration for middle, and for that reason we call it a "Complete Respecification" of the type.
The new type declared above using wildcards could be declared as an explicit <xs:restriction/> of the original type, because every document accepted by the new type is also accepted by the old. XML Schema's type <xs:restriction/> allows alteration of wildcards anywhere in the content model, like Complete Respecification, but allows the original type to be preserved. Alternatively, XML Schema's type extension mechanism <xs:extension/> [provide ref to Recommendation] provides a different way of specifiying a modified type, in which the original content is not restated, but only the new elements are explicitly referenced. The differences are: (1) xs:extension of sequences allows new content only at the end of the model and (2) using wildcards as shown above, the original type will accept not only documents in the original language, but also documents containing the middle name, something that's not true in typical uses of xs:extension. Thus the schema author of new version of a type has 3 options outlined above: 1) Complete Respecification without explicit use of xs:restriction; 2) Complete Respecification with explicit use of xs:restriction; 3) xs:extension.
3 Updated All Group
All-groups can use the updated wildcard:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:complexType name="nameType">
<xs:all>
<xs:element name="given" type="xs:string"/>
<xs:element name="middle" type="xs:string" minOccurs="0"/>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:all>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
This highlights two change to all-groups: the addition of wildcards and maxOccurs > 1 allows personNames such as:
<personName xmlns="http://www.example.org/ns/personName/1">
<given>Dave</given>
<family>Orchard</family>
</personName>
<personName xmlns="http://www.example.org/ns/personName/1">
<family>Orchard</family>
<given>Dave</given>
</personName>
<personName xmlns="http://www.example.org/ns/personName/1">
<middle>Bryce</middle>
<given>Dave</given>
<family>Orchard</family>
</personName>
<personName xmlns="http://www.example.org/ns/personName/1">
<addr:Address xmlns:addr="http://www.example.org/ns/address/1">Vancouver</addr:Address>
<given>Dave</given>
<family>Orchard</family>
</personName>
4 Negative Wildcards
The previous schemas allowed extra content that was already declared elsewhere in the schema, because the wildcard the wildcard could match anything. The NIS wildcard matches global elements from the schema, and the schema is generated by the schema processor as a result of processing all the schema documents including those imported and included. In the following example, the wildcards used in the schemas above would match the <given> that follows <family>:
<personName xmlns="http://www.example.org/ns/personName/1">
<given>Dave</given>
<family>Orchard</family>
<given>Dave</given>
</personName>
We can preclude the "extra" occurances by using the negative wildcard to disallow certain elements, ie:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:complexType name="nameType">
<xs:sequence>
<xs:any namespace="##any"
notQName="namens:personName namens:given namens:family"
processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="given" type="xs:string"/>
<xs:any namespace="http://www.example.org/ns/personName/1"
notQName="namens:personName namens:given namens:family"
processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="family" type="xs:string"/>
<xs:any notNamespace="http://www.example.org/ns/personName/1"
processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
The first wildcard allows anything other than namens:personName, namens:given, namens:family. The 2nd wildcard allows any element in the http://www.example.org/ns/personName/1 namespace expect for name, given, family. The last wild card allows for any namespace other than the http://www.example.org/ns/personName/1 namespace.
It is possible to re-use the wildcard with the excluded QNames by employing a model group with a wildcard referencing the QNames.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:group name="definedQNames">
<xs:sequence>
<xs:any namespace="##any" notQname="namens:personName namens:given namens:family"/>
</xs:sequence>
</xs:group>
<xs:complexType name="nameType">
<xs:sequence>
<xs:group ref="namens:definedQNames"/>
<xs:element name="given" type="xs:string"/>
<xs:group ref="namens:definedQNames"/>
<xs:element name="family" type="xs:string"/>
<xs:group ref="namens:definedQNames"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
5 Multiple Namespaces
Many XML Languages use multiple namespaces. Imagine the name where the given and family are from different namespaces than the name with wildcards at the end. What wildcard should be there? Saying "##any" means already existing terms could be inserted. ##other only prevents items from the target namespace (name) from appearing. If we want to allow only elements that are not in the givenns, familyns, or name namespaces, we can use negative wildcards with the notNamespace option:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1"
xmlns:givenns="http://www.example.org/ns/personName/given/1"
xmlns:familyns="http://www.example.org/ns/personName/family/1">
<xs:import namespace="http://www.example.org/ns/personName/given/1"/>
<xs:import namespace="http://www.example.org/ns/personName/family/1"/>
<xs:complexType name="nameType">
<xs:sequence>
<xs:element ref="givenns:given"/>
<xs:element ref="familyns:family"/>
<xs:any notNamespace="http://www.example.org/ns/personName/1 http://www.example.org/ns/personName/given/1
http://www.example.org/ns/personName/family/1" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
The wildcard above will validate any element except those with namespaces "http://www.example.org/ns/personName/1 http://www.example.org/ns/personName/given/1 and http://www.example.org/ns/personName/family/1". A common versioning scenario is to extend an existing namespace with new names, as mentioned in TAG finding (http://www.w3.org/2001/tag/doc/namespaceState.html). If we want to exclude existing terms from a namespace, we can also list them, as shown earlier but reprised in multi-ns:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:import namespace="http://www.example.org/ns/personName/given/1"/>
<xs:import namespace="http://www.example.org/ns/personName/family/1"/>
<xs:complexType name="nameType">
<xs:sequence>
<xs:element ref="givenns:given"/>
<xs:element ref="familyns:family"/>
<xs:any namespace="##any" notQName="namens:personName givenns:given familyns:family" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
6 Default Open Content
The previous schemas can be hard to read because of the wildcards sprinkled through the types. Also, the language designer has to remember to put the wildcards in everywhere. To partially address this problem, Schema 1.1 introduces the openContent element. It's functionality can be thought of as a default wildcard. There are two places that open content can occur, at the schema level or at the complextype level. The open content facility can provide for extensibility of the content model in two styles: extensibility only at the end is specified by a mode="suffix" in the openContent; extensibility before the first element, between every element and after the last is specified by a mode="interleave" in the openContent. For simplicity, the type of wildcard that is defaulted is specified by a wildcard as a child of openContent.
6.1 Schema wide Open Content
At the schema wide level, a sample is:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:openContent mode="interleave">
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:openContent>
<xs:complexType name="nameType">
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
This content allows and validates any extensions before, between or after family. If another type was added to the schema, then it would also have the openContent. For a schema that only has type nameType, it is very similar to Example #2.
6.2 ComplexType level open content
A ComplexType level open content is:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:complexType name="nameType">
<xs:openContent mode="suffix">
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:openContent>
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
This content allows and validates any extensions before, between or after family. For the nameType type definition, it is very similar to Example #2.
7 Not in Schema wildcard
The Negative wildcard requires that every wildcard specify or list the excluded QNames. We see that this can become difficult to manage as the number of wildcards and definitions grows. If there were 1000 element definitions and another one was added, then potentially 1000 wildcards would need to be updated to preclude the new element. Best case is there is an open content at the schema level and only one change is needed. However, even in this scenario, it is very possible to forget to add the new excluded qname. To help with this manageability issue, the Not In Schema wildcard specifies that any declared element is not allowed in the wildcard and is equivalent to the negative wildcard if all the declared elements were listed as excluded QNames. For ease of authoring, the examples are based upon the open content mentioned above.
The schema looks like:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<!-- Defines addr:Address, addr:City, addr:PostalCode, addr:Country, addr:State -->
<xs:import namespace="http://www.example.org/ns/Address/1"/>
<!-- ##defined here disallows: namens:personName, namens:given, namens:family,
addr:Address, addr:City, addr:PostalCode, addr:Country, addr:State -->
<xs:openContent mode="interleave">
<xs:any namespace="##any" notQName="##defined" processContents="lax"/>
</xs:openContent>
<xs:complexType name="nameType">
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
This example shows 2 different namespaces, namens and addr, that collectively define namens:personName, namens:given, namens:family, addr:Address, addr:City, addr:PostalCode, addr:Country, addr:State. Actually, here and in other QName comparisons discussed in this primer, it's the namespace name URI, that's compared, not the 'namens or addr' prefix. This text ensures that the namespace URI for namens is http://www.example.org/ns/personName/1 and the local name is personName for namens:personName. For convenience in this primer we follow XML conventions and refer just to the prefixed QName. These Qnames are disallowed in the personName element. Imagine that a producer invents an extension, say "middle" names. The producer puts the middle after the family, shown below
<personName xmlns="http://www.example.org/ns/personName/1">
<given>Dave</given>
<family>Orchard</family>
<midns:middle xmlns:midns="http://www.example.org/ns/middleName/1">Bryce</midns:middle>
</personName>
The consumer won't know about the middle names and validation will pass. Again, note that elements that are considered defined are all the elements that are available as a result of processing every schema document including those referenced by include and import.
8 Type extension and restriction with wildcards
Extension and Restriction are two modularity mechanisms that can be combined with the new wildcard capabilities of XML Schema 1.1.
8.1 Extension
We can use open contents and type extension to add content to the content model in the simplest way, that is adding the new element, because the following is legal in Schema:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:openContent mode="interleave">
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:openContent>
<xs:complexType name="nameType">
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
<xs:complexType name="personNameWithMiddleType">
<xs:complexContent>
<xs:extension base="namens:nameType">
<xs:sequence>
<xs:element name="middle" type="xs:string"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personNameWithMiddle" type="namens:personNameWithMiddleType"/>
</xs:schema>
This results in a type which is legal in schema 1.1 because it creates a type with content model below:
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
<xs:element name="middle" type="xs:string"/>
</xs:sequence>
Its validation semantics are changed to behave as if occurs before, in between and after, each particle, like this:
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="given" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="middle" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
Note that extension adds to the content model. In the previous case, the wildcard was implicit and not part of the types content model. Extension of types with explicit wildcards at the end is not possible when the wildcard has a minOccurs that does not equal the maxOccurs. The reason is that extension of types extends the content model, and adding an explicit element after a wildcard with optional content is actually a restriction. For example, the following is illegal.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:complexType name="nameType">
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:complexType name="personNameWithMiddleType">
<xs:complexContent>
<xs:extension base="namens:nameType">
<xs:sequence minOccurs="0" >
<xs:element name="middle" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
It is worth noting that if the wildcard has a minOccurs = maxOccurs then the previous extension is valid because the number of elements validated by the wildcard is predictable and so the UPA constraint is not violated. However, this doesn't appear to be a common usage pattern.
8.2 Restriction
Now let us examine type restriction with wildcards.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:complexType name="nameType">
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:complexType name="personNameWithMiddleType">
<xs:complexContent>
<xs:restriction base="namens:nameType" >
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
<xs:element name="middle" type="xs:string" minOccurs="0"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="personNameWithMiddle" type="namens:personNameWithMiddleType"/>
</xs:schema>
Note that the restriction forces us to replicate the content model of the restricted type. This does allow us to perform significant updates to the content model including adding content between existing elements, for example
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:complexType name="nameType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="given" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:complexType name="MuchBetterNameType">
<xs:complexContent>
<xs:restriction base="namens:nameType" >
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="prefix" type="xs:string" minOccurs="0"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="given" type="xs:string"/> <!-- ie David -->
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="familiarname" type="xs:string" minOccurs="0"/> <!-- ie Dave -->
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="middle" type="xs:string" minOccurs="0"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="suffix" type="xs:string" minOccurs="0"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="fullyWrittenName" type="xs:string" minOccurs="0"/> <!-- ie Henry S Truman -->
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="MuchBetterName" type="namens:MuchBetterNameType"/>
</xs:schema>
We can also change the location of the wildcards. The newer version of the schema must not allow more things than before - because any instances of the new type must be valid against the old type - the wildcards can change from interleave to suffix to none. Because we are restricting the type, we use the xsd:restriction construct. An example of this is:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:complexType name="nameType">
<xs:openContent mode="interleave">
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:openContent>
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
<xs:complexType name="personNameWithMiddleType">
<xs:complexContent>
<xs:restriction base="namens:nameType">
<xs:openContent mode="suffix">
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:openContent>
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
<xs:element name="middle" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:restriction>
<xs:anyAttribute/>
</xs:complexContent>
</xs:complexType>
<xs:element name="personName" type="namens:personNameWithMiddleType"/>
</xs:schema>
8.3 Allowing Extension or Restriction with wildcards
The first version of a type will determine whether xsd:extension or xsd:restriction can be used for modularity. In general, explicit repeating wildcards in the first version of a type mean that a derived type can use xsd:restriction and cannot use xsd:extension. The converse is true, which is that no wildcards or implicit wildcards in the first version of a type mean that a derived type can use xsd:extension and cannot use xsd:restriction unless other content allowed by the base type is optional or variable. If a type author wants to enable re-use of a type without respecification, specifically xsd:extension, then they typically must not use explicit wildcards.
8.4 Producer side considerations for NIS
There is an issue for a producer of a document with extensions that wishes to write a schema that includes the extension. In the scenario where a middle is added to a name, the producer does know about the extension. It might create a schema for the extension such as
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/middleName/1"
elementFormDefault="qualified"
xmlns:midns="http://www.example.org/ns/middleName/1">
<xs:element name="middle" type="xs:string"/>
</xs:schema>
When the producer attempts to validate the instance document against the two schemas, validation will fail. This is because the ##defined will now fail because the middle is now known.
One attempt to solve this problem is to rewrite the schema.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1"
xmlns:midns="http://www.example.org/ns/middleName/1">
<xs:import namespace="http://www.example.org/ns/middleName/1"/>
<xs:openContent mode="interleave">
<xs:any namespace="##any" notQName="##defined" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:openContent>
<xs:complexType name="nameType">
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
<xs:element ref="midns:middle" minOccurs="0"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
The producer is able to produce a schema that validates the instance. But what if the producer is not able to change the nameType to add in the middle? They might attempt to do something such as:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1"
xmlns:midns="http://www.example.org/ns/middleName/1">
<xs:import namespace="http://www.example.org/ns/personMiddle/1"/>
<xs:redefine schemaLocation="name.xsd">
<xs:complexType name="nameType">
<xs:complexContent>
<xs:restriction base="namens:nameType">
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
<xs:element ref="midns:middle" minOccurs="0"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:redefine>
<xs:openContent mode="interleave">
<xs:any namespace="##any" notQName="##defined"
processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:openContent>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
The problem is that, by the time the definition of the redefined type is checked, the midns:middle is known, and it defines midns:middle In such a context, the above schema represents an illegal redefinition of nameType. The Working Group acknowledges this may limit use of NIS wildcards in some circumstances and solicits feedback.
9 Fallback to Declared Type
XML Schema 1.0 has a feature that an instance document may contain an xsi:type attribute that specifies the type of the element. When a consumer receives the existing element name with an xsi:type specifying the new type, it may not know about the new type. A fallback from the xsi:type to the declared type allows a consuming schema processor to "cast" the type it does know about into the declared type.
<personName xmlns="http://www.example.org/ns/personName/1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="namens:personNameWithMiddle">
<given>Dave</given>
<family>Orchard</family>
<middle>Bryce</middle>
</personName>
If the consumer of this element didn't understand the xsi:type definition (namens:personNameWithMiddle), they could "cast" it to the declared type (namens:personName), resulting in roughly:
<personName xmlns="http://www.example.org/ns/personName/1" >
<given>Dave</given>
<family>Orchard</family>
<middle>Bryce</middle>
</personName>
10 Appendix: Some mechanisms not in Schema 1.0 or 1.1
This section lists a few mechanisms that have some interest and demand but for a variety of reasons are not in Schema 1.0 or Schema 1.1. These are included here because there are still discussion within the Schema WG about versioning mechanisms and may be useful for the Schema WG members. Note, the syntax used here-in is probably incorrect as it isn't maintained as closely as the in-scope mechanisms.
10.1 Extension replacing wildcard
As noted in the section on extension and restriction, an explicit wildcard at the end of a content model means that xsd:extension cannot be used and thus restatement of the original content must be done. One potential solution to allow re-use without restatement is to revise XML Schema's extension mechanism to specify that a trailing wildcard in a base type is replaced by the extension. ie:
<xs:complexType name="nameType">
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:complexType name="personNameWithMiddleType">
<xs:complexContent>
<xs:extensionRemovingTrailingWildcard base="namens:nameType" >
<xs:sequence>
<xs:element name="middle" type="xs:string" minOccurs="0"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extensionRemovingTrailingWildcard>
</xs:complexContent>
</xs:complexType>
This proposed new extension would result in a content model of
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
<xs:element name="middle" type="xs:string" minOccurs="0"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
This feature does not seem very useful however. This can be approximated by a base type with an open content with mode=suffix and then the extension type have the same open content.
10.2 Fallback
Fallback allows replacement content to be inserted if an element type isn't defined. All the previous examples generally retain the extra content in the PSVI. One use of fallback is to "prune" the extra content from the PSVI, such as:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:complexType name="nameType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded">
<xs:fallback/>
</xs:any>
<xs:element name="given" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded">
<xs:fallback/>
</xs:any>
<xs:element name="family" type="xs:string"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded">
<xs:fallback/>
</xs:any>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:element name="personName" type="namens:nameType"/>
</xs:schema>
In this example, any extensions will be pruned and will not be in the PSVI after fallback processing is applied.
Also see the following section for instance document based fallback.
10.3 FallbackElement in instance
The previous example creates a new type and preserved the existing name. Another possibility is that new element names will be created. When a consumer receives a new element name, it may not know about the new element name or type. An xsi:fallbackElement can be specified in the instance, and a consumer can "cast" the element it does know about into the xsi:fallbackElement.
<personNameWithMiddle xmlns="http://www.example.org/ns/personName/1"
xmlns:namens="http://www.example.org/ns/personName/1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="namens:personNameWithMiddleType"
xsi:fallbackElement="namens:personName">
<given>Dave</given>
<family>Orchard</family>
<middle>Bryce</middle>
</personNameWithMiddle>
If the consumer of this element didn't understand the element definition, they could "cast" it to the fallbackElement, resulting in:
<personName xmlns="http://www.example.org/ns/personName/1"
xmlns:namens="http://www.example.org/ns/personName/1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="namens:personNameWithMiddleType" >
<given>Dave</given>
<family>Orchard</family>
<middle>Bryce</middle>
</personName>
This would then combine with the fallback to Declared type as mentioned previously.
10.3.1 Multiple Versions with Fallback Type
Let us explore multiple versions. Imagine a 3rd version of name is created with a suffix:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/ns/personName/1"
elementFormDefault="qualified"
xmlns:namens="http://www.example.org/ns/personName/1">
<xs:element name="personNameWithMiddleAndSuffix" type="namens:personNameWithMiddleAndSuffixType"/>
<xs:complexType name="personNameWithMiddleAndSuffixType">
<xs:complexContent>
<xs:restriction base="namens:personNameWithMiddle" >
<xs:openContent mode="suffix">
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:openContent>
<xs:sequence>
<xs:element name="given" type="xs:string"/>
<xs:element name="family" type="xs:string"/>
<xs:element name="middle" type="xs:string" minOccurs="0"/>
<xs:element name="suffix" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
There is a problem of chaining the fallback elements together. TBD.
<personNameWithMiddleAndSuffix xmlns="http://www.example.org/ns/personName/1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="namens:personNameWithMiddleAndSuffix" xsi:fallbackElement="namens:personNameWithMiddle namens:personName">
<given>Dave</given>
<family>Orchard</family>
<middle>Bryce</middle>
</personNameWithMiddleAndSuffix>
12 Acknowledgements
Gilbert Pilz, BEA Systems. W3C Schema Working Group Members. Paul Downey, BT.