 |  |
| |
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:vdv@dyomedea.com)
</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? |