 |  |
| |
This chapter provides a quick reference to all of the elements W3C XML Schema uses to define components of XML Schemas. Some elements can be defined simply, while others require multiple entries reflecting usage in different contexts. If an element name is followed by a parenthetical phrase, you may want to examine following entries to determine which context is most appropriate for your use.
| xs:all(outside a group) | Compositor describing an unordered group of elements. |
<xs:all
id = xs:ID
maxOccurs = "1" : "1"
minOccurs = ( "0" | "1" ) : "1"
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, xs:element*)
</xs:all>
|
xs:all is used to describe an unordered group of elements whose number of occurences may be zero or one.
xs:all is the only compositor that cannot be used as a particle and needs to be used by itself to describe a complete content model. Unlike xs:choice and xs:sequence, xs:all cannot be embedded within another compositor. It can, thus, only be embedded directly into an xs:complexType, xs:restriction, or xs:extension; furthermore, its number of occurrences may be only zero or one.
The particles included in xs:all are also limited: they can only be xs:element and their number of occurrences can only be zero or one.
Combining these two restrictions means xs:all may only be used to describe content models in which a group of unordered elements (mandatory or optional, but with a number of occurrences not greater than one) are the only child elements.
Situations describing unordered groups of optional elements that have the same number of maximum occurrences can be described using xs:choice or substitution groups, but other content models (such as groups of unordered elements with arbitrary and different maximum numbers of occurrences) cannot be described with W3C XML Schema.
Complex types defined using an xs:all compositor cannot be derived by extension.
<xs:element name="author">
<xs:complexType>
<xs:all>
<xs:element ref="name"/>
<xs:element ref="born"/>
<xs:element ref="dead" minOccurs="0"/>
</xs:all>
<xs:attribute ref="id"/>
</xs:complexType>
</xs:element>
<xs:element name="full-name" substitutionGroup="name">
<xs:complexType>
<xs:all>
<xs:element name="first" type="string32" minOccurs="0"/>
<xs:element name="middle" type="string32" minOccurs="0"/>
<xs:element name="last" type="string32"/>
</xs:all>
</xs:complexType>
</xs:element>| xs:all(within a group) | Compositor describing an unordered group of elements. The number of occurrences cannot be defined when xs:all is used within a group. |
<xs:all
id = xs:ID
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, xs:element*)
</xs:all>
|
Used within a group, xs:all has the same meaning as when it is used directly under xs:complexType, except that the minOccurs and maxOccurs attributes have completely disappeared (i.e., it cannot be marked as optional).
The restrictions that apply to xs:all apply to the group embedding the xs:all compositor. This group cannot have a number of occurrences greater than one and cannot be used as a particle. It must be included directly under xs:complexType, xs:restriction, or xs:extension.
All other restrictions of xs:all apply here.
<xs:group name="authorSubElements">
<xs:all>
<xs:element ref="name"/>
<xs:element ref="born"/>
<xs:element ref="dead" minOccurs="0"/>
</xs:all>
</xs:group>| xs:annotation | Informative data for human or electronic agents. |
<xs:annotation
id = xs:ID
{any attributes with non-schema namespace}
>
Content: (xs:appinfo | xs:documentation)*
</xs:annotation>
|
xs:annotation is a container in which additional information can be embedded, either for human consumption (with xs:documentation) or for programs (xs:appinfo). xs:annotation can be added as a first element in almost any W3C XML Schema element. It can also be included anywhere as a top-level element (directly under xs:schema).
xs:annotation cannot be included within itself.
<xs:element name="author" type="author">
<xs:annotation>
<xs:documentation xml:lang="en">
The author of a book.
</xs:documentation>
<xs:documentation xml:lang="fr">
Designe l'auteur d'un livre.
</xs:documentation>
<xs:appinfo xmlns:sch="http://www.ascc.net/xml/schematron">
<sch:pattern name="Born before dead">
<sch:rule context="author">
<sch:assert test="not(dead) or (dead > born)"
diagnostics="bornAfterDead">
An author should die after her or his death.
</sch:assert>
<sch:diagnostics>
<sch:diagnostic id="bornAfterDead">
Error, this author is born after her or his birth!
Author=
<sch:value-of select="name"/>
Birth =
<sch:value-of select="born"/>
Death =
<sch:value-of select="dead"/>
</sch:diagnostic>
</sch:diagnostics>
</sch:rule>
</sch:pattern>
</xs:appinfo>
</xs:annotation>
</xs:element>| xs:any | Wildcard to replace any element. |
<xs:any
id = xs:ID
maxOccurs = ( xs:nonNegativeInteger | "unbounded" ) : "1"
minOccurs = xs:nonNegativeInteger : "1"
namespace = ( ( "##any" | "##other" ) | list of ( xs:anyURI | (
"##targetNamespace" | "##local" ) ) ) : "##any"
processContents = ( "skip" | "lax" | "strict" ) : "strict"
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:any>
|
xs:any is a wildcard that allows the insertion of any element belonging to a list of namespaces. This particle can be used like xs:element within choices (xs:choice) and sequences (xs:sequence), and the number of occurrences of the elements that are allowed can be controlled by its minOccurs and maxOccurs attributes.
The list of permitted namespaces is specified though the namespace attribute. The namespace attribute expects a list of namespace URIs. In this list, two values have a specific meaning: ##targetNamespace stands for the target namespace, and ##local stands for local elements (without namespaces). These values can be mixed in the list with regular namespaces URIs. The whole list may also be replaced by two other special values: ##any stands for any namespace at all and is the default value for the namespace attribute, and ##other stands for any namespace other than the target namespace. When ##other is used in a schema without a target namespace, all the namespaces are allowed and only elements without namespaces are forbidden.
The target namespace used to evaluate the special values ##targetNamespace and ##other is the target namespace (or lack of target namespace) of the schema in which the xs:any wildcard is found. This doesn't change when one schema is imported into another.
The behavior of the validator regarding the elements that will be allowed and their children can be specified using the processContent attribute. When processContent is set to strict (i.e., the default values), the schema processors must validate these elements against their schemas and report an error if they are not valid or if it hasn't been able to fetch the schemas for their namespaces. When set to skip, the processors do not attempt to validate these elements. When set to lax, the validator validates the elements if it can find a definition for them, and skips them if it can't.
When the processContent is skip (or when it is lax and the schema processor hasn't been able to locate a schema for an element, which is equivalent), the processor skips any further validation of the elements accepted that may have any content type. The processor eventually includes attributes and subelements of any namespace regardless of the value of the namespace attribute.
When the processContent is strict (or when it is lax and the schema validator has found a schema for them, which is equivalent), the elements that are accepted for the wildcard need to be defined as global elements in the schema for this namespace or have a valid datatype associated in the instance document through xsi:type attribute.
Some combinations of specifications of namespaces that are useful to define multi-namespaces open vocabularies are missing. These are the cases of "any namespace known in the current validation context" and its complementary "any namespace not defined in the current validation context."
The usual restrictions for nondeterministic content models apply to wildcards. While trying to track the risks of or reasons for a nondeterministic content model, pay attention to the value of the processContent attribute. Possible conflict may occur with any element declared as global in one of the permitted namespaces if processContent is strict, and it may occur with any element (global or local) if processContent is skip.
The behavior of the special value ##other on unqualified elements in schemas with target namespaces is contradictory in the W3C XML Schema Recommentation and should be clarified in a future addendum. The most likely interpretation is unqualified elements are not allowed when ##other is specified in these schemas, even though a passage of the Recommendation states the contrary.
| xs:anyAttribute | Wildcard to replace any attribute. |
<xs:anyAttribute
id = xs:ID
namespace = ( ( "##any" | "##other" ) | list of ( xs:anyURI | (
"##targetNamespace" | "##local" ) ) ) : "##any"
processContents = ( "skip" | "lax" | "strict" ) : "strict"
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:anyAttribute>
|
xs:anyAttribute is a wildcard that allows the insertion of any attribute belonging to a list of namespaces. This particle must be used wherever an attribute local declaration of reference can be used (i.e., within complexType or attributeGroup definitions).
The list of permitted namespaces is specified though the namespace attribute. The namespace attribute expects a list of namespace URIs. In this list, two values have a specific meaning: ##targetNamespace stands for the target namespace, and ##local stands for local attributes (without namespaces). These values can be mixed in the list with regular namespaces URIs. The whole list may also be replaced by two other special values: ##any stands for any namespace at all and is the default value for the namespace attribute and ##other stands for any namespace other than the target namespace. When ##other is used in a schema without a target namespace, all the namespaces are allowed and only attributes without namespaces are forbidden.
The target namespace used to evaluate the special values ##targetNamespace and ##other is the target namespace (or lack of target namespace) of the schema in which the xs:anyAttribute wildcard is found. This doesn't change when one schema is imported into another.
The behavior of the validator regarding the attributes that will be allowed can be specified using the processContent attribute. When processContent is set to strict (i.e., the default values), the schema processors must validate these attributes against their schemas and report an error if they are not valid or if it hasn't been able to fetch the schemas for their namespaces. When set to skip, the processors do not attempt to validate these attributes. When set to lax, the validator validates the attributes if it can find a definition for them, and skips them if it can't.
When the processContent is skip (or when it is lax and the schema processor hasn't been able to locate a schema for an attribute, which is equivalent), the processor skips any further validation of the accepted attributes that may belong to any datatype.
When the processContent is strict (or when it is lax and the schema validator has found a schema for them, which is equivalent), the accepted attributes for the wildcard need to be defined as global attributes in the schema for this namespace.
Some combinations of specifications of namespaces used to define multi-namespace open vocabularies are missing. These include the cases of "any namespace known in the current validation context" and its complementary "any namespace not defined in the current validation context."
The behavior of the special value ##other on unqualified attributes in schemas with target namespaces is contradictory in the W3C XML Schema Recommentation and should be clarified in a future addendum. The most likely interpretation is that unqualified attributes are not allowed when ##other is specified in these schemas, even though a passage of the Recommendation states the contrary.
| xs:appinfo | Information for applications. |
<xs:appinfo
source = xs:anyURI
>
Content: ({any})*
</xs:appinfo>
|
xs:appinfo is a container that embeds structured information that can be used by applications. Its content model is open and can accept any element from any namespace (with a lax validation; W3C XML Schema elements included here must be valid). xs:appinfo can be used to include any kind of information, such as metadata, processing directives, or even code snippets.
Its content is similar to xs:documentation (which is reserved for human-readable information), except for an xml:lang attribute (which is allowed in xs:documentation but forbidden for xs:appinfo).
Foreign attributes cannot be included in xs:appinfo.
The source attribute is underspecified in the Recommendation, which could lead to interoperability issues between applications relying on xs:appinfo if they use relative or shared URIs. For instance, one application may decide to use the XSLT namespace in the source attribute to indicate an XSLT snippet while another application could use the same URI to indicate a set of parameters to pass to an XSLT transformation.
<xs:element name="author" type="author">
<xs:annotation>
<xs:appinfo xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:creator>
Eric van der Vlist (mailto:[email protected])
</dc:creator>
<dc:date>
2002-02-01
</dc:date>
<dc:subject>
author,person,book
</dc:subject>
<dc:description>
This element describes the author of a book.
</dc:description>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="author" type="author">
<xs:annotation>
<xs:appinfo source="saf:meta-data-item"
xmlns:sql="http://www.extensibility.com/saf/spec/safsample/sql-map.saf"
>
<sql:select>
select
<sql:elem>
name
</sql:elem>
,
<sql:elem>
birthdate
</sql:elem>
,
<sql:attr>
deathdate
</sql:attr>
from tbl_author
</sql:select>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="book" type="book">
<xs:annotation>
<xs:appinfo xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="book">
<xsl:apply-templates select="title"/>
<xsl:apply-templates select="isbn"/>
<p>
Authors:
</p>
<ul>
<xsl:apply-templates select="author"/>
</ul>
<p>
Characters:
</p>
<ul>
<xsl:apply-templates select="character"/>
</ul>
</xsl:template>
</xs:appinfo>
</xs:annotation>
</xs:element>| xs:attribute(global definition) | Global attribute definition that can be referenced within the same schema by other schemas. |
<xs:attribute
default = xs:string
fixed = xs:string
id = xs:ID
name = xs:NCName
type = xs:QName
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, xs:simpleType?)
</xs:attribute>
|
All the attributes defined at the top level of a schema (i.e., xs:attribute, which is included directly under the xs:schema document element) are considered globally defined.
Globally defined attributes have a global scope: they can be referenced through their qualified name everywhere in the schema in which they are defined as well as in any schema that imports or includes this schema.
Attributes are identified by their qualified name, but the local name is expected in the name attribute.
The definition is done by assigning a simple datatype to the element. This assignment can be done either by reference, using the type attribute to refer to a simple datatype by its qualified name, or "inline," by embedding the definition of the simple type (xs:simpleType element) within the xs:attribute element.
When a target namespace is defined, global attributes must be defined as qualified, i.e., they must be prefixed in the instance documents. Since most of the XML vocabularies do not prefix attributes except when they are "foreign attributes" immersed in elements from other namespaces, this means that global attributes are seldom used when a target namespace is defined. To work around this restriction, attribute groups (xs:attributeGroup) can be used to embed definitions of unqualified attributes that need to be included within multiple complex type definitions.
The identification of the global attributes by their qualified names makes it impossible to globally define multiple attributes having the same qualified name. When a schema must include multiple definitions of attributes that have the same qualified names (and different datatypes), all the definitions (except one) must be locally declared. In this case, it is possible to use simple types or attribute groups instead of global attributes to define reusable content models.
All the globally defined attributes must be qualified if a target namespace is defined for the schema--they must all belong to the target namespace. When no target namespace is defined, all the attributes that are globally or locally defined must be unqualified.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:attribute name="id" type="xs:ID"/> <xs:attribute name="available" type="xs:boolean"/> <xs:attribute name="lang" type="xs:language"/> .../... </xs:schema>
| xs:attribute(reference or local definition) | Reference to a global attribute definition or local definition (local definitions cannot be referenced). |
<xs:attribute
default = xs:string
fixed = xs:string
form = ( "qualified" | "unqualified" )
id = xs:ID
name = xs:NCName
ref = xs:QName
type = xs:QName
use = ( "prohibited" | "optional" | "required" ) : "optional"
{any attributes with non-schema namespace}
>
Content: ((xs:annotation?), (xs:simpleType?))
</xs:attribute>
|
This element serves two different purposes and has two different content models for these two purposes: it can either be a reference to a globally defined attribute or it can be a local attribute definition. These options are mutually exclusive.
When used as a reference to an attribute, the ref attribute must contain the qualified name of the attribute (with its namespace prefix).
When used as a local definition, the definition is done by assigning a simple datatype to the attribute. This assignment can be done either by reference, using the type attribute to refer to a simple datatype by its qualified name, or inline, by embedding the definition of the simple type (xs:simpleType element) within the xs:attribute element.
Locally defined attributes cannot be referenced.
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
.../...
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:language"/>
</xs:extension>
</xs:simpleContent>| xs:attributeGroup(global definition) | Global attributes group declaration that can be referenced within the same schema by other schemas. |
<xs:attributeGroup
id = xs:ID
name = xs:NCName
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, ((xs:attribute | xs:attributeGroup)*,
xs:anyAttribute?))
</xs:attributeGroup>
|
Attribute groups are global containers that embed groups of attributes. They can be used to manipulate groups of several attributes often used together, but also to provide global access to attributes that cannot be globally defined because they are unqualified or because several definitions cohabit in a single schema (see the example).
Attribute references or local definitions, attribute wildcards, and attribute group references may be included within attribute group definitions.
Attribute groups may be redefined through xs:redefine elements.
None.
<xs:attributeGroup name="bookAttributes"> <xs:attribute name="id" type="xs:ID"/> <xs:attribute name="available" type="xs:boolean"/> </xs:attributeGroup>
| xs:attributeGroup(reference) | Reference to a global attributes group declaration. |
<xs:attributeGroup
id = xs:ID
ref = xs:QName
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:attributeGroup>
|
Any non-top-level occurrence of xs:attribute is a reference to an attribute group that acts like a replacement of the group by the attributes (or attribute group references) embedded in the group.
None.
<xs:element name="book">
<xs:complexType>
<xs:sequence>
<xs:element ref="isbn"/>
<xs:element ref="title"/>
<xs:element ref="author" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="character" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="bookAttributes"/>
</xs:complexType>
</xs:element>| xs:choice(outside a group) | Compositor to define group of mutually exclusive elements or compositors. |
<xs:choice
id = xs:ID
maxOccurs = ( xs:nonNegativeInteger | "unbounded" ) : "1"
minOccurs = xs:nonNegativeInteger : "1"
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:element | xs:group | xs:choice |
xs:sequence | xs:any)
)*)
</xs:choice>
|
xs:choice is a compositor that defines a group of mutually exclusive particles. Only one can be found in the instance document per occurrence of the xs:choice compositor. The number of occurrences of the compositor itself is controlled by its minOccurs and maxOccurs attributes, while the number of occurrences of each particle within a single occurrence of xs:choice can be controlled by the minOccurs and maxOccurs attributes of the particles.
In addition to situations where simple choices are expressed (element "a" or "b" can be accepted here), xs:choice is often used to work around the limitations of xs:all and to define content models where an unlimited number of elements can be found in any order (see the example).
When the particle used in a xs:choice compositor is an element, a similar effect may be achieved using substitution groups.
The xs:choice compositor may cause violations of the Unique Particle Attribution and Consistent Declaration rules.
<xs:choice>
<!-- Allows either "name" or the sequence "first-name",
"middle-name"and"last-name". -->
<xs:element ref="name"/>
<xs:sequence>
<xs:element ref="first-name"/>
<xs:element ref="middle-name" minOccurs="0"/>
<xs:element ref="last-name"/>
</xs:sequence>
</xs:choice>| xs:choice(within a group) | Compositor to define group of mutually exclusive elements or compositors. The number of occurrences cannot be defined when xs:choice is used within a group. |
<xs:choice
id = xs:ID
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:element | xs:group | xs:choice |
xs:sequence | xs:any)
)*)
</xs:choice>
|
When embedded in a group definition, the xs:choice compositor has the same function as other contexts, except that the number of its occurrences is defined in the xs:group reference instead of by the minOccurs and maxOccurs attributes of the xs:choice compositor.
The minOccurs and maxOccurs attributes that are allowed in other contexts are forbidden.
<xs:group name="author-or-character">
<xs:choice>
<xs:element ref="author"/>
<xs:element ref="character"/>
</xs:choice>
</xs:group>| xs:complexContent | Definition of a complex content by derivation of a complex type. |
<xs:complexContent
id = xs:ID
mixed = xs:boolean
{any attributes with non-schema namespace}
>
Content: ((xs:annotation?), (xs:restriction | xs:extension))
</xs:complexContent>
|
This element allows you to define a complex content model by derivation of a complex type. It is not a component by itself (complex contents are not named), but rather the declaration of an intention to define a complex content model by derivation.
The derivation method is not defined by the xs:complexContent element itself, but by the choice of its child element (xs:restriction for a derivation by restriction, or xs:extension for a derivation by extension).
This element can be used to define if the content model is mixed or not--but this information can also be defined in the xs:complexType parent element, which has also a mixed attribute.
The mixed nature of the content model defined by xs:complexContent attribute is dependent on the derivation method and on the base type. If the base type is mixed, it can be restricted to become elements only; otherwise the mixed nature of the base type cannot be changed.
A base type whose elements cannot be extended to be mixed.
<xs:element name="author">
<xs:complexType>
<xs:complexContent>
<xs:extension base="basePerson">
<xs:sequence>
<xs:element ref="dead" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>| xs:complexType(global definition) | Global definition of a complex type that can be referenced within the same schema by other schemas. |
<xs:complexType
abstract = xs:boolean : "false"
block = ( "#all" | list of ( "extension" | "restriction" ) )
final = ( "#all" | list of ( "extension" | "restriction" ) )
id = xs:ID
mixed = xs:boolean : "false"
name = xs:NCName
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:simpleContent | xs:complexContent | (,
(xs:group | xs:all | xs:choice | xs:sequence)?,
((xs:attribute | xs:attributeGroup)*, xs:anyAttribute?
?))))
</xs:complexType>
|
This component is used to create global complex types as direct descriptions of their content model, or by derivation from simple types or other complex types. The creation of a new complex type is done by a compositor (xs:sequence, xs:choice, or xs:all) that describes the child elements, followed by a list of attributes (or attribute groups or attribute wildcards). The derivation of a complex type through existing simple or complex types is done by including an xs:simpleContent (for simple contents) or an xs:complexContent (for complex contents) element. In both cases, when the content is not simple, the mixed attribute defines if the content model is mixed (i.e., allows both text and element nodes) or not.
Several controls are provided through attributes. Complex types can be declared "abstract," their substitution can be "blocked," and they can be "final" for derivation.
Constraints about keys (xs:key, xs:unique, and xs:keyref) cannot be defined at this level but need to be defined in the xs:element element. This means that, while in many cases referencing a global element definition or a global complex type definition can be considered as equivalent to define modular content models, complex types are no longer an option when these constraints need to be included in the content model.
<xs:complexType name="title">
<xs:simpleContent>
<xs:extension base="tokenWithLang">
<xs:attribute name="note" type="xs:token"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>| xs:complexType(local definition) | Complex type local definition (local definitions cannot be referenced). |
<xs:complexType
id = xs:ID
mixed = xs:boolean : "false"
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:simpleContent | xs:complexContent | (,
(xs:group | xs:all | xs:choice | xs:sequence)?,
((xs:attribute | xs:attributeGroup)*, xs:anyAttribute?
?))))
</xs:complexType>
|
Complex type definition can be created several ways. It can be done by derivation using an xs:simpleContent (for simple content models) or an xs:complexContent (for simple content model) element, or it can be described, using xs:sequence (for an ordered sequence of elements), an xs:choice (for an alternative beyond several elements), xs:all (for a unordered list of elements) or xs:group (to reference a group of elements), and xs:attribute, xs:attributeGroup, and xs:anyAttribute to define the list of its attributes.
Complex types describe all the constraints on the element, character, and attribute nodes that may be included within an element except those described by xs:unique, xs:key, and xs:keyref, which are defined directly under the xs:element element definitions.
Constraints defined by xs:unique, xs:key, and xs:keyref are not defined within complex types but directly under the xs:element element definitions.
Local definitions can neither be derived (by restriction or extension) nor substituted. In addition, the derivation by restriction of complex types and the redefinition by restriction of element groups, including elements defined with local complex type definitions, is limited since derivations by restriction need to redefine the elements that are kept using explicit derivations.
Unlike other components (xs:element, xs:attribute, xs:group, and xs:attributeGroup), local xs:complexType components cannot be used to reference global complex types. Reference to complex types is done through xs:element type attributes and xs:restriction and xs:extension base attributes.
<xs:element name="title">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>| xs:documentation | Human-targeted documentation. |
<xs:documentation
source = xs:anyURI
xml:lang = xml:lang
>
Content: ({any})*
</xs:documentation>
|
xs:documentation is a container for human-readable documentation in plain text or structured formats. Its content model is open and can accept any element from any namespace (with a lax validation only--W3C XML Schema elements included here must be valid). xs:documentation can be used to include any kind of information.
Its content is similar to xs:appinfo (which is reserved for application processable information), except that it has xml:lang attribute; this is allowed in xs:documentation, but forbidden for xs:appinfo).
Foreign attributes cannot be included in xs:documentation. The source attribute is also underspecified in the Recommendation. This could lead to interoperability issues between applications that rely on xs:documentation.
<xs:element name="author" type="author">
<xs:annotation>
<xs:documentation xml:lang="en">
The author of a book.
</xs:documentation>
<xs:documentation xml:lang="fr">
Designe l'auteur d'un livre.
</xs:documentation>
</xs:annotation>
</xs:element>| xs:element(global definition) | Global element definition that can be referenced within the same schema by other schemas. |
<xs:element
abstract = xs:boolean : "false"
block = ( "#all" | list of ( "extension" | "restriction" |
"substitution" ) )
default = xs:string
final = ( "#all" | list of ( "extension" | "restriction" ) )
fixed = xs:string
id = xs:ID
name = xs:NCName
nillable = xs:boolean : "false"
substitutionGroup = xs:QName
type = xs:QName
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:simpleType | xs:complexType)?, (xs:unique |
xs:key | xs:keyref)*)
</xs:element>
|
All the elements defined at the top level of a schema (i.e., xs:element, which is included directly under the xs:schema document element) are considered globally defined.
Globally defined elements have a global scope: they can be referenced through their qualified name everywhere in the schema in which they are defined, as well as in any schema that imports or includes this schema. They can also be used as document elements in instance documents.
Elements are identified by their qualified name, but the local name is expected in the name attribute. The type definition is performed by assigning a simple or complex datatype to the element.
This assignment can be done either by reference, using the type attribute to refer to a simple or complex datatype by its qualified name, or inline, by embedding the definition of the simple (xs:simpleType) element or the complex (xs:complexType) element that is within the xs:element element.
A default value may be defined using the default attribute, but note that the semantics of default values for elements are different than those of the default values for attributes. An element is not created if it is absent from the instance document; the default value is applied only if the element is present and empty.
Several control attributes are included in element definitions (see the attributes abstract, blocked, final, fixed, and nillable) .
Element definitions are also the place in which substitution groups are defined using the substitutionGroup attribute to refer to the head of the substitution group. Any global element that is not final may be chosen as the head of a substitution group. Any reference to the head of a substitution group may be replaced in the instance documents by any of the members of the substitution group (assuming these substitutions have not been blocked through block attributes). The relation is transitive, and if the head of a substitution "A" is a member of another substitution group "B," the members of "A" are also considered members of "B."
There is no feature that allows definition of global elements that cannot be used as document elements. When this is needed, the workaround is to define all the elements, save one, and use simple and complex types or element groups instead of global elements to define reusable content models, and then reference these types from a single globally-defined element.
The identification of the global elements by their qualified names makes it impossible to globally define multiple elements that have the same qualified name. When a schema must include multiple definitions of elements that have the same qualified name (and different datatypes), all the definitions except one must be locally declared. It is possible to use simple and complex types or element groups instead of global elements to define reusable content models.
All globally defined elements must be qualified if a target namespace has been defined for the schema; they must all belong to the target namespace. When no target namespace is defined, all the elements that are globally or locally defined must be unqualified.
The default and fixed values are defined in attributes and, therefore, can only apply to simple type elements.
Elements cannot be directly redefined. To redefine an element, one can either include it in a group and redefine the group, or use a global complex type to define the element and redefine the complex type.
<xs:element name="name" type="xs:string"/>
| xs:element(within xs:all) | Reference to a global element declaration or local definition (local definitions cannot be referenced). The number of occurrences can only be zero or one when xs:element is used within xs:all.. |
<xs:element
block = ( "#all" | list of ( "extension" | "restriction" |
"substitution" ) )
default = xs:string
fixed = xs:string
form = ( "qualified" | "unqualified" )
id = xs:ID
maxOccurs = ( "0" | "1" ) : "1"
minOccurs = ( "0" | "1" ) : "1"
name = xs:NCName
nillable = xs:boolean : "false"
ref = xs:QName
type = xs:QName
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:simpleType | xs:complexType)?, (xs:unique |
xs:key | xs:keyref)*)
</xs:element>
|
This element serves two different purposes and has two different content models for these purposes: it can either be a reference to a globally defined element or to a local element definition. These options are mutually exclusive.
When used as a reference to an element, the ref attribute must contain the qualified name of the element (with its namespace prefix).
When used as a local definition, the definition is done by assigning a simple or complex datatype to the element. This assignment can be done either by reference, using the type attribute to refer to a simple or complex datatype by its qualified name, or inline, by embedding the definition of the simple (xs:simpleType) element or complex (xs:complexType) element within the xs:element element.
Local element definitions or references cannot have a number of occurrences greater than one.
The default and fixed values are defined in attributes and, therefore, can only apply to simple type elements.
The fact that W3C XML Schema cannot describe the exclusive combinations of the attributes and elements of xs:element, which can be summarized as:
ref attribute xor name attribute, type attribute xor xs:simpleType element, xor xs:complexType element
is an example that shows some of the restrictions of the language.
<xs:all> <xs:element name="first" type="string32" minOccurs="0"/> <xs:element name="middle" type="string32" minOccurs="0"/> <xs:element name="last" type="string32"/> </xs:all>
| xs:element(reference or local definition) | Reference to a global element declaration or local definition (local definitions cannot be referenced). |
<xs:element
block = ( "#all" | list of ( "extension" | "restriction" |
"substitution" ) )
default = xs:string
fixed = xs:string
form = ( "qualified" | "unqualified" )
id = xs:ID
maxOccurs = ( xs:nonNegativeInteger | "unbounded" ) : "1"
minOccurs = xs:nonNegativeInteger : "1"
name = xs:NCName
nillable = xs:boolean : "false"
ref = xs:QName
type = xs:QName
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:simpleType | xs:complexType)?, (xs:unique |
xs:key | xs:keyref)*)
</xs:element>
|
This element serves two different purposes and has two different content models for these purposes: it can either be a reference to a globally defined element or to a local element definition. These options are mutually exclusive.
When used as a reference to an element, the ref attribute must contain the qualified name of the element (with its namespace prefix).
When used as a local definition, the definition is done by assigning a simple or complex datatype to the element. This assignment can be done either by reference, using the type attribute to refer to a simple or complex datatype by its qualified name, or inline, by embedding the definition of the simple (xs:simpleType) element or complex (xs:complexType) element within the xs:element element.
In all cases, the number of occurrences can be constrained using the minOccurs and maxOccurs attributes, whose default value is 1. The maxOccurs attribute can take the value unbounded, to define that an element may appear as many times as the author of the document wishes.
The default and fixed values are defined in attributes and, therefore, can only apply to simple type elements.
The fact that W3C XML Schema cannot describe the exclusive combinations of the attributes and elements of xs:element which could be summarized as:
ref attribute xor name attribute, type attribute xor xs:simpleType element, xor xs:complexType element
is an example that shows some of the restrictions of the language.
<xs:sequence>
<xs:element name="book" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element ref="isbn"/>
<xs:element ref="title"/>
<xs:element ref="author" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="character" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute ref="id"/>
<xs:attribute ref="available"/>
</xs:complexType>
</xs:element>
</xs:sequence>| xs:enumeration | Facet to restrict a datatype to a finite set of values. |
<xs:enumeration
id = xs:ID
value = anySimpleType
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:enumeration>
|
May be used as facet for: xs:anyURI, xs:base64Binary, xs:byte, xs:date, xs:dateTime, xs:decimal, xs:double, xs:duration, xs:ENTITIES, xs:ENTITY, xs:float, xs:gDay, xs:gMonth, xs:gMonthDay, xs:gYear, xs:gYearMonth, xs:hexBinary, xs:ID, xs:IDREF, xs:IDREFS, xs:int, xs:integer, xs:language, xs:long, xs:Name, xs:NCName, xs:negativeInteger, xs:NMTOKEN, xs:NMTOKENS, xs:nonNegativeInteger, xs:nonPositiveInteger, xs:normalizedString, xs:NOTATION, xs:positiveInteger, xs:QName, xs:short, xs:string, xs:time, xs:token, xs:unsignedByte, xs:unsignedInt, xs:unsignedLong, xs:unsignedShort
xs:enumeration is a facet that allows definition of a list of possible values for the value space of a datatype by enumerating all these values in separated xs:enumeration elements in a single restriction step (i.e., under a single rs:restriction parent element). This is one of the two facets (with xs:pattern) that are available for all the datatypes (atomic, lists, or unions), but unlike xs:pattern, xs:enumeration is not available for xs:boolean.
The values of the xs:enumeration facets must belong to the value space of the base datatype. When the base datatype is already restricted by enumeration, the new enumeration values must be a subset of the base datatype enumerations (even though they may have different lexical representations that correspond to the same logical values).
This facet cannot be fixed (i.e., it remains available in all the derived types).
This facet is not available for xs:boolean.
<xs:simpleType name="schemaRecommendations">
<xs:restriction base="xs:anyURI">
<xs:enumeration value="http://www.w3.org/TR/xmlschema-0/"/>
<xs:enumeration value="http://www.w3.org/TR/xmlschema-1/"/>
<xs:enumeration value="http://www.w3.org/TR/xmlschema-2/"/>
</xs:restriction>
</xs:simpleType>| xs:extension(simple content) | Extension of a simple content model. |
<xs:extension
base = xs:QName
id = xs:ID
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, ((xs:attribute | xs:attributeGroup)*, xs:anyAttribute?))
</xs:extension>
|
This element is used to extend either a simple type or a simple content complex type into a simple content complex type (i.e., the content model of an element with a text nodes and some attributes). The type to extend is specified in the base attribute, and the list of the attributes to add to the content model is given as xs:attributes, xs:attributeGroup, and xs:anyAttribute embedded in the xs:extension element.
Such a derivation by extension of a simple type is the only way to create a complex type simple content content model.
The definition of the base type cannot be embedded in the xs:extension element, and the base type needs to be a global type.
The same element name (xs:extension) is used by W3C XML Schema for the extension of simple content and complex content complex types with a different content model.
<xs:element name="title">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="string255">
<xs:attribute ref="lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>| xs:extension(complex content) | Extension of a complex content model. |
<xs:extension
base = xs:QName
id = xs:ID
{any attributes with non-schema namespace}
>
Content: ((xs:annotation?), (, (xs:group | xs:all | xs:choice |
xs:sequence)?, ((xs:attribute | xs:attributeGroup)*,
xs:anyAttribute?)))
</xs:extension>
|
Extension of a complex (or mixed) content complex type. This derivation method can be applied to another complex content complex base type, and allows the addition of elements and attributes to this base type. The additional elements are added after the compositor used in the base type.
When new elements are added during a derivation by extension, the resulting content model is equivalent to creating a sequence that contains the compositor used to define the base type and the one included in the xs:extension element.
Complex types that use a xs:all compositor cannot be used as base types for derivations by extension, except when those extensions add only attributes.
New elements added to base types using a xs:choice compositor are added in sequence after the xs:choice, rather than as new choices.
<xs:element name="character">
<xs:complexType>
<xs:complexContent>
<xs:extension base="basePerson">
<xs:sequence>
<xs:element ref="qualification"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>| xs:field | Definition of the field to use for a uniqueness constraint. |
<xs:field
id = xs:ID
xpath = xs:token
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:field>
|
xs:field is used to define the location of the fields on which a uniqueness constraint or reference will be checked.
The fields are elements or attributes that are identified by relative XPath expressions (i.e., xpath attributes) evaluated against the nodes selected by the xs:selector element.
Concatenated keys can be expressed defining multiple fields under a xs:unique, xs:key, or xs:keyref element.
The xpath attribute uses a simple subset of XPath 1.0. The motivation of the W3C XML Schema Working Group for defining this subset is to simplify the work of the implementers of schema processors, and also to define a subset that constraints the path to stay within the scope of the current element.
This subset is restricted to using only the child, attribute, self, and descendant or self XPath axes through their abbreviated syntaxes without including any test in any of the XPath location steps, and without using any XPath functions. It is identical to the subset defined for xs:selector, except that attributes are allowed in xs:field and forbidden in xs:selector.
The formal extended BNF given in the W3C Recommendation is as follows:
Field ::= Path ( '|' Path )* Path ::= ('.//')? ( Step '/' )* ( Step | '@' NameTest )
Step ::= '.' | NameTest NameTest ::= QName | '*' | NCName ':' '*'When concatenated keys are defined, the node sets identified by each field must have a single occurrence per iteration of locator. This means that on structures such as:
<sect num="1"> <sub-sect num="1"> Sub section 1.1 </sub-sect> <sub-sect num="2"> Sub section 1.2 </sub-sect> </sect> <sect num="1"> <sub-sect num="3"> Sub section 1.3 </sub-sect> <sub-sect num="4"> Sub section 1.4 </sub-sect> </sect>
multilevel concatenated keys over the num attributes of sect and sub-sect cannot be defined with W3C XML Schema. This is because the locator would need to iterate on the sect element, and the num attribute of the sub-sect element then takes several values for each iteration.
<xs:element name="library">
<xs:complexType>
.../...
</xs:complexType>
<xs:unique name="book">
<xs:selector xpath="book"/>
<xs:field xpath="isbn"/>
</xs:unique>
</xs:element>| xs:fractionDigits | Facet to define the number of fractional digits of a numerical datatype. |
<xs:fractionDigits
fixed = xs:boolean : "false"
id = xs:ID
value = xs:nonNegativeInteger
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:fractionDigits>
|
May be used as facet for: xs:decimal
xs:fractionDigits defines the maximum number of fractional digits (i.e., digits that are after the decimal point) of an xs:decimal datatype.
This facet constrains the value space, which means that the number of fractional digits is checked after the value is transformed to its canonical form, and the trailing zeros are removed.
Within a restriction step, xs:fractionDigits is dependent on xs:totalDigits, since using inconsistent values leads to datatypes with empty value spaces.
xs:fractionDigits must restrict the value space of its base type, and its value must be smaller than the value of xs:fractionDigits of its base type if defined.
It is possible to use xs:pattern to constrain the number of fractional digits in the lexical space.
<xs:simpleType name="fractionDigits">
<xs:restriction base="xs:decimal">
<xs:fractionDigits value="2"/>
</xs:restriction>
</xs:simpleType>| xs:group(definition) | Global elements group declaration that can be referenced within the same schema by other schemas. |
<xs:group
name = xs:NCName
>
Content: (xs:annotation?, (xs:all | xs:choice | xs:sequence))
</xs:group>
|
Groups of elements can be globally defined and used as containers, which can be referenced elsewhere in this schema or in other schemas. These containers, which are almost free of semantics, are very flexible and may be used as building blocks for the definition of local or global complex types.
Being global components, they can also be used to encapsulate element definitions that cannot be made global, such as unqualified elements in a schema with target namespaces, multiple elements with the same name in a schema, elements that should not be used as document elements, or elements that should be redefined through xs:redefine in other schemas.
Element groups can be redefined through xs:redefine; the redefinition can be either a restriction (similar to a complex type derivation by restriction) or an extension. (This is more flexible than a complex type extension since the location where the base group is included in the new group can be chosen, while the new elements are always located after the base type during a derivation by extension.)
Any of the three compositors (xs:all, xs:sequence, or xs:choice) may be used to create an element group.
When a group is created using a xs:all compositor, this group inherits all the restrictions of xs:all. In other words, including a xs:all compositor in a group is not a workaround to avoid the fundamental restrictions of xs:all!
Group definition cannot be recursive.
<xs:group name="name">
<xs:choice>
<xs:element ref="name"/>
<xs:sequence>
<xs:element ref="first-name"/>
<xs:element ref="middle-name" minOccurs="0"/>
<xs:element ref="last-name"/>
</xs:sequence>
</xs:choice>
</xs:group>| xs:group(reference) | Reference to a global elements group declaration or local definition (local definitions cannot be referenced). |
<xs:group
id = xs:ID
maxOccurs = ( xs:nonNegativeInteger | "unbounded" ) : "1"
minOccurs = xs:nonNegativeInteger : "1"
ref = xs:QName
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:group>
|
Used in a local context, xs:group is a reference to an element group. The effect is a logical replacement of the group reference by the group's content.
When a group is being redefined (through xs:redefine), a self reference (i.e., a reference to the group being redefined) specifically means "include the original content of the group at this location."
Groups cannot be recursive (i.e., a group cannot be referred to either directly or indirectly within its definition).
<xs:element name="author">
<xs:complexType>
<xs:sequence>
<xs:group ref="name"/>
<xs:element ref="born"/>
<xs:element ref="dead" minOccurs="0"/>
</xs:sequence>
<xs:attribute ref="id"/>
</xs:complexType>
</xs:element>| xs:import | Import of a W3C XML Schema for another namespace. |
<xs:import
id = xs:ID
namespace = xs:anyURI
schemaLocation = xs:anyURI
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:import>
|
xs:import identifies the location at which a W3C XML Schema validator may find the definition corresponding to namespaces other than the target namespace of the current schema.
All the global definitions (elements, attributes, element and attribute groups, simple and complex types) and unique and key constraints of the imported schemas can be referenced using a namespace prefix defined for the corresponding namespace URI.
The schema locations indicated in xs:import elements are only hints provided to the schema validators and may be omitted. In this case, the Recommendation states that "the schema author is leaving the identification of that schema to the instance, application or user, via the mechanisms described in Layer 3: Schema Document Access and Web-interoperability."
xs:import may also be used to import components with no target namespaces into schemas with target namespaces.
xs:import must not be used to import component definitions from the target namespace since two other elements are available for this purpose (see xs:include and xs:redefine).
Only global component definitions of the imported schemas can be referenced (local definitions can never be referenced).
The rules of scoping described for the xs:keyref element also apply to references between constraints for elements that belong to different namespaces (the root element of the keyref constraint must be an ancestor or self element of the root element for the unique or key constraint).
<xs:schema targetNamespace="http://dyomedea.com/ns/library"
elementFormDefault="qualified" attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ppl="http://dyomedea.com/ns/people"
xmlns:lib="http://dyomedea.com/ns/library">
<xs:import namespace="http://dyomedea.com/ns/people"
schemaLocation="simple-2-ns-ppl.xsd"/>
<xs:element name="library">
<xs:complexType>
<xs:sequence>
<xs:element name="book" type="lib:bookType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="bookType">
<xs:sequence>
<xs:element name="isbn" type="xs:NMTOKEN"/>
<xs:element name="title" type="xs:string"/>
<xs:element name="authors">
<xs:complexType>
<xs:sequence>
<xs:element ref="ppl:person"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="characters">
<xs:complexType>
<xs:sequence>
<xs:element ref="ppl:person" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:attribute name="available" type="xs:string" use="required"/>
</xs:complexType>
</xs:schema>| xs:include | Inclusion of a W3C XML Schema for the same target namespace. |
<xs:include
id = xs:ID
schemaLocation = xs:anyURI
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:include>
|
xs:include performs a straight inclusion of a schema within another schema that describes the same target namespace. It is possible, though, to include a schema that doesn't specify a target namespace. The included schema will be treated as adopting the target namespace of its includer in a schema with a target namespace. This possibility, often called "chameleon design," allows reuse of "transparent" schemas in the context of different namespaces.
The effect of a schema inclusion is a merge between the two schemas that are consolidated into a global schema. The schema that is included doesn't need to be a complete schema by itself.
It is not possible to use xs:include to include a schema describing another namespace. (xs:import should be used in this case.)
It is not possible to change the definitions of the included schemas. (xs:redefine should be used in this case.)
It is not possible to include a fragment of a schema. (General purpose inclusion mechanisms such as XInclude should be used in this case.)
<xs:include schemaLocation="simple-types.xsd"/>
| xs:key | Definition of a key. |
<xs:key
id = xs:ID
name = xs:NCName
{any attributes with non-schema namespace}
>
Content: ((xs:annotation?), (xs:selector, xs:field+))
</xs:key>
|
xs:key is used to define simple or compound keys by unambiguously identifying each element of a selected list of subelements within the scope of a root element.
xs:key is very similar to xs:unique. Like the constraints defined with xs:unique, keys defined with xs:key are unique in the scope of their root element and may be referenced by xs:keyref. The only difference between xs:key and xs:unique is the keys must be defined for each of the elements in the selection list, while unique identifiers may be undefined for elements in the selection list.
The root element for the key is the element in which the key is defined. The location of the root element must be carefully chosen since the unicity of the key is checked only within the node elements that are the key's children. Defining a root element that has multiple occurrences within a document leaves the possibility to define local keys that are unique only in the scope of each occurrence of a document. When a key is global to a document, defining it using the document element as a root may cause it to be less error-prone.
The contribution of xs:key to the PSVI is a node table in each occurrence of the root key element that contains the list of the key sequences for this root element. The scope of these node tables is limited to the root element in which they are contained and its ancestors. This scope is used to determine the behavior of the key references and impacts the choice of the key root element when the key is referenced (see xs:keyref).
These XPath-based features do not follow the object-oriented, namespace-aware general philosophy of W3C XML Schema. The XPath expressions are specified independently of the element's content model and the constraints for the elements of all the possible namespaces must be defined in the schema for the namespace of the constraint root element.
<xs:element name="library">
<xs:complexType>
.../...
</xs:complexType>
<xs:key name="book">
<xs:selector xpath="book"/>
<xs:field xpath="isbn"/>
</xs:key>
</xs:element>| xs:keyref | Definition of a key reference. |
<xs:keyref
id = xs:ID
name = xs:NCName
refer = xs:QName
{any attributes with non-schema namespace}
>
Content: ((xs:annotation?), (xs:selector, xs:field+))
</xs:keyref>
|
xs:keyref is used to define a reference to a simple or compound key or to a unique constraint.
The syntax of xs:keyref is very similar to the syntax of xs:key or xs:unique. The only difference is the refer attribute, which must contain the name of the referred key or unique constraint.
The root element for the keyref is the element in which the key is defined. The key reference is often defined with the same root element as its referred key or unique constraint, in which case the matching is simple and straightforward.
The root element of the keyref may also be defined in any element for which it is in the scope of a matching constraint node table, i.e., in all the ancestors of the root element of the referred key or unique constraint. In this case, an additional check is performed; for each matching key reference, the validator should test that the key or unique value is defined only once in all the matching key or unique root elements.
Key references defined in an ancestor of their referenced key or unique constraint actually add additional constraints on the referenced key or the unique key, which may be unexpected. A set of identifiers that match a key or unique constraint may become invalid when a key reference is defined.
If, for instance, local keys are defined to identify characters within the scope of a book, these keys would allow the reuse of the same characters' identifiers in distinct books, such as in the following:
<book>
<isbn> 0836217462 </isbn>
<title> Being a Dog Is a Full-Time Job </title>
<character id="PP">
<name> Peppermint Patty </name>
<qualification> bold, brash and tomboyish </qualification>
</character>
<character id="Snoopy">
<name> Snoopy </name>
<qualification> hero of the book </qualification>
</character>
<character id="Schroeder">
<name> Schroeder </name>
<qualification> brought classical music to the Peanuts strip</qualification>
</character>
<character id="Lucy">
<name> Lucy </name>
<qualification> bossy, crabby and selfish </qualification>
</character>
</book>
<book>
<isbn> 0805033106 </isbn>
<title> Peanuts Every Sunday </title>
<character id="Sally">
<name> Sally Brown </name>
<qualification> always looks for the easy way out </qualification>
</character>
<character id="Snoopy">
<name> Snoopy </name>
<qualification> extroverted beagle </qualification>
</character>
</book>If we add a key reference to reference these keys from the books, using the same identifier for characters in different books will be allowed if, and only if, these keys are not referenced.
This example is then valid:
<library>
<book>
<isbn> 0836217462 </isbn>
<title> Being a Dog Is a Full-Time Job </title>
<character id="PP">
<name> Peppermint Patty </name>
<qualification> bold, brash and tomboyish </qualification>
</character>
<character id="Snoopy">
<name> Snoopy </name>
<qualification> hero of the book </qualification>
</character>
<character id="Schroeder">
<name> Schroeder </name>
<qualification> brought classical music to the Peanuts strip </qualification>
</character>
<character id="Lucy">
<name> Lucy </name>
<qualification> bossy, crabby and selfish </qualification>
</character>
</book>
<book>
<isbn> 0805033106 </isbn>
<title> Peanuts Every Sunday </title>
<character id="Sally">
<name> Sally Brown </name>
<qualification> always looks for the easy way out </qualification>
</character>
<character id="Snoopy">
<name> Snoopy </name>
<qualification> extroverted beagle </qualification>
</character>
</book>
<comment about="Sally"> Sally is cute </comment>
</library>Because "Sally" is a unique key, it becomes invalid if we add a comment element referring to "Snoopy," which is mentioned twice.
A complete schema for this document might be the following (note how the xs:keyref refers to a xs:unique constraint, which is defined for a child of the current node):
<xs:schema elementFormDefault="qualified" xmlns:xs=
"http://www.w3.org/2001/XMLSchema">
<xs:element name="library">
<xs:complexType>
<xs:sequence>
<xs:element name="book" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="isbn" type="xs:NMTOKEN"/>
<xs:element name="title" type="xs:string"/>
<xs:element name="character" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="qualification" type="xs:string"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:key name="character">
<xs:selector xpath="character"/>
<xs:field xpath="@id"/>
</xs:key>
</xs:element>
<xs:element name="comment" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="about" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:unique name="book">
<xs:selector xpath="book"/>
<xs:field xpath="isbn"/>
</xs:unique>
<xs:keyref name="comment" refer="character">
<xs:selector xpath="comment"/>
<xs:field xpath="@about"/>
</xs:keyref>
</xs:element>
</xs:schema><xs:element name="library">
<xs:complexType>
.../...
</xs:complexType>
<xs:key name="ID">
<xs:selector xpath="book|author|character"/>
<xs:field xpath="@id"/>
</xs:key>
<xs:keyref name="IDREF" refer="ID">
<xs:selector xpath="book/author-ref|book/character-ref"/>
<xs:field xpath="@ref"/>
</xs:keyref>
</xs:element>| xs:length | Facet to define the length of a value. |
<xs:length
fixed = xs:boolean : "false"
id = xs:ID
value = xs:nonNegativeInteger
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:length>
|
May be used as facet for: xs:anyURI, xs:base64Binary, xs:ENTITIES, xs:ENTITY, xs:hexBinary, xs:ID, xs:IDREF, xs:IDREFS, xs:language, xs:Name, xs:NCName, xs:NMTOKEN, xs:NMTOKENS, xs:normalizedString, xs:NOTATION, xs:QName, xs:string, xs:token
xs:length is a facet that allows the definition of the length expressed in a unit that depends on the datatype. For most of the datatypes, the unit is the character as defined in the XML 1.0 Recommendation (i.e., Unicode characters defined by ISO/IEC 10646 that may be represented on more than 8 bits). The exceptions are the binary datatypes (xs:hexBinary and xs:base64Binary), for which lengths are expressed in number of bytes (8 bits) of binary data, and all the list datatypes, for which lengths are expressed in number of list items.
xs:length constrains the value space. In practice, this means that it is checked after whitespace replacement and collapsing, as defined by the xs:whiteSpace facet.
This is a logical length that has often no direct relation to the size of storage needed for the value.
The value of this facet cannot be modified during further restrictions, and the value of the fixed attribute is meaningless (the behavior is always as if the facet were fixed).
Although also not specified in the Recommendation, xs:length interacts with the xs:minLength and xs:maxLength and shouldn't set the length to a value not in the range between xs:minLength and xs:maxLength of its base type.
Fixing the xs:length facet doesn't fix the xs:maxLength and xs:minLength facets. To fix the three facets, define two restriction steps, since it is forbidden to apply these facets in the same restriction step.
<xs:simpleType name="standardNotations">
<xs:restriction base="xs:NOTATION">
<xs:length value="8"/>
</xs:restriction>
</xs:simpleType>| xs:list | Derivation by list. |
<xs:list
id = xs:ID
itemType = xs:QName
{any attributes with non-schema namespace}
>
Content: ((xs:annotation?), (xs:simpleType?))
</xs:list>
|
Derivation by list is the process of transforming a simple datatype (named the item type) into a whitespace-separated list of values from this datatype.
The item type can be defined inline by adding a simpleType definition as a child element of the list element, or by reference, using the itemType attribute (it is an error to use both).
The semantic and list of facets applicable on the item type are lost and the new datatype inherits a list of facets, which is common to all the list datatypes: xs:enumeration, xs:length, xs:maxLength, xs:minLength, and xs:pattern and its whitespaces are always collapsed.
After a derivation by list, the type of the resulting datatype is a list of whatever the item type was (atomic or union).
It is possible to define lists of atomic datatypes that allow whitespaces such as xs:string. In this case, the whitespaces are always considered separators.
The facets that can be applied to a list datatype are common to all the list datatypes, and add constraints to the list as a whole (rather than on the items composing the list). The constraints on the item composing the lists, therefore, need to be applied before the derivation by list.
The list separators cannot be chosen and are always whitespaces.
It is explicitly forbidden by the Recommendation to define lists of lists. Lists of unions and unions of lists are both allowed, so it should be possible to work around this limitation by defining a dummy union of a list and using this union as a list item if needed. However, lists of lists are effectively pointless, since all the list types have the same set of separators.
<xs:simpleType name="integerList"> <xs:list itemType="xs:integer"/> </xs:simpleType>
| xs:maxExclusive | Facet to define a maximum (exclusive) value. |
<xs:maxExclusive
fixed = xs:boolean : "false"
id = xs:ID
value = anySimpleType
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:maxExclusive>
|
May be used as facet for:xs:byte, xs:date, xs:dateTime, xs:decimal, xs:double, xs:duration, xs:float, xs:gDay, xs:gMonth, xs:gMonthDay, xs:gYear, xs:gYearMonth, xs:int, xs:integer, xs:long, xs:negativeInteger, xs:nonNegativeInteger, xs:nonPositiveInteger, xs:positiveInteger, xs:short, xs:time, xs:unsignedByte, xs:unsignedInt, xs:unsignedLong, xs:unsignedShort
xs:maxExclusive defines an exclusive maximum value. To be valid, a value must be strictly less than the value of xs:maxExclusive. This facet constrains the value space.
It is forbidden to define both xs:maxExclusive and xs:maxInclusive in the same restriction step. Although not explicitly specified in the Recommendation, it doesn't make sense to define several xs:maxExclusive facets in a single restriction step also.
Within a restriction step, xs:maxExclusive is also dependent on xs:minExclusive and xs:minInclusive, since using inconsistent values leads to datatypes with empty value spaces.
xs:maxExclusive must restrict the value space of its base type, and its value must be in the value space of the base type.
Fixing the maxExclusive facet doesn't fix the xs:maxInclusive facet. To fix both facets, define two restriction steps since it is forbidden to apply these two facets in the same restriction step.
<xs:simpleType name="myInteger">
<xs:restriction base="xs:integer">
<xs:minInclusive value="-2"/>
<xs:maxExclusive value="5"/>
</xs:restriction>
</xs:simpleType>| xs:maxInclusive | Facet to define a maximum (inclusive) value. |
<xs:maxInclusive
fixed = xs:boolean : "false"
id = xs:ID
value = anySimpleType
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:maxInclusive>
|
May be used as facet for: xs:byte, xs:date, xs:dateTime, xs:decimal, xs:double, xs:duration, xs:float, xs:gDay, xs:gMonth, xs:gMonthDay, xs:gYear, xs:gYearMonth, xs:int, xs:integer, xs:long, xs:negativeInteger, xs:nonNegativeInteger, xs:nonPositiveInteger, xs:positiveInteger, xs:short, xs:time, xs:unsignedByte, xs:unsignedInt, xs:unsignedLong, xs:unsignedShort
xs:maxInclusive defines an inclusive maximum value. To be valid, a value must be less than or equal to the value of xs:maxInclusive.
This facet constrains the value space.
It is forbidden to define both xs:maxExclusive and xs:maxInclusive in the same restriction step. Although not explicitly specified in the Recommendation, it doesn't make sense to define several xs:maxInclusive facets in a single restriction step either.
Within a restriction step, xs:maxInclusive is also dependent on xs:minExclusive and xs:minInclusive, since using inconsistent values leads to datatypes with empty value spaces.
xs:maxInclusive must restrict the value space of its base type, and its value must be in the value space of the base type.
Fixing the maxInclusive facet doesn't fix the xs:maxExclusive facet. To fix both facets, define two restriction steps since it is forbidden to apply these two facets in the same restriction step.
<xs:simpleType name="thousands">
<xs:restriction base="xs:double">
<xs:maxInclusive value="1e3"/>
</xs:restriction>
</xs:simpleType>| xs:maxLength | Facet to define a maximum length. |
<xs:maxLength
fixed = xs:boolean : "false"
id = xs:ID
value = xs:nonNegativeInteger
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:maxLength>
|
May be used as facet for:xs:anyURI, xs:base64Binary, xs:ENTITIES, xs:ENTITY, xs:hexBinary, xs:ID, xs:IDREF, xs:IDREFS, xs:language, xs:Name, xs:NCName, xs:NMTOKEN, xs:NMTOKENS, xs:normalizedString, xs:NOTATION, xs:QName, xs:string, xs:token
xs:maxLength is a facet that allows the definition of the maximum length expressed in a unit that depends on the datatype. For most of the datatypes, the unit is a character as defined in the XML 1.0 Recommendation (i.e., Unicode characters defined by ISO/IEC 10646 that may be represented on more than 8 bits). The exceptions are the binary datatypes (xs:hexBinary and xs:base64Binary), for which lengths are expressed in number of bytes (8 bits) of binary data, and all the list datatypes, for which lengths are expressed in number of list items.
xs:maxLength constrains the value space. In practice, this means that it is checked after whitespace replacement and collapsing, as defined by the xs:whiteSpace facet.
This is a logical length, which often has no direct relation to the size of storage needed for the value.
It is forbidden to define both xs:maxLength and xs:length in the same restriction step. Although not explicitly specified in the Recommendation, it doesn't make sense to define several xs:maxLength facets in a single restriction step either.
Within a restriction step, xs:maxLength is also dependent on xs:minLength, since using inconsistent values leads to datatypes with empty value spaces.
xs:maxLength must restrict the value space of its base type, and its value must be smaller than the value of xs:maxLength of its base type, if defined.
Although not specified in the Recommendation, xs:maxLength interacts with the xs:length and shouldn't be used if xs:length is defined for its base type.
Fixing the xs:maxLength facet doesn't fix the xs:length facet. To fix both facets, define two restriction steps since it is forbidden to apply these two facets in the same restriction step.
<xs:simpleType name="binaryImage">
<xs:restriction base="xs:hexBinary">
<xs:maxLength value="1024"/>
</xs:restriction>
</xs:simpleType>| xs:minExclusive | Facet to define a minimum (exclusive) value. |
<xs:minExclusive
fixed = xs:boolean : "false"
id = xs:ID
value = anySimpleType
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:minExclusive>
|
May be used as facet for: xs:byte, xs:date, xs:dateTime, xs:decimal, xs:double, xs:duration, xs:float, xs:gDay, xs:gMonth, xs:gMonthDay, xs:gYear, xs:gYearMonth, xs:int, xs:integer, xs:long, xs:negativeInteger, xs:nonNegativeInteger, xs:nonPositiveInteger, xs:positiveInteger, xs:short, xs:time, xs:unsignedByte, xs:unsignedInt, xs:unsignedLong, xs:unsignedShort
xs:minExclusive defines an exclusive minimum value. To be valid, a value must be strictly greater than the value of xs:minExclusive.
This facet constrains the value space.
It is forbidden to define both xs:minExclusive and xs:minInclusive in the same restriction step. Although not explicitly specified in the Recommendation, it doesn't make sense to define several xs:minExclusive facets in a single restriction step either.
Within a restriction step, xs:minExclusive is also dependent on xs:maxExclusive and xs:maxInclusive, since using inconsistent values leads to datatypes with empty value spaces.
xs:minExclusive must restrict the value space of its base type, and its value must be in the value space of the base type.
Fixing the xs:minExclusive facet doesn't fix the xs:minInclusive facet. To fix both facets, define two restriction steps since it is forbidden to apply these two facets in the same restriction step.
<xs:simpleType name="afterTeaTimeInParisInSummer">
<xs:restriction base="xs:time">
<xs:minExclusive value="17:00:00+02:00"/>
</xs:restriction>
</xs:simpleType>| xs:minInclusive | Facet to define a minimum (inclusive) value. |
<xs:minInclusive
fixed = xs:boolean : "false"
id = xs:ID
value = anySimpleType
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:minInclusive>
|
May be used as facet for: xs:byte, xs:date, xs:dateTime, xs:decimal, xs:double, xs:duration, xs:float, xs:gDay, xs:gMonth, xs:gMonthDay, xs:gYear, xs:gYearMonth, xs:int, xs:integer, xs:long, xs:negativeInteger, xs:nonNegativeInteger, xs:nonPositiveInteger, xs:positiveInteger, xs:short, xs:time, xs:unsignedByte, xs:unsignedInt, xs:unsignedLong, xs:unsignedShort
xs:minInclusive defines an inclusive minimum value. To be valid, a value must be greater than or equal to the value of xs:minInclusive.
This facet constrains the value space.
It is forbidden to define both xs:minInclusive and xs:minExclusive in the same restriction step. Although not explicitly specified in the Recommendation, it doesn't make sense to define several xs:minInclusive facets in a single restriction step either.
Within a restriction step, xs:minInclusive is also dependent on xs:maxExclusive and xs:maxInclusive, since using inconsistent values leads to datatypes with empty value spaces.
xs:minInclusive must restrict the value space of its base type, and its value must be in the value space of the base type.
Fixing the xs:minInclusive facet doesn't fix the xs:minExclusive facet. To fix both facets, define two restriction steps since it is forbidden to apply these two facets in the same restriction step.
<xs:simpleType name="positive">
<xs:restriction base="xs:double">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>| xs:minLength | Facet to define a minimum length. |
<xs:minLength
fixed = xs:boolean : "false"
id = xs:ID
value = xs:nonNegativeInteger
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:minLength>
|
May be used as facet for: xs:anyURI, xs:base64Binary, xs:ENTITIES, xs:ENTITY, xs:hexBinary, xs:ID, xs:IDREF, xs:IDREFS, xs:language, xs:Name, xs:NCName, xs:NMTOKEN, xs:NMTOKENS, xs:normalizedString, xs:NOTATION, xs:QName, xs:string, xs:token
xs:minLength is a facet that allows definition of the minimum length expressed in a unit that depends on the datatype. For most of the datatypes, the unit is the character as defined in the XML 1.0 Recommendation (i.e., Unicode characters defined by ISO/IEC 10646 that may be represented on more than 8 bits). The exceptions are the binary datatypes (xs:hexBinary and xs:base64Binary), for which lengths are expressed in number of bytes (8 bits) of binary data, and all the list datatypes, for which lengths are expressed in number of list items.
xs:minLength constrains the value space. In practice, this means that it is checked after whitespace replacement and collapsing, as defined by the xs:whiteSpace facet.
This is a logical length, which often has no direct relation on the size of storage needed for the value.
It is forbidden to define both xs:minLength and xs:length in the same restriction step. Although not explicitly specified in the Recommendation, it doesn't make sense to define several xs:minLength facets in a single restriction step either.
Within a restriction step, xs:minLength is also dependent on xs:maxLength, since using inconsistent values leads to datatypes with empty value spaces.
xs:minLength must restrict the value space of its base type, and its value must be greater than the value of xs:minLength of its base type if defined.
Although not specified in the Recommendation, xs:minLength interacts with xs:length and shouldn't be used if xs:length is defined for its base type.
Fixing the xs:minLength facet doesn't fix the xs:length facet. To fix both facets, define two restriction steps since it is forbidden to apply these two facets in the same restriction step.
<xs:simpleType name="longName">
<xs:restriction base="xs:NCName">
<xs:minLength value="6"/>
</xs:restriction>
</xs:simpleType>| xs:notation | Declaration of a notation. |
<xs:notation
id = xs:ID
name = xs:NCName
public = xs:token
system = xs:anyURI
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:notation>
|
xs:notation is used to declare a notation just like the NOTATION declarations in DTDs. The main difference is that W3C XML Schema notations are namespace-aware and can be imported between schemas. When these declarations are used, the notations are used in xs:enumeration facets to create simple types.
Notations are very seldom used in real world applications.
<xs:notation name="jpeg" public="image/jpeg"
system="file:///usr/bin/xv"/>
<xs:notation name="gif" public="image/gif"
system="file:///usr/bin/xv"/>
<xs:notation name="png" public="image/png"
system="file:///usr/bin/xv"/>
<xs:notation name="svg" public="image/svg"
system="file:///usr/bin/xsmiles"/>
<xs:notation name="pdf" public="application/pdf"
system="file:///usr/bin/acroread"/>
<xs:simpleType name="graphicalFormat">
<xs:restriction base="xs:NOTATION">
<xs:enumeration value="jpeg"/>
<xs:enumeration value="gif"/>
<xs:enumeration value="png"/>
<xs:enumeration value="svg"/>
<xs:enumeration value="pdf"/>
</xs:restriction>
</xs:simpleType>| xs:pattern | Facet to define a regular expression pattern constraint. |
<xs:pattern
id = xs:ID
value = anySimpleType
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:pattern>
|
May be used as facet for:xs:anyURI, xs:base64Binary, xs:boolean, xs:byte, xs:date, xs:dateTime, xs:decimal, xs:double, xs:duration, xs:ENTITY, xs:float, xs:gDay, xs:gMonth, xs:gMonthDay, xs:gYear, xs:gYearMonth, xs:hexBinary, xs:ID, xs:IDREF, xs:int, xs:integer, xs:language, xs:long, xs:Name, xs:NCName, xs:negativeInteger, xs:NMTOKEN, xs:nonNegativeInteger, xs:nonPositiveInteger, xs:normalizedString, xs:NOTATION, xs:positiveInteger, xs:QName, xs:short, xs:string, xs:time, xs:token, xs:unsignedByte, xs:unsignedInt, xs:unsignedLong, xs:unsignedShort
xs:pattern allows the definition of regular expression patterns over the lexical space. The syntax used for these patterns has been borrowed from Perl regular expressions, and has been enhanced to support the Unicode character blocks.
When multiple xs:pattern facets are defined in a single derivation step, a value is considered valid if it matches at least one of the patterns, meaning that a logical or is performed on all the patterns defined in a same derivation step.
Patterns are applied to the lexical space of the base datatype, meaning that a logical and is performed on patterns defined in different derivation steps.
The syntax of these patterns is explained in more detail in Chapter 6, "Using Regular Expressions to Specify Simple Datatypes".
xs:pattern is a common workaround to define datatypes that look like datatypes missing from the list of predefined datatypes. It is possible, for instance, to simulate decimals using a separator other than the decimal point with a pattern. Such datatypes need to be based on xs:token, and will still not have the semantic of xs:decimal and its list of facets.
xs:pattern cannot be fixed.
<xs:simpleType name="nonScientific">
<xs:restriction base="xs:float">
<xs:pattern value="[^eE]*"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="noLeading0">
<xs:restriction base="xs:float">
<xs:pattern value="[^0].*"/>
</xs:restriction>
</xs:simpleType>| xs:redefine | Inclusion of a W3C XML Schema for the same namespace with possible override. |
<xs:redefine
id = xs:ID
schemaLocation = xs:anyURI
{any attributes with non-schema namespace}
>
Content: (xs:annotation | (xs:simpleType | xs:complexType | xs:group |
xs:attributeGroup))*
</xs:redefine>
|
xs:redefine is similar to xs:include with one exception: the definition of simple and complex types and attribute and element groups can be changed. Changes performed on these components must lead to components that are valid restrictions or extensions of the original ones.
Simple and complex types are redefined using the usual mechanism of derivation: the new types must be defined as derivations by restriction or extension of their previous definition, which is considered to be the base type.
Element and attribute groups are redefined by giving a new definition, and may refer to themselves to indicate that the content of their original definition must be included. In this case, this self-reference is not considered a recursive definition (which is forbidden in element and attribute groups), but an extension of the original group.
When xs:redefine is used and no redefinitions are specified, its effect is similar to xs:include.
xs:redefine can be used only to include schemas with either the same target namespace or no target namespace. There is no equivalent to import and redefine schema definitions in a single operation. The schema must be redefined and imported in two different operations.
Arbitrary redefinitions are not allowed. After redefinition, the components must be valid derivations (by extension or restriction) of their definitions before redefinition.
xs:element, xs:attribute, and xs:notation cannot be redefined.
<xs:redefine schemaLocation="complex-types2.xsd">
<xs:complexType name="book">
<xs:complexContent>
<xs:restriction base="book">
<xs:sequence>
<xs:element ref="isbn"/>
<xs:element ref="title"/>
<xs:element ref="author" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="character" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="bookID"/>
<xs:attribute ref="available"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:redefine>| xs:restriction(simple type) | Derivation of a simple datatype by restriction. |
<xs:restriction
base = xs:QName
id = xs:ID
{any attributes with non-schema namespace}
>
Content: ((xs:annotation?), (xs:simpleType?, (xs:minExclusive |
xs:minInclusive | xs:maxExclusive | xs:maxInclusive |
xs:totalDigits | xs:fractionDigits | xs:length |
xs:minLength | xs:maxLength | xs:enumeration |
xs:whiteSpace | xs:pattern)*))
</xs:restriction>
|
Deriving a simple datatype by restriction is the action of defining a new datatype by adding constraints (called facets) on a base datatype to restrict its lexical and value spaces.
The base datatype can be defined by reference (using the base attribute) or inline (through a xs:simpleType element defining a local datatype).
Each of the facets is defined as a child element after the optional embedded xs:simpleType definition.
Each facet has its own meaning and depending on the facet, acts on the lexical space, on the value space, or on the whitespace transformation performed between the lexical and value spaces. Depending on the base datatype, a facet may also have a different behavior. See the detailed description of each facet in this chapter for more information.
Derivations by restrictions can be applied to any type of datatype (atomic, list, or union), and don't change the type of the datatype (atomic, list, and union datatypes stay atomic, list, or union, after a derivation by restriction).
The same element name (xs:restriction) is used in three different contexts with highly different meanings. Be careful to distinguish restriction in the context of a simple datatype, a simple content model, and a complex content model.
The base attribute and the xs:simpleType embedded definition must not be used together (the base type is defined either by reference or embedded).
<xs:simpleType name="myInteger">
<xs:restriction base="xs:integer">
<xs:minInclusive value="-2"/>
<xs:maxExclusive value="5"/>
</xs:restriction>
</xs:simpleType>| xs:restriction(simple content) | Derivation of a simple content model by restriction. |
<xs:restriction
base = xs:QName
id = xs:ID
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:simpleType?, (xs:minExclusive |
xs:minInclusive | xs:maxExclusive | xs:maxInclusive |
xs:totalDigits | xs:fractionDigits | xs:length |
xs:minLength | xs:maxLength | xs:enumeration | xs:whiteSpace |
xs:pattern)*)?, ((xs:attribute | xs:attributeGroup)*,
xs:anyAttribute?))
</xs:restriction>
|
The restriction of simple content complex types is an operation that allows the addition of new constraints to both the attributes and the text node allowed in simple content elements (this reduces the set of valid instances structures). The restriction of the text node is done using the same facets that are available for restricting simple types; the restriction of the attributes is done by providing a list of modified attribute definitions or references. The attribute types used in this list must be identical or explicit derivations by restriction of the types used during the definition of the base type. The controls applied to the attributes must result in a restriction of their definition (for instance, a value may be fixed, an attribute that was optional may become either required or prohibited, etc.).
The same element name (xs:restriction) is used in three different contexts with highly different meanings. Be careful to distinguish restriction in the context of a simple datatype, a simple content model, and a complex content model.
<xs:element name="title">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="tokenWithLangAndNote">
<xs:maxLength value="255"/>
<xs:attribute name="lang">
<xs:simpleType>
<xs:restriction base="xs:language">
<xs:enumeration value="en"/>
<xs:enumeration value="es"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:restriction>
</xs:simpleContent>
</xs:complexType>
</xs:element>| xs:restriction(complex content) | Derivation of a complex content model by restriction. |
<xs:restriction
base = xs:QName
id = xs:ID
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:group | xs:all | xs:choice | xs:sequence)?,
((xs:attribute | xs:attributeGroup)*, xs:anyAttribute?))
</xs:restriction>
|
The restriction of a complex content complex type is an operation that allows the addition of new constraints to both the attributes and child elements in complex content elements (this reduces the set of valid instances structures). It can be seen as a declaration of intention that a new content model is a subset of a base content model (the declaration by intention is checked by the schema processors). The new content model is entirely described under xs:restriction and must represent a restriction to what was allowed by the base content model (i.e., any content valid per the restricted type must also be valid per the base type). The only exception is attributes whose description may be skipped under xs:restriction, if not changed.
To facilitate the checking done by schema processors, the new derived content model must follow the definition of the base type particle per particle. Each of them must be explicit derivations by restriction.
The same element name (xs:restriction) is used in three different contexts with highly different meanings. Be careful to be able to distinguish restrictions in the context of a simple datatype, a simple content model, and a complex content model.
<xs:element name="author">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="person">
<xs:sequence>
<xs:element ref="name"/>
<xs:element ref="born"/>
<xs:element ref="dead" minOccurs="0"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>| xs:schema | Document element of a W3C XML Schema. |
<xs:schema
attributeFormDefault = ( "qualified" | "unqualified" ) : "unqualified"
blockDefault = ( "#all" | list of ( "extension" | "restriction" |
"substitution" ) ) : ""
elementFormDefault = ( "qualified" | "unqualified" ) : "unqualified"
finalDefault = ( "#all" | list of ( "extension" | "restriction" )
) : ""
id = xs:ID
targetNamespace = xs:anyURI
version = xs:token
xml:lang = xml:lang
{any attributes with non-schema namespace}
>
Content: ((xs:include | xs:import | xs:redefine | xs:annotation)*, (,
( | (xs:simpleType | xs:complexType | xs:group |
xs:attributeGroup) | xs:element | xs:attribute |
xs:notation), xs:annotation*)*)
</xs:schema>
|
xs:schema is the document (root) element of any W3C XML Schema. It's both a container for all the declarations and definitions of the schema and a place holder for a number of default values expressed as attributes. The compositors embedded directly under xs:schema have a special role, since they are considered global definitions that can be referenced elsewhere.
A xs:schema element (and therefore a schema) is associated with a maximum of one namespace and must import the definitions of compositors for other namespaces if needed.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="name" type="xs:string"/> <xs:element name="qualification" type="xs:string"/> <xs:element name="born" type="xs:date"/> <xs:element name="dead" type="xs:date"/> <xs:element name="isbn" type="xs:NMTOKEN"/> <xs:attribute name="id" type="xs:ID"/> <xs:attribute name="available" type="xs:boolean"/> <xs:attribute name="lang" type="xs:language"/> .../... </xs:schema>
| xs:selector | Definition of the the path selecting an element for a uniqueness constraint. |
<xs:selector
id = xs:ID
xpath = xs:token
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:selector>
|
xs:selector is used to define the element on which a uniqueness constraint or reference is checked (it cannot be an attribute, since attributes are already unique per XML 1.0). It is identified by a relative XPath expression.
The constraint is checked while looping on the XPath expression is resolved relative to the root element of the constraint. It serves as the location from which xs:field XPath expressions are resolved.
The xpath attribute uses a simple subset of XPath 1.0. The motivation of the W3C XML Schema Working Group for defining this subset is to simplify the work of the implementers of schema processors, and also to define a subset that constrains the path to stay within the scope of the current element.
This subset is restricted to use the child only; self and descendant, and self XPath axes through their abbreviated syntaxes without including any test in any of the XPath location steps and without using any XPath functions. It is identical to the subset defined for xs:field, except that attributes are allowed in xs:field and forbidden in xs:selector.
The formal extended BNF given in the W3C Recommendation is as follow:
Selector ::= Path ( '|' Path )* Path ::= ('.//')? Step ( '/' Step )* Step ::= '.' |
NameTest NameTest ::= QName | '*' | NCName ':' '*'<xs:element name="book" maxOccurs="unbounded">
<xs:complexType>
.../...
</xs:complexType>
<xs:unique name="book">
<xs:selector xpath="book"/>
.../...
</xs:unique>
</xs:element>| xs:sequence(outside a group) | Compositor to define an ordered group of elements. |
<xs:sequence
id = xs:ID
maxOccurs = ( xs:nonNegativeInteger | "unbounded" ) : "1"
minOccurs = xs:nonNegativeInteger : "1"
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:element | xs:group | xs:choice |
xs:sequence | xs:any) )*)
</xs:sequence>
|
This compositor is used to define an ordered list or set of elements. It can hold its own minOccurs and maxOccurs attributes to define a number of occurrences of the whole sequence.
xs:sequence may not be included in an xs:all compositor, and xs:sequence may not include xs:all compositors.
When xs:sequence is included in an xs:group compositor, its content model is slightly different (see xs:sequence(within a group) (within a group)).
<xs:element name="library">
<xs:complexType>
<xs:sequence>
<xs:element ref="book" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>| xs:sequence(within a group) | Compositor to define an ordered group of elements. The number of occurrences cannot be defined when xs:all is used within a group. |
<xs:sequence
id = xs:ID
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:element | xs:group | xs:choice |
xs:sequence | xs:any) )*)
</xs:sequence>
|
This compositor is used to define ordered list of elements.
xs:sequence may not include xs:all compositors.
When xs:sequence is used outside an xs:group compositor, its content model is slightly different (see xs:sequence(outside a group) (outside a group)).
<xs:group name="name">
<xs:sequence>
<xs:element ref="name"/>
<xs:sequence minOccurs="0">
<xs:element ref="middle-name" minOccurs="0"/>
<xs:element ref="last-name"/>
</xs:sequence>
</xs:sequence>
</xs:group>| xs:simpleContent | Simple content model declaration. |
<xs:simpleContent
id = xs:ID
{any attributes with non-schema namespace}
>
Content: ((xs:annotation?), (xs:restriction | xs:extension))
</xs:simpleContent>
|
This element allows the definition of a simple content model by derivation of a simple type or of another simple content complex type. It is not a component by itself (simple contents are not named) but rather declaration of the intention to define a simple content model by derivation.
The derivation method is not defined by the xs:simpleContent element, but by the choice of its child element (which is xs:restriction for a derivation by restriction, or xs:extension for a derivation by extension).
None.
<xs:element name="title">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>| xs:simpleType(global definition) | Global simple type declaration that can be referenced within the same schema by other schemas. |
<xs:simpleType
final = ( "#all" | ( "list" | "union" | "restriction" ) )
id = xs:ID
name = xs:NCName
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:restriction | xs:list | xs:union))
</xs:simpleType>
|
Global user-defined simple datatypes are defined directly under the xs:schema document element (or redefined using xs:redefine) outside of the scope of any specific content model. They can be referenced through their qualified name in the same schema or by any other schema that has included or imported this schema.
Like local simple datatypes, these are defined by derivation from other simple datatypes (either predefined by W3C XML Schema or other user-defined datatypes) using one of the three derivation methods available for simple types: xs:restriction to add new constraints to a datatype, xs:list to define lists of values, and xs:union to perform the union of the lexical spaces of several datatypes).
The name attribute is unqualified since the datatype is considered to belong to the target namespace of the schema in which it is defined. During a reference, the prefix that has been defined for this namespace needs to be added.
Although simple datatypes are considered to belong to the target namespace of schema in which they are defined, they can be referenced to create new datatypes, attributes, or elements for any namespace.
Further derivations (by list, union, restriction, or all) can be blocked using the final attribute.
W3C XML Schema doesn't provide any mechanism to add new primary datatypes, new facets, or to act on the transformation performed between the lexical and value spaces (for instance, it is not possible to change the representation of the decimal point).
<xs:simpleType name="totalDigits">
<xs:restriction base="xs:integer">
<xs:totalDigits value="5"/>
</xs:restriction>
</xs:simpleType>| xs:simpleType(local definition) | Local simple type definition (local definitions cannot be referenced). |
<xs:simpleType
id = xs:ID
{any attributes with non-schema namespace}
>
Content: (xs:annotation?, (xs:restriction | xs:list | xs:union))
</xs:simpleType>
|
Local simple datatypes are defined directly where needed (during element, attribute, or other simple type definitions) for local anonymous usage, and cannot be referenced as such in other places of a schema.
Like global simple datatypes, these are defined by derivation from other simple datatypes (either predefined by W3C XML Schema or other user-defined datatypes) using one of the three derivation methods available for simple types: xs:restriction to add new constraints to a datatype, xs:list to define lists of values, and xs:union to perform the union of the lexical spaces of several datatypes).
W3C XML Schema doesn't provide any mechanism for creating new primary datatypes, new facets, or to act on the transformation performed between the lexical and value spaces (for instance, it is not possible to change the representation of the decimal point).
<xs:simpleType name="myInteger">
<xs:restriction>
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:maxExclusive value="5"/>
</xs:restriction>
</xs:simpleType>
<xs:minInclusive value="-2"/>
</xs:restriction>
</xs:simpleType>| xs:totalDigits | Facet to define the total number of digits of a numeric datatype. |
<xs:totalDigits
fixed = xs:boolean : "false"
id = xs:ID
value = xs:positiveInteger
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:totalDigits>
|
May be used as facet for: xs:byte, xs:decimal, xs:int, xs:integer, xs:long, xs:negativeInteger, xs:nonNegativeInteger, xs:nonPositiveInteger, xs:positiveInteger, xs:short, xs:unsignedByte, xs:unsignedInt, xs:unsignedLong, xs:unsignedShort
xs:totalDigits defines the maximum number of digits of decimal and derived datatypes (both after and before the decimal point, not counting the decimal point itself).
This facet constrains the value space, which means that the number of digits is checked after the value is transformed to its canonical form and the leading and trailing zeros are removed.
It is also possible to use xs:pattern to constrain the number of total digits in the lexical space.
Within a restriction step, xs:totalDigits is dependent on xs:fractionDigits since using inconsistent values leads to datatypes with empty value spaces.
xs:totalDigits must restrict the value space of its base type. Its value must be smaller than the value of the xs:totalDigits of its base type if defined.
<xs:simpleType name="totalDigits">
<xs:restriction base="xs:integer">
<xs:totalDigits value="5"/>
</xs:restriction>
</xs:simpleType>| xs:union | Derivation of simple datatypes by union. |
<xs:union
id = xs:ID
memberTypes = list of xs:QName
{any attributes with non-schema namespace}
>
Content: ((xs:annotation?), (xs:simpleType*))
</xs:union>
|
Deriving a simple datatype by union merges the lexical spaces of several simple datatypes (called member types) to create a new simple datatype.
Whatever the type (atomic, list, or union) of the member types, the resulting datatype has a type union.
The member types can be defined either by reference (through the memberTypes attribute) or embedded as simple datatype local definitions in the xs:union element. Both styles can be mixed.
The semantic of the member datatypes is lost at least as far as validation is concerned, and the only facets that can be further applied to the resulting datatype are xs:pattern and xs:enumeration.
However, the semantic of the member datatypes isn't completely lost for an application built on a PSVI, since the validator needs to perform canonicalization according to the first member type that matches the instance value. This implies that order matters in the list of member types. When both styles are used, the datatypes referenced in the memberTypes are tested before the locally defined datatypes.
None.
<xs:simpleType name="integerOrData"> <xs:union memberTypes="xs:integer xs:date"/> </xs:simpleType>
| xs:unique | Definition of a uniqueness constraint. |
<xs:unique
id = xs:ID
name = xs:NCName
{any attributes with non-schema namespace}
>
Content: ((xs:annotation?), (xs:selector, xs:field+))
</xs:unique>
|
xs:unique is used to define simple or compound constraints, which unambiguously identify each element in which they are present, from a selected list of subelements within the scope of a root element.
xs:unique is very similar to xs:key. Like the constraints defined with xs:key, constraints defined with xs:unique are unique in the scope of their root element and may be referenced by xs:keyref. The only difference between xs:unique and xs:key is that the xs:unique keys may be undefined in any of the elements in the selection list, while xs:key identifiers must be defined for all the elements in the selection list.
The root element for the constraint is the element in which the constraint is defined. The location of the root element must be carefully chosen since the unity of the constraint is checked only within the node elements that are its children. Defining a root element that has multiple occurrences within a document leaves the possibility of defining local constraints that are unique only in the scope of each occurrence of a document. When a constraint is global to a document, defining it using the document element as a root may cause it to be less error-prone.
The contribution of xs:unique to the PSVI is a node table in each occurrence of the root key element that contains the list of the key sequences for this root element. The scope of these node tables is limited to the root element in which they are contained and all its ancestors. This scope is used to determine the behavior of the key references and impacts the choice of the constraint root element when the constraint is referenced (see the section xs:keyref).
These XPath-based features do not follow the object-oriented, namespace-aware general philosophy of W3C XML Schema. The XPath expressions are specified independently of the element's content model, and the constraints for the elements of all the possible namespaces must be defined in the schema for the namespace of the constraint root element.
<xs:element name="library">
<xs:complexType>
.../...
</xs:complexType>
<xs:unique name="book">
<xs:selector xpath="book"/>
<xs:field xpath="isbn"/>
</xs:unique>
</xs:element>| xs:whiteSpace | Facet to define whitespace behavior. |
<xs:whiteSpace
fixed = xs:boolean : "false"
id = xs:ID
value = ( "preserve" | "replace" | "collapse" )
{any attributes with non-schema namespace}
>
Content: (xs:annotation?)
</xs:whiteSpace>
|
May be used as facet for:xs:ENTITIES, xs:ENTITY, xs:ID, xs:IDREF, xs:IDREFS, xs:language, xs:Name, xs:NCName, xs:NMTOKEN, xs:NMTOKENS, xs:normalizedString, xs:string, xs:token
This facet defines the treatment to perform on whitespace--i.e., #x20 (space), #x9 (tab), #xA (linefeed), and #xD (carriage return)--during the transformation between the lexical and value spaces.
Its values are preserve (whitespace characters are kept unchanged), replace (all instances of whitespace are replaced with a space), and collapse (leading and trailing whitespace is removed and all the other sequences of contiguous whitespace are replaced by a single space).
This is the only facet (or feature of W3C XML Schema) that interacts with the canonicalization transformation.
It is not possible to "relax" the whitespace behavior during a restriction: if a datatype has a whitespace set as preserve, its derived datatypes can have any whitespace behavior, but if its whitespace is set as replace, its derived datatypes can only have whitespace equal to replace or collapse. If its whitespace is equal to collapse, all its derived datatypes must have the same behavior.
This limitation is somewhat paradoxical since it allows the actual expansion of the lexical space of a datatype during a derivation by restriction.
<xs:simpleType name="CapitalizedNameWS">
<xs:restriction base="xs:string">
<xs:whiteSpace value="collapse"/>
<xs:pattern value="([A-Z]([a-z]*) ?)+"/>
</xs:restriction>
</xs:simpleType> |  | |
| 14.5. Which One and What For? |  | 16. Datatype Reference Guide |
Copyright © 2002 O'Reilly & Associates. All rights reserved.