This document is also available in these non-normative formats: XML, XHTML with changes since version 1.0 marked, XHTML with changes since previous Working Draft marked, Independent copy of the schema for schema documents, Independent copy of the DTD for schema documents, Independent tabulation of components and microcomponents, and List of translations.
Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
XML Schema: Structures specifies the XML Schema definition language, which offers facilities for describing the structure and constraining the contents of XML documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in XML and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML document type definitions (DTDs). This specification depends on XML Schema 1.1 Part 2: Datatypes.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a Public Working Draft of XML Schema 1.1. It is here made available for review by W3C members and the public. It is intended to give an indication of the W3C XML Schema Working Group's intentions for this new version of the XML Schema language and our progress in achieving them. It attempts to be complete in indicating what will change from version 1.0, but does not specify in all cases how things will change.
This draft was published on 30 March 2006. The major changes since the previous draft are:
For those primarily interested in the changes since version 1.0, the Changes since version 1.0 (§G) appendix, which summarizes both changes already made and also those in prospect, with links to the relevant sections of this draft, is the recommended starting point. Accompanying versions of this document display in color all changes to normative text since version 1.0 and since the previous Working Draft.
Please send comments on this Working Draft to www-xml-schema-comments@w3.org (archive).
Although feedback based on any aspect of this specification is welcome, there are certain aspects of the design presented herein for which the Working Group is particularly interested in feedback. These are designated "priority feedback" aspects of the design, and identified as such in editorial notes at appropriate points in this draft.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced by the W3C XML Schema Working Group as part of the W3C XML Activity. The goals of the XML Schema language version 1.1 are discussed in the Requirements for XML Schema 1.1 document. The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
The English version of this specification is the only normative version. Information about translations of this document is available at http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlschema.
Text in this document which does not now have Working Group consensus is marked: ||this way||.
This document sets out the structural part (XML Schema: Structures) of the XML Schema definition language.
Chapter 2 presents a Conceptual Framework (§2) for XML Schemas, including an introduction to the nature of XML Schemas and an introduction to the XML Schema abstract data model, along with other terminology used throughout this document.
Chapter 3, Schema Component Details (§3), specifies the precise semantics of each component of the abstract model, the representation of each component in XML, with reference to a DTD and XML Schema for an XML Schema document type, along with a detailed mapping between the elements and attribute vocabulary of this representation and the components and properties of the abstract model.
Chapter 4 presents Schemas and Namespaces: Access and Composition (§4), including the connection between documents and schemas, the import, inclusion and redefinition of declarations and definitions and the foundations of schema-validity assessment.
Chapter 5 discusses Schemas and Schema-validity Assessment (§5), including the overall approach to schema-validity assessment of documents, and responsibilities of schema-aware processors.
The normative appendices include a Schema for Schema Documents (Structures) (normative) (§A) for the XML representation of schemas and References (normative) (§B).
The non-normative appendices include the DTD for Schemas (non-normative) (§K) and a Glossary (non-normative) (§J).
This document is primarily intended as a language definition reference. As such, although it contains a few examples, it is not primarily designed to serve as a motivating introduction to the design and its features, or as a tutorial for new users. Rather it presents a careful and fully explicit definition of that design, suitable for guiding implementations. For those in search of a step-by-step introduction to the design, the non-normative [XML Schema: Primer] is a much better starting point than this document.
The Working Group has two main goals for this version of W3C XML Schema:
These goals are in tension with one another. The Working Group's strategic guidelines for changes between versions 1.0 and 1.1 can be summarized as follows:
The aim with regard to compatibility is that
The purpose of XML Schema: Structures is to define the nature of XML schemas and their component parts, provide an inventory of XML markup constructs with which to represent schemas, and define the application of schemas to XML documents.
The purpose of an XML Schema: Structures schema is to define and describe a class of XML documents by using schema components to constrain and document the meaning, usage and relationships of their constituent parts: datatypes, elements and their content and attributes and their values. Schemas may also provide for the specification of additional document information, such as normalization and defaulting of attribute and element values. Schemas have facilities for self-documentation. Thus, XML Schema: Structures can be used to define, describe and catalogue XML vocabularies for classes of XML documents.
Any application that consumes well-formed XML can use the XML Schema: Structures formalism to express syntactic, structural and value constraints applicable to its document instances. The XML Schema: Structures formalism allows a useful level of constraint checking to be described and implemented for a wide spectrum of XML applications. However, the language defined by this specification does not attempt to provide all the facilities that might be needed by any application. Some applications may require constraint capabilities not expressible in this language, and so may need to perform their own additional validations.
The definition of XML Schema: Structures depends on the following specifications: [XML-Infoset], [XML-Namespaces 1.1], [XPath], and [XML Schema: Datatypes].
See Required Information Set Items and Properties (normative) (§E) for a tabulation of the information items and properties specified in [XML-Infoset] which this specification requires as a precondition to schema-aware processing.
[XML Schema: Datatypes] defines some datatypes which depend on definitions in [XML 1.1] and [XML-Namespaces 1.1]; those definitions, and therefore the datatypes based on them, vary between version 1.0 ([XML 1.0], [XML-Namespaces 1.0]) and version 1.1 ([XML 1.1], [XML-Namespaces 1.1]) of those specifications. In any given schema-validity-·assessment· episode, the choice of the 1.0 or the 1.1 definition of those datatypes is implementation-defined.
Conforming implementations of this specification may provide either the 1.1-based datatypes or the 1.0-based datatypes, or both. If both are supported, the choice of which datatypes to use in a particular assessment episode should be under user control.
The section introduces the highlighting and typography as used in this document to present technical material.
Aspects of this document which the Working Group are committed to changing, but where (all) changes are not yet in place, are signalled by the appearance of an Issue, with a link to the associated version 1.1 Requirement, for example:
Issue (xmpl):Issue nnnn (RQ-nnn)
All such issues are tabulated in Outstanding issues (§G.2).
Special terms are defined at their point of introduction in the text. For example [Definition:] a term is something used with a special meaning. The definition is labeled as such and the term it defines is displayed in boldface. The end of the definition is not specially marked in the displayed or printed text. Uses of defined terms are links to their definitions, set off with middle dots, for instance ·term·.
Non-normative examples are set off in boxes and accompanied by a brief explanation:
<schema targetNamespace="http://www.example.com/XMLSchema/1.0/mySchema">
The definition of each kind of schema component consists of a list of its properties and their contents, followed by descriptions of the semantics of the properties:
References to properties of schema components are links to the relevant definition as exemplified above, set off with curly braces, for instance {example property}.
The correspondence between an element information item which is part of the XML representation of a schema and one or more schema components is presented in a tableau which illustrates the element information item(s) involved. This is followed by a tabulation of the correspondence between properties of the component and properties of the information item. Where context may determine which of several different components may arise, several tabulations, one per context, are given. The property correspondences are normative, as are the illustrations of the XML representation element information items.
In the XML representation, bold-face
attribute names (e.g. count below) indicate a required
attribute information item, and the rest are
optional. Where an attribute information item has an enumerated type
definition, the values are shown separated by vertical bars, as for
size
below; if there is a default value, it is shown
following a colon. Where an attribute information item has a built-in simple
type definition defined in [XML Schema: Datatypes], a hyperlink to its
definition therein is given.
The allowed content of the information item is
shown as a grammar fragment, using the Kleene operators ?
,
*
and +
. Each element name therein is a hyperlink to
its own illustration.
example
Element Information ItemReferences to elements in the text are links to the relevant illustration as exemplified above, set off with angle brackets, for instance <example>.
References to properties of information items as defined in [XML-Infoset] are notated as links to the relevant section thereof, set off with square brackets, for example [children].
Properties which this specification defines for information items are introduced as follows:
References to properties of information items defined in this specification are notated as links to their introduction as exemplified above, set off with square brackets, for example [new property].
The following highlighting is used for non-normative commentary in this document:
Within normative prose in this specification, the words may, should, must and must not are defined as follows:
These definitions describe in terms specific to this document the meanings assigned to these terms by [IETF RFC 2119]. The specific wording follows that of [XML 1.1].
This specification provides a definition of error and of conformant processors' responsibilities with respect to errors in Schemas and Schema-validity Assessment (§5).
This chapter gives an overview of XML Schema: Structures at the level of its abstract data model. Schema Component Details (§3) provides details on this model, including a normative representation in XML for the components of the model. Readers interested primarily in learning to write schema documents may wish to first read [XML Schema: Primer] for a tutorial introduction, and only then consult the sub-sections of Schema Component Details (§3) named XML Representation of ... for the details.
An XML Schema ||consists||||is a set|| of components such as type definitions and element declarations. These can be used to assess the validity of well-formed element and attribute information items (as defined in [XML-Infoset]), and furthermore may specify augmentations to those items and their descendants. This augmentation makes explicit information which may have been implicit in the original document, such as normalized and/or default values for attributes and elements and the types of element and attribute information items. ||The input information set can also be augmented with information about the validity of the item, or about other properties described in this specification.|| [Definition:] We refer to the augmented infoset which results from conformant processing as defined in this specification as the post-schema-validation infoset, or PSVI. ||Conforming processors may provide access to different parts of the PSVI, as described in Subset of the Post-schema-validation Infoset (§D.1). The mechanisms by which processors provide access to the PSVI are neither defined nor constrained by this specification.||
Issue (RQ-142i): Issue 2846 (RQ-142 PSVI properties), Issue 2822 (RQ-144 required properties)Version 1.0 included several properties in the PSVI whose absence carried information (e.g. [type definition]), while at the same time not being completely clear about which PSVI properties, if any, were required. The Working Group intends to eliminate the former and clarify the latter.Resolution:
For 142, which mandates that insofar as possible absence of a property should not in general signify, when it does explicit 'if-and-only-if' language is required, the effect is distributed throughout the PSVI sub-sub-sections in section 3.
The Working Group appears to be close to consensus (although no final decision has been made) on views which can be summarized thus:
- We should eliminate any dependency on the absence of specific properties (i.e. important situations should be describable and distinguishable in terms of properties and their values, without appeal to the absence of particular properties), or if this proves unfeasible in particular cases we should say explicitly that a property is present "if and only if" certain conditions apply. Any remaining "if" (if any) would be a true conditional, not an equivalence.
- Any specification of a class of processors (including ours) can require specific additional information not in the PSVI, though should note that interoperability is better if applications depend only on the properties present in the PSVI as we define it.
- In our own specification of processor classes, we should be explicit that processors may provide additional information. (Or alternatively be explicit that they must not -- but the chair believes the WG consensus was to allow it.)
For 144, a few general remarks here about flexible-but-firm conformance are wanted here; most of the new work should end up in section 4 and/or 5.
Schema-validity assessment has two aspects:
Throughout this specification, [Definition:] the word valid and its derivatives are used to refer to clause 1 above, the determination of local schema-validity.
Throughout this specification, [Definition:] the word assessment is used to refer to the overall process of local validation, schema-validity assessment and infoset augmentation.
This specification builds on [XML 1.1] and [XML-Namespaces 1.1]. The concepts and definitions used herein regarding XML are framed at the abstract level of information items as defined in [XML-Infoset]. By definition, this use of the infoset provides a priori guarantees of well-formedness (as defined in [XML 1.1]) and namespace conformance (as defined in [XML-Namespaces 1.1]) for all candidates for ·assessment· and for all ·schema documents·.
Just as [XML 1.1] and [XML-Namespaces 1.1] can be described in terms of information items, XML Schemas can be described in terms of an abstract data model. In defining XML Schemas in terms of an abstract data model, this specification rigorously specifies the information which must be available to a conforming XML Schema processor. The abstract model for schemas is conceptual only, and does not mandate any particular implementation or representation of this information. To facilitate interoperation and sharing of schema information, a normative XML interchange format for schemas is provided.
[Definition:] Schema component is the generic term for the building blocks that comprise the abstract data model of the schema. [Definition:] An XML Schema is a set of ·schema components·. There are 13 kinds of component in all, falling into three groups. The primary components, which may (type definitions) or must (element and attribute declarations) have names, are as follows:
The secondary components, which must have names, are as follows:
Finally, the "helper" components provide small parts of other components; they are not independent of their context:
The name [Definition:] Component covers all the different kinds of component defined in this specification.
During ·validation·, [Definition:] declaration components are associated by (qualified) name to information items being ·validated·.
On the other hand, [Definition:] definition components define internal schema components that can be used in other schema components.
[Definition:] Declarations and definitions may and in some cases must have and be identified by names, which are NCNames as defined by [XML-Namespaces 1.1].
[Definition:] Several kinds of component have a target namespace, which is either ·absent· or a namespace name, also as defined by [XML-Namespaces 1.1]. The ·target namespace· serves to identify the namespace within which the association between the component and its name exists. In the case of declarations, this in turn determines the namespace name of, for example, the element information items it may ·validate·.
·Validation·, defined in detail in Schema Component Details (§3), is a relation between information items and schema components. For example, an attribute information item may ·validate· with respect to an attribute declaration, a list of element information items may ·validate· with respect to a content model, and so on. The following sections briefly introduce the kinds of components in the schema abstract data model, other major features of the abstract model, and how they contribute to ·validation·.
The abstract model provides two kinds of type definition component: simple and complex.
[Definition:] This specification uses the phrase type definition in cases where no distinction need be made between simple and complex types.
Type definitions form a hierarchy with a single root. The subsections below first describe characteristics of that hierarchy, then provide an introduction to simple and complex type definitions themselves.
[Definition:] Except for a distinguished ·ur-type definition·, every ·type definition· is, by construction, either a ·restriction· or an ·extension· of some other type definition. The graph of these relationships forms a tree known as the Type Definition Hierarchy.
[Definition:] The type definition used as the basis for an ·extension· or ·restriction· is known as the base type definition of that definition.
[Definition:] ||A type defined with the same constraints as its ·base type definition·, or with more, is said to be a restriction|| ||A type defined by appropriate use of facets or declarations so as to validate a subset of what another type definition validates, with consistent PSVI outcomes, is a restriction of the other type||. ||The added constraints might include narrowed ranges or reduced alternatives. Members of a type, A, whose definition is a ·restriction· of the definition of another type, B, are always members of type B as well.||
Issue (RQ-17i):Issue 2820 (RQ-17 simplify restriction rules)Version 1.0 made clear that the intention for derivation by restriction was that restrictions validated a subset of what their base validated. However, the constructive rules for what constituted valid content model restrictions for complex type definition not only failed to enforce this completely correctly, but also ruled out various cases which evidently should have been allowed. The Working Group has decided to shift to a much higher level statement of what constitutes a valid restriction, appealing directly to the subset requirement, in order to address these problems.Resolution:
A major change in definition/presentation, with only modest changes in consequences for schemas and validity, will be made, by defining restriction for complex type definitions in terms of the desired result, that is that all members of a restricted type are members of its base type. In the normative part of the spec. this will be done by appeal to local validity.
"Clarifying: R restricts B: any EII that is locally valid [per R] must also be locally valid [per B], with side conditions on properties on terms you appeal to [to] get same child allowed by two content models." [-F2F 2004-03-12, section Subsumption (W3C-member-only link)]
A non-normative appendix will provide references to published algorithms for enforcing the constraint.
[Definition:] A complex type definition which allows element or attribute content in addition to that allowed by another specified type definition is said to be an extension.
[Definition:] A distinguished complex type definition, the ur-type definition, whose name is ||anyType||||rootType|| in the XML Schema namespace, is present in each ·XML Schema·, serving as the root of the type definition hierarchy for that schema.
[Definition:] A further special complex type definition, whose name is anyType in the XML Schema namespace, is also present in each ·XML Schema·. The definition of anyType serves as default type definition for element declarations whose XML representation does not specify one.
A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the ·normalized value· of an attribute information item or of an element information item with no element children. Informally, it applies to the values of attributes and the text-only content of elements.
Each simple type definition, whether built-in (that is, defined in [XML Schema: Datatypes]) or user-defined, is a ·restriction· of its ·base type definition·. [Definition:] The simple ur-type definition, a special ·restriction· of the ·ur-type definition·, whose name is anySimpleType in the XML Schema namespace is the root of the ·Type Definition Hierarchy· for the simple type definitions. The ·simple ur-type definition· is considered to have an unconstrained lexical space, and a value space consisting of the union of the value spaces of all the built-in primitive datatypes and the set of all lists of all members of the value spaces of all the built-in primitive datatypes. The built-in list datatypes all have the ·simple ur-type definition· as their ·base type definition·.
[Definition:] There is a further special datatype called anyAtomicType, a ·restriction· of the ·simple ur-type definition·, which is the ·base type definition· of all the primitive built-in datatypes. It too is considered to have an unconstrained lexical space. Its value space consists of the union of the value spaces of all the built-in primitive datatypes.
The mapping from lexical space to value space is unspecified for items whose type definition is the ·simple ur-type definition·or ·anyAtomicType·. Accordingly this specification does not constrain processors' behaviour in areas where this mapping is implicated, for example checking such items against enumerations, constructing default attributes or elements whose declared type definition is the ·simple ur-type definition·, checking identity constraints involving such items.
[XML Schema: Datatypes] provides mechanisms for defining new simple type definitions by ·restricting· one of the built-in primitive or ordinary datatypes. It also provides mechanisms for constructing new simple type definitions whose members are lists of items themselves constrained by some other simple type definition, or whose membership is the union of the memberships of some other simple type definitions. Such list and union simple type definitions are also ·restrictions· of the ·simple ur-type definition·.
For detailed information on simple type definitions, see Simple Type Definitions (§3.14) and [XML Schema: Datatypes]. The latter also defines an extensive inventory of pre-defined simple types.
A complex type definition is a set of attribute declarations and a content type, applicable to the [attributes] and [children] of an element information item respectively. The content type may require the [children] to contain neither element nor character information items (that is, to be empty), or to be a string which belongs to a particular simple type, or to contain a sequence of element information items which conforms to a particular model group, with or without character information items as well.
Each complex type definition other than the ·ur-type definition· is either
or
A complex type which extends another does so by having additional content model particles at the end of the other definition's content model, or by having additional attribute declarations, or both.
For detailed information on complex type definitions, see Complex Type Definitions (§3.4).
There are three kinds of declaration component: element, attribute, and notation. Each is described in a section below. Also included is a discussion of element substitution groups, which is a feature provided in conjunction with element declarations.
An element declaration is an association of a name with a type definition, either simple or complex, an (optional) default value and a (possibly empty) set of identity-constraint definitions. The association is either global or scoped to a containing complex type definition. A top-level element declaration with name 'A' is broadly comparable to a pair of DTD declarations as follows, where the associated type definition fills in the ellipses:
<!ELEMENT A . . .> <!ATTLIST A . . .>
Element declarations contribute to ·validation· as part of model group ·validation·, when their defaults and type components are checked against an element information item with a matching name and namespace, and by triggering identity-constraint definition ·validation·.
For detailed information on element declarations, see Element Declarations (§3.3).
In XML, the name and content of an element must correspond exactly to the element type referenced in the corresponding content model.
[Definition:] Through the new mechanism of element substitution groups, XML Schemas provides a more powerful model supporting substitution of one named element for another. Any top-level element declaration can serve as the defining member, or head, for an element substitution group. Other top-level element declarations, regardless of target namespace, can be designated as members of the substitution group headed by this element. In a suitably enabled content model, a reference to the head ·validates· not just the head itself, but elements corresponding to any other member of the substitution group as well.
All such members must have type definitions which are either the same as the head's type definition or restrictions or extensions of it. Therefore, although the names of elements can vary widely as new namespaces and members of the substitution group are defined, the content of member elements is strictly limited according to the type definition of the substitution group head.
Note that element substitution groups are not represented as separate components. They are specified in the property values for element declarations (see Element Declarations (§3.3)).
An attribute declaration is an association between a name and a simple type definition, together with occurrence information and (optionally) a default value. The association is either global, or local to its containing complex type definition. Attribute declarations contribute to ·validation· as part of complex type definition ·validation·, when their occurrence, defaults and type components are checked against an attribute information item with a matching name and namespace.
For detailed information on attribute declarations, see Attribute Declarations (§3.2).
A notation declaration is an association between a name and an identifier for a
notation. For an attribute information item to be ·valid· with respect to a
NOTATION
simple type definition, its value must have been declared
with a notation declaration.
For detailed information on notation declarations, see Notation Declarations (§3.12).
The model group, particle, and wildcard components contribute to the portion of a complex type definition that controls an element information item's content.
A model group is a constraint in the form of a grammar fragment that applies to lists of element information items. It consists of a list of particles, i.e. element declarations, wildcards and model groups. There are three varieties of model group:
For detailed information on model groups, see Model Groups (§3.8).
A particle is a term in the grammar for element content, consisting of either an element declaration, a wildcard or a model group, together with occurrence constraints. Particles contribute to ·validation· as part of complex type definition ·validation·, when they allow anywhere from zero to many element information items or sequences thereof, depending on their contents and occurrence constraints.
The name [Definition:] Term is used to refer to any of the three kinds of components which can appear in particles. All ·Terms· are themselves ·Annotated Components·.
[Definition:] A particle can be used in a complex type definition to constrain the ·validation· of the [children] of an element information item; such a particle is called a content model.
For detailed information on particles, see Particles (§3.9).
An attribute use plays a role similar to that of a particle, but for attribute declarations: an attribute declaration within a complex type definition is embedded within an attribute use, which specifies whether the declaration requires or merely allows its attribute, and whether it has a default or fixed value.
A wildcard is a special kind of particle which matches element and attribute information items dependent on their namespace name, independently of their local names.
For detailed information on wildcards, see Wildcards (§3.10).
An identity-constraint definition is an association between a name and one of several varieties of identity-constraint related to uniqueness and reference. All the varieties use [XPath] expressions to pick out sets of information items relative to particular target element information items which are unique, or a key, or a ·valid· reference, within a specified scope. An element information item is only ·valid· with respect to an element declaration with identity-constraint definitions if those definitions are all satisfied for all the descendants of that element information item which they pick out.
For detailed information on identity-constraint definitions, see Identity-constraint Definitions (§3.11).
There are two kinds of convenience definitions provided to enable the re-use of pieces of complex type definitions: model group definitions and attribute group definitions.
A model group definition is an association between a name and a model group, enabling re-use of the same model group in several complex type definitions.
For detailed information on model group definitions, see Model Group Definitions (§3.7).
An attribute group definition is an association between a name and a set of attribute declarations, enabling re-use of the same set in several complex type definitions.
For detailed information on attribute group definitions, see Attribute Group Definitions (§3.6).
An annotation is information for human and/or mechanical consumers. The interpretation of such information is not defined in this specification.
For detailed information on annotations, see Annotations (§3.13).
The [XML 1.1] specification describes two kinds of constraints on XML documents: well-formedness and validity constraints. Informally, the well-formedness constraints are those imposed by the definition of XML itself (such as the rules for the use of the < and > characters and the rules for proper nesting of elements), while validity constraints are the further constraints on document structure provided by a particular DTD.
The preceding section focused on ·validation·, that is the constraints on information items which schema components supply. In fact however this specification provides four different kinds of normative statements about schema components, their representations in XML and their contribution to the ·validation· of information items:
The last of these, schema information set
contributions, are not as new as they might at first seem. XML
validation augments the XML information set in similar ways,
for example by
providing values for attributes not present in instances, and by implicitly
exploiting type information for normalization or access.
(As an example of the latter case, consider the
effect of NMTOKENS
on attribute white space, and the semantics of
ID
and IDREF
.) By including schema
information set contributions, this specification makes explicit some features
that XML leaves implicit.
This specification describes three levels of conformance for schema aware processors. The first is required of all processors. Support for the other two will depend on the application environments for which the processor is intended.
[Definition:] Minimally conforming processors must completely and correctly implement the ·Schema Component Constraints·, ·Validation Rules·, and ·Schema Information Set Contributions· contained in this specification.
[Definition:] ·Minimally conforming· processors which accept schemas represented in the form of XML documents as described in Layer 2: Schema Documents, Namespaces and Composition (§4.2) are additionally said to ||provide conformance to the XML Representation of Schemas||||be schema-document aware||. Such processors must, when processing schema documents, completely and correctly implement all ·Schema Representation Constraints· in this specification, and must adhere exactly to the specifications in Schema Component Details (§3) for mapping the contents of such documents to ·schema components· for use in ·validation· and ·assessment·.
[Definition:] A ·minimally conforming· processor which is not ·schema-document aware· is said to be a non-schema-document-aware processor.
[Definition:] ||Fully conforming||||Web-aware|| processors are network-enabled processors which are not only both ·minimally conforming· and ·||in conformance to the XML Representation of Schemas||||schema-document aware||·, but which additionally must be capable of accessing schema documents from the World Wide Web ||according to||||as described in|| Representation of Schemas on the World Wide Web (§2.7) and How schema definitions are located on the Web (§4.3.2). .
See Schemas and Namespaces: Access and Composition (§4) for a more detailed explanation of the mechanisms supporting these levels of conformance.
As discussed in XML Schema Abstract Data Model (§2.2), most schema components (may) have ·names·. If all such names were assigned from the same "pool", then it would be impossible to have, for example, a simple type definition and an element declaration both with the name "title" in a given ·target namespace·.
Therefore [Definition:] this specification introduces the term symbol space to denote a collection of names, each of which is unique with respect to the others. A symbol space is similar to the non-normative concept of namespace partition introduced in [XML-Namespaces 1.1]. There is a single distinct symbol space within a given ·target namespace· for each kind of definition and declaration component identified in XML Schema Abstract Data Model (§2.2), except that within a target namespace, simple type definitions and complex type definitions share a symbol space. Within a given symbol space, names are unique, but the same name may appear in more than one symbol space without conflict. For example, the same name can appear in both a type definition and an element declaration, without conflict or necessary relation between the two.
Locally scoped attribute and element declarations are special with regard to symbol spaces. Every complex type definition defines its own local attribute and element declaration symbol spaces, where these symbol spaces are distinct from each other and from any of the other symbol spaces. So, for example, two complex type definitions having the same target namespace can contain a local attribute declaration for the unqualified name "priority", or contain a local element declaration for the name "address", without conflict or necessary relation between the two.
The XML representation of schema components uses a vocabulary
identified by the namespace name http://www.w3.org/2001/XMLSchema
. For brevity, the text and examples in this specification use the prefix
xs:
to stand for this namespace; in practice,
any prefix can be used.
Issue (RQ-153i):Issue 3047 (RQ-153 XSD 1.1 namespace)This specification must choose either to use the same namespace as XML Schema 1.0, or to use a different namespace, or to use more than one namespace. An explicit decision should be made.
XML Schema: Structures also defines several attributes for direct use in any XML documents. These attributes are in a different namespace,
which has the namespace name http://www.w3.org/2001/XMLSchema-instance
.
For brevity, the text and examples in this specification use the prefix
xsi:
to stand for this latter namespace; in practice,
any prefix can be used. All schema processors have appropriate attribute
declarations for these attributes built in, see Attribute Declaration for the 'type' attribute (§3.2.7),
Attribute Declaration for the 'nil' attribute (§3.2.7), Attribute Declaration for the 'schemaLocation' attribute (§3.2.7) and Attribute Declaration for the 'noNamespaceSchemaLocation' attribute (§3.2.7).
The Simple Type Definition (§2.2.1.2) or Complex Type Definition (§2.2.1.3) used in ·validation· of an element is usually
determined by reference to the appropriate schema components.
An element information item in an instance may, however,
explicitly assert its type using the attribute xsi:type
.
The value of this attribute is a ·QName·; see QName Interpretation (§3.15.3) for
the means by which the ·QName· is
associated with a type definition.
XML Schema: Structures introduces a mechanism for signaling that an element
must be accepted as ·valid· when
it has no content despite a content type which does not require or
even necessarily allow empty content. An element may be
·valid· without
content if it has the attribute xsi:nil
with the value
true
. An element so labeled must be empty, but can
carry attributes if permitted by the corresponding complex type.
The xsi:schemaLocation
and xsi:noNamespaceSchemaLocation
attributes can be used in a document to provide
hints as to the physical location of schema documents which may
be used for ·assessment·.
See How schema definitions are located on the Web (§4.3.2) for details on the use of these attributes.
On the World Wide Web, schemas are conventionally represented as XML
documents (preferably of MIME type
application/xml
or text/xml
, but see clause 1.1 of Inclusion Constraints and Semantics (§4.2.1)), conforming to the specifications in Layer 2: Schema Documents, Namespaces and Composition (§4.2). For more information on
the representation and use of schema documents on the World Wide Web see Standards for representation of schemas and retrieval of schema documents on the Web (§4.3.1) and
How schema definitions are located on the Web (§4.3.2).
The following sections provide full details on the composition of all schema components, together with their XML representations and their contributions to ·assessment·. Each section is devoted to a single component, with separate subsections for
The sub-sections immediately below introduce conventions and terminology used throughout the component sections.
Components are defined in terms of their properties, and each property in turn is defined by giving its range, that is the values it may have. This can be understood as defining a schema as a labeled directed graph, where the root is a schema, every other vertex is a schema component or a literal (string, boolean, decimal) and every labeled edge is a property. The graph is not acyclic: multiple copies of components with the same name in the same ·symbol space· must not exist, so in some cases re-entrant chains of properties will exist. Equality of components for the purposes of this specification is always defined as equality of names (including target namespaces) within symbol spaces.
Issue (RQ-125i):Issue 2837 (RQ-125 identity of anonymous types), Issue 2842 (RQ-134 inherited portions of content model) Version 1.0 was deliberately reticent in stating identity conditions for components. With hindsight this was a mistake, and will be corrected.Resolution:
Add {scope} property to type definition components which will either be the enclosing element declaration or "global", by analogy with element declarations {scope}. [For further context, see F2F 2004-03-12, section RQ-125 (W3C-member-only link).]
This change will solve the anonymous type equality problem by giving an unequivocal answer to the "who am I?" question for such types by way of the answer "Your identity is determined by your scope's identity."
Component properties are simply named values. Most properties have either other components or literals (that is, strings or booleans or enumerated keywords) for values, but in a few cases, where more complex values are involved, [Definition:] a property value may itself be a collection of named values, which we call a property record.
[Definition:] Throughout this specification, the term absent is used as a distinguished property value denoting absence. Again this should not be interpreting as constraining implementations, as for instance between using a null value for such properties or not representing them at all.
Any property not identified as optional is ||required to be present||||defined as always present||; optional properties which are not present are taken to have ·absent· as their value. Any property identified as a having a set, subset or list value may have an empty value unless this is explicitly ruled out: this is not the same as ·absent·. Any property value identified as a superset or subset of some set may be equal to that set, unless a proper superset or subset is explicitly called for. By 'string' in Part 1 of this specification is meant a sequence of ISO 10646 characters identified as legal XML characters in [XML 1.1].
The principal purpose of XML Schema: Structures is to define a set of
schema components that constrain the contents of instances and augment the
information sets thereof. Although no external representation
of schemas is required for this purpose, such representations will
obviously be widely used. To provide for this in an appropriate and
interoperable way, this specification provides a normative XML representation for schemas which
makes provision for every kind of schema
component. [Definition:] A document in
this form (i.e. a <schema> element information item) is a schema document. For the schema document as a whole, and
its constituents, the sections below define correspondences between element
information items (with declarations in
Schema for Schema Documents (Structures) (normative) (§A) and DTD for Schemas (non-normative) (§K)) and
schema components. All the element information items in the XML representation
of a schema must be in the XML Schema namespace, that is their [namespace name] must be http://www.w3.org/2001/XMLSchema
. Although a common way of creating the XML Infosets which are or contain ·schema documents· will be using an XML parser, this is not required: any mechanism which constructs conformant infosets as defined in [XML-Infoset] is a possible starting point.
Two aspects of the XML representations of components presented in the following sections are constant across them all:
For each kind of schema component there is a corresponding normative XML representation. The sections below describe the correspondences between the properties of each kind of schema component on the one hand and the properties of information items in that XML representation on the other, together with constraints on that representation above and beyond those implicit in the Schema for Schema Documents (Structures) (normative) (§A).
The language used is as if the correspondences were mappings from XML representation to schema component, but the mapping in the other direction, and therefore the correspondence in the abstract, can always be constructed therefrom.
In discussing the mapping from XML representations to schema components below, the value of a component property is often determined by the value of an attribute information item, one of the [attributes] of an element information item. Since schema documents are constrained by the Schema for Schema Documents (Structures) (normative) (§A), there is always a simple type definition associated with any such attribute information item. [Definition:] The phrase actual value is used to refer to the member of the value space of the simple type definition associated with an attribute information item which corresponds to its ·normalized value·. This will often be a string, but may also be an integer, a boolean, a URI reference, etc. This term is also occasionally used with respect to element or attribute information items in a document being ·validated·.
Many properties are identified below as having other schema components or sets of components as values. For the purposes of exposition, the definitions in this section assume that (unless the property is explicitly identified as optional) all such values are in fact present. When schema components are constructed from XML representations involving reference by name to other components, this assumption may be violated if one or more references cannot be resolved. This specification addresses the matter of missing components in a uniform manner, described in Missing Sub-components (§5.3): no mention of handling missing components will be found in the individual component descriptions below.
Forward reference to named definitions and declarations is allowed, both within and between ·schema documents·. By the time the component corresponding to an XML representation which contains a forward reference is actually needed for ·validation· an appropriately-named component may have become available to discharge the reference: see Schemas and Namespaces: Access and Composition (§4) for details.
Throughout this specification, [Definition:] the initial value of some attribute information item is the value of the [normalized value] property of that item. Similarly, the initial value of an element information item is the string composed of, in order, the [character code] of each character information item in the [children] of that element information item.
The above definition means that comments and processing instructions, even in the midst of text, are ignored for all ·validation· purposes.
[Definition:] The normalized value of an element or attribute information item is an ·initial value· whose white space, if any, has been normalized according to the value of the whiteSpace facet of the simple type definition used in its ·validation·:
#x9
(tab), #xA
(line feed) and
#xD
(carriage return) are replaced with #x20
(space).#x20
s are collapsed to a single
#x20
, and initial and/or final #x20
s are deleted.
If the simple type definition used in an item's ·validation· is the ·simple ur-type definition·, then the ·normalized value· must be determined as in the preserve case above.
There are three alternative validation rules which may supply the necessary background for the above: Attribute Locally Valid (§3.2.4) (clause 3), Element Locally Valid (Type) (§3.3.4) (clause 3.1.3) or Element Locally Valid (Complex Type) (§3.4.4) (clause 2.2).
These three levels of normalization correspond to the processing mandated in XML for element content, CDATA attribute content and tokenized attributed content, respectively. See Attribute Value Normalization in [XML 1.1] for the precedent for replace and collapse for attributes. Extending this processing to element content is necessary to ensure a consistent ·validation· semantics for simple types, regardless of whether they are applied to attributes or elements. Performing it twice in the case of attributes whose [normalized value] has already been subject to replacement or collapse on the basis of information in a DTD is necessary to ensure consistent treatment of attributes regardless of the extent to which DTD-based information has been made use of during infoset construction.
Attribute declarations provide for:
<xs:attribute name="age" type="xs:positiveInteger" use="required"/>
The attribute declaration schema component has the following properties:
The {name} property must match the local part of the names of attributes being ·validated·.
The value of the attribute must conform to the supplied {type definition}.
A ·non-absent· value of the {target namespace} property provides for ·validation· of namespace-qualified attribute information items (which must be explicitly prefixed in the character-level form of XML documents). ·Absent· values of {target namespace} ·validate· unqualified (unprefixed) items.
A {scope} with {variety} global identifies attribute declarations available for use in complex type definitions throughout the schema. Locally scoped declarations are available for use only within the complex type definition identified by the {scope}'s {parent} property. This property is ·absent· in the case of declarations within attribute group definitions: their scope will be determined when they are used in the construction of complex type definitions.
{value constraint} reproduces the functions of XML default and #FIXED
attribute values. A {variety} of default specifies that the attribute is to appear unconditionally in
the ·post-schema-validation infoset·, with {value}
and {lexical form} used
whenever the attribute is not actually present; fixed indicates that the attribute value if present must be identical to {value}, and if absent receives {value}
and {lexical form} as for
default. Note that it is values that are
checked, not strings.
See Annotations (§3.13) for information on the role of the {annotations} property.
[XML-Infoset] distinguishes attributes with names such as xmlns
or xmlns:xsl
from
ordinary attributes, identifying them as [namespace attributes]. Accordingly, it is unnecessary and in fact not possible for
schemas to contain attribute declarations corresponding to such
namespace declarations, see xmlns
Not Allowed (§3.2.6). No means is provided in
this specification to supply a
default value for a namespace declaration.
Issue (RQ-121i):Issue 2835 (RQ-121 prohibited + fixed)Neither the prose of this specification nor the schema for schema documents rules out XML representations of attribute declarations containing bothuse='prohibited'
andfixed='...'
. It will be made clear that this is not an error and that ‘prohibited
’ wins.
The XML representation for an attribute declaration schema component is an <attribute> element information item. It specifies a simple type definition for an attribute either by reference or explicitly, and may provide default information. The correspondences between the properties of the information item and properties of the component are as follows:
attribute
Element Information Item<attribute
default = string
fixed = string
form = (qualified | unqualified)
id = ID
name = NCName
ref = QName
type = QName
use = (optional | prohibited | required) : optional
{any attributes with non-schema namespace . . .}>
Content: (annotation?, simpleType?)
</attribute>
targetNamespace
[attribute] of the parent <schema>
element information item, or ·absent· if there is none.type
[attribute], if present, otherwise the
·simple ur-type definition·.default
or a fixed
[attribute], then a Value Constraint as follows, otherwise ·absent·.
ref
[attribute] is absent, it corresponds to an
attribute use with properties as follows (unless use='prohibited'
, in which case the item
corresponds to nothing at all):default
or a fixed
[attribute], then a Value Constraint as follows, otherwise ·absent·.
form
is present and its
·actual value· is qualified
, or if form
is absent and the
·actual value· of attributeFormDefault
on the <schema>
ancestor is qualified
, then the ·actual value· of the
targetNamespace
[attribute] of the parent <schema>
element information item, or ·absent· if there
is none, otherwise ·absent·.type
[attribute], if present, otherwise the
·simple ur-type definition·.ref
[attribute] is present), it corresponds to an
attribute use with properties as follows (unless use='prohibited'
, in which case the item
corresponds to nothing at all):default
or a fixed
[attribute], then a Value Constraint as follows, otherwise ·absent·.
Attribute declarations can appear at the top level of a schema document, or within complex
type definitions, either as complete (local) declarations, or by reference to top-level
declarations, or within attribute group definitions. For complete declarations, top-level or local, the type
attribute is used when the declaration can use a
built-in or pre-declared simple type definition. Otherwise an
anonymous <simpleType> is provided inline.
The default when no simple type definition is referenced or provided is the ·simple ur-type definition·, which imposes no constraints at all.
Attribute information items ·validated· by
a top-level declaration must be qualified with the
{target namespace} of that declaration.
If the
{target namespace} is ·absent·,
the item must be unqualified.
Control over whether attribute information items
·validated· by a local
declaration must be similarly qualified or not
is provided by the form
[attribute], whose default is provided
by the attributeFormDefault
[attribute] on the
enclosing <schema>, via its determination of
{target namespace}.
The names for top-level attribute declarations are in their own ·symbol space·. The names of locally-scoped attribute declarations reside in symbol spaces local to the type definition which contains them.
default
and fixed
must not both be present.ref
or name
is present, but not both.Issue (RQ-143i):Issue 2827 (RQ-143 attribute assessment)An attribute with no type declaration cannot be 'assessed', as defined by (Schema-Validity Assessment (Attribute)), so it will never have any PSVI properties, whereas it would be natural for it to have [validation attempted] = none and [validity] = notKnown. This will be fixed.Resolution:
It is likely that the current backward-chaining approach to defining schema-validity assessment will be reworked, in which case this will get fixed as part of that.
All attribute declarations (see Attribute Declarations (§3.2)) must satisfy the following constraints.
xsi:
Not Allowedhttp://www.w3.org/2001/XMLSchema-instance
(unless it is one of the four built-in declarations given in the next section).xsi:type
or xsi:nil
, which would be
seriously misleading, as they would have no effect.There are four attribute declarations present in every schema by definition:
type
http://www.w3.org/2001/XMLSchema-instance
nil
http://www.w3.org/2001/XMLSchema-instance
schemaLocation
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2001/XMLSchema-instance
noNamespaceSchemaLocation
http://www.w3.org/2001/XMLSchema-instance
Element declarations provide for:
<xs:element name="PurchaseOrder" type="PurchaseOrderType"/> <xs:element name="gift"> <xs:complexType> <xs:sequence> <xs:element name="birthday" type="xs:date"/> <xs:element ref="PurchaseOrder"/> </xs:sequence> </xs:complexType> </xs:element>
The element declaration schema component has the following properties:
The {name} property must match the local part of the names of element information items being ·validated·.
A {scope} with {variety} global identifies element declarations available for use in content models throughout the schema. Locally scoped declarations are available for use only within the complex type identified by the {scope}'s {parent} property. This property is ·absent· in the case of declarations within named model groups: their scope will be determined when they are used in the construction of complex type definitions.
A ·non-absent· value of the {target namespace} property provides for ·validation· of namespace-qualified element information items. ·Absent· values of {target namespace} ·validate· unqualified items.
An element information item is ·valid· only if it satisfies the {type definition}. For such an item, schema information set contributions appropriate to the {type definition} are added to the corresponding element information item in the ·post-schema-validation infoset·.
If {nillable} is true, then an
element can also be ·valid· if it carries the namespace qualified
attribute with [local
name] nil
from namespace
http://www.w3.org/2001/XMLSchema-instance
and value true
(see
xsi:nil (§2.6.2)) even if it has no text or element content
despite a {content type} which would otherwise
require content. Formal details of
element ·validation· are described in
Element Locally Valid (Element) (§3.3.4).
{value constraint} establishes a default or fixed value for an element. If a {value constraint} with a {variety} of default is present, and if the element being ·validated· is empty, then the {value constraint}'s {lexical form} becomes the [schema normalized value] of the ·validated· element in the ·post-schema-validation infoset·. If fixed is specified, then the element's content must either be empty, in which case fixed behaves as default, or its value must be intentical to the {value constraint}'s {value}.
{identity-constraint definitions} express constraints establishing uniquenesses and reference relationships among the values of related elements and attributes. See Identity-constraint Definitions (§3.11).
Element declarations are potential members of the substitution group, if any, identified by {substitution group affiliation}. Potential membership is transitive but not symmetric; an element declaration is a potential member of any group of which its {substitution group affiliation} is a potential member. Actual membership may be blocked by the effects of {substitution group exclusions} or {disallowed substitutions}, see below.
An empty {substitution group exclusions} allows a declaration to be nominated as the {substitution group affiliation} of other element declarations having the same {type definition} or types derived therefrom. The explicit values of {substitution group exclusions} rule out element declarations having types which are extensions or restrictions respectively of {type definition}. If both values are specified, then the declaration must not be nominated as the {substitution group affiliation} of any other declaration.
The supplied values for {disallowed substitutions} determine whether an element declaration appearing in a ·content model· will be prevented from additionally ·validating· elements (a) with an xsi:type (§2.6.1) that identifies an extension or restriction of the type of the declared element, and/or (b) from ·validating· elements which are in the substitution group headed by the declared element. If {disallowed substitutions} is empty, then all derived types and substitution group members are allowed.
Element declarations for which {abstract} is true can appear in content models only when substitution is allowed; such declarations must not themselves ever be used to ·validate· element content.
See Annotations (§3.13) for information on the role of the {annotations} property.
The XML representation for an element declaration schema component is an <element> element information item. It specifies a type definition for an element either by reference or explicitly, and may provide occurrence and default information. The correspondences between the properties of the information item and properties of the component(s) it corresponds to are as follows:
element
Element Information Item<element
abstract = boolean : false
block =
(#all | List of (extension | restriction | substitution))
default = string
final =
(#all | List of (extension | restriction))
fixed = string
form = (qualified | unqualified)
id = ID
maxOccurs =
(nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
name = NCName
nillable = boolean : false
ref = QName
substitutionGroup = QName
type = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation?, ((simpleType | complexType)?, (unique | key | keyref)*))
</element>
targetNamespace
[attribute] of the parent <schema> element information item, or ·absent· if there is none.type
[attribute], otherwise the
{type definition} of the element declaration
·resolved· to by the ·actual value· of
the substitutionGroup
[attribute], if present,
otherwise the ||·ur-type definition·||||·definition of anyType·||.default
or a fixed
[attribute], then
a Value Constraint as follows,
otherwise ·absent·. [Definition:] Use the name effective simple type
definition for the {type definition},
if it is a simple type definition, or, if the {type definition}'s {content type} has
{variety} simple, that {content type}'s {simple type definition}, or else the built-in string simple type
definition).
substitutionGroup
[attribute], if present, otherwise ·absent·.block
[attribute], if present, otherwise on the ·actual value· of the
blockDefault
[attribute] of the ancestor <schema> element
information item, if present, otherwise on the empty string. Call this the EBV (for effective block value). Then the value of this property is
the appropriate case among the following:#all
, then {
extension, restriction, substitution}
;blockDefault
[attribute] of
<schema> may include values other than
extension, restriction or substitution,
those values are ignored in the determination of {disallowed substitutions} for element declarations (they
are used elsewhere).final
and finalDefault
[attributes] in place of the
block
and blockDefault
[attributes] and with the
relevant set being {
extension, restriction}
.ref
[attribute] is absent, the corresponding schema components
are as follows (unless minOccurs=maxOccurs=0
, in which case the item
corresponds to no component at all):maxOccurs
[attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs
[attribute], if present, otherwise 1
.form
is present and its
·actual value· is qualified
, or if form
is absent and the
·actual value· of elementFormDefault
on the <schema>
ancestor is qualified
, then the ·actual value· of the
targetNamespace
[attribute] of the parent <schema>
element information item, or ·absent· if there
is none, otherwise ·absent·.ref
[attribute] is present), the corresponding schema component is as
follows (unless minOccurs=maxOccurs=0
, in which case the item
corresponds to no component at all):maxOccurs
[attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs
[attribute], if present, otherwise 1
.<element> corresponds to an element declaration, and allows the type definition of that declaration to be specified either by reference or by explicit inclusion.
<element>s within <schema> produce
global element declarations; <element>s within <group> or <complexType> produce either particles which contain global element declarations (if there's a ref
attribute) or local declarations (otherwise). For complete declarations, top-level or local, the type
attribute is used when the declaration can use a
built-in or pre-declared type definition. Otherwise an
anonymous <simpleType> or <complexType> is provided inline.
Element information items ·validated· by a top-level
declaration must be qualified with the
{target namespace} of that
declaration.
If the
{target namespace} is ·absent·,
the item must be unqualified.
Control over whether element information items ·validated· by a local declaration must be similarly qualified or not
is provided by the form
[attribute], whose default is provided
by the elementFormDefault
[attribute] on the enclosing <schema>, via its determination of {target namespace}.
As noted above the names for top-level element declarations are in a separate ·symbol space· from the symbol spaces for the names of type definitions, so there can (but need not be) a simple or complex type definition with the same name as a top-level element. As with attribute names, the names of locally-scoped element declarations with no {target namespace} reside in symbol spaces local to the type definition which contains them.
Note that the above allows for two levels of defaulting for unspecified
type definitions. An <element> with no referenced or included type definition will
correspond to an element declaration which has the same type definition as the
head of its substitution group if it identifies one, otherwise the ||·ur-type definition·||||·definition of anyType·||. This has the important consequence that the minimum valid element declaration, that is, one with only a name
attribute and no contents, is also (nearly) the most general, validating any combination of text and element content and allowing any attributes, and providing for recursive validation where possible.
See below at XML Representation of Identity-constraint Definition Schema Components (§3.11.2) for <key>, <unique> and <keyref>.
<xs:element name="unconstrained"/> <xs:element name="emptyElt"> <xs:complexType> <xs:attribute ...>. . .</xs:attribute> </xs:complexType> </xs:element> <xs:element name="contextOne"> <xs:complexType> <xs:sequence> <xs:element name="myLocalElement" type="myFirstType"/> <xs:element ref="globalElement"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="contextTwo"> <xs:complexType> <xs:sequence> <xs:element name="myLocalElement" type="mySecondType"/> <xs:element ref="globalElement"/> </xs:sequence> </xs:complexType> </xs:element>
myLocalElement
within
contextOne
will be constrained by myFirstType
,
while those within contextTwo
will be constrained by
mySecondType
. <xs:complexType name="facet"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="value" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="facet" type="xs:facet" abstract="true"/> <xs:element name="encoding" substitutionGroup="xs:facet"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:facet"> <xs:sequence> <xs:element ref="annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="value" type="xs:encodings"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="period" substitutionGroup="xs:facet"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:facet"> <xs:sequence> <xs:element ref="annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="value" type="xs:duration"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <xs:complexType name="datatype"> <xs:sequence> <xs:element ref="facet" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="optional"/> . . . </xs:complexType>
facet
type is defined
and the facet
element is declared to use it. The facet
element is abstract -- it's
only defined to stand as the head for a substitution group. Two further
elements are declared, each a member of the facet
substitution group. Finally a type is defined which refers to facet
, thereby
allowing either period
or encoding
(or
any other member of the group).default
and fixed
are not
both present.ref
or name
is present, but not both.ref
is present, then all of <complexType>,
<simpleType>, <key>, <keyref>,
<unique>, nillable
, default
,
fixed
, form
, block
and type
are absent,
i.e. only minOccurs
, maxOccurs
, id
and <annotation> are
allowed to appear together with
ref
.http://www.w3.org/2001/XMLSchema-instance
and whose [local
name] is nil
.false
.true
, and
all of the following are true:http://www.w3.org/2001/XMLSchema-instance
and whose [local
name] is type
, then
all of the following are true:Editorial Note: Most of the above change is actually nothing to do with rq129, but is a fix for a long-standing bug, which called for the comparison of a value and a lexical form. Need to check if we decided on identical or equal.
http://www.w3.org/2001/XMLSchema-instance
and whose [local name] is one of type
, nil
, schemaLocation
or noNamespaceSchemaLocation
.ID/IDREF
functionality is imperfect in that if the ·validation
root· is not the document element of an XML document, the results will
not necessarily be the same as those a validating parser would give were the
document to have a DTD with equivalent declarations.http://www.w3.org/2001/XMLSchema-instance
and whose [local name] is type
.xsi:type
[attribute] is involved, however, clause 1.2
takes precedence,
as is made clear in Element Locally Valid (Element) (§3.3.4).All element declarations (see Element Declarations (§3.3)) must satisfy the following constraint.
The following constraints define relations appealed to elsewhere in this specification.
Complex Type Definitions provide for:
Issue (RQ-36i): Issue 2857 (RQ-7 wildcards), Issue 2860 (RQ-36 local references), Issue 2544 (RQ-146 element declarations consistent)Although extremely useful, wildcards have proved to interact in unfortunate ways with the Unique Particle Attribution and Element Declarations Consistent constraints, and this has limited their utility, particularly for use in allowing for extension and anticipating subsequent versions. The interpretation of wildcards will be changed to address these problems, without compromising backward compatibility.
<xs:complexType name="PurchaseOrderType"> <xs:sequence> <xs:element name="shipTo" type="USAddress"/> <xs:element name="billTo" type="USAddress"/> <xs:element ref="comment" minOccurs="0"/> <xs:element name="items" type="Items"/> </xs:sequence> <xs:attribute name="orderDate" type="xs:date"/> </xs:complexType>
A complex type definition schema component has the following properties:
Either an Element Declaration or a Complex Type Definition.
Issue (RQ-131i): Issue 2841 (RQ-131 ordering of annotations), Issue 2840 (RQ-130 lost annotations), Issue 2851 (RQ-19 annotations in PSVI)Version 1.0 was inconsistent in providing for multiple sources of annotation, particularly where components corresponded to multiple nested elements in schema documents (e.g. Complex Type Definitions vis a visxs:complexType
,xs:complexContent
andxs:restriction
). This will change so that all components can have multiple annotations, and annotations will be handled consistently across all kinds of components.Also applies anywhere else {annotations} plural appears — everywhere, in fact.Resolution:
- All components have an {annotations} property;
- It contains a sequence of annotations;
- Namely all annotations "scoped" by this component, but not "scoped" by any other component "further down".
- The order of annotations within {annotations} is implementation-determined.
Note that when point 3 above mentions "annotations 'scoped' by . . ." this means <annotation> elements and out-of-band attributes.
[Agendum 4.1 SCD-related requirements (W3C-member-only link)]
Complex type definitions are identified by their {name} and {target namespace}. Except
for anonymous complex type definitions (those with no {name}), since
type definitions (i.e. both simple and complex type definitions taken together) must be uniquely identified within an ·XML
Schema·, no complex type definition can have the same name as another
simple or complex type definition. Complex type {name}s and {target namespace}s
are provided for reference from
instances (see xsi:type (§2.6.1)), and for use in the XML
representation of schema components
(specifically in <element>). See References to schema components across namespaces (<import>
) (§4.2.3) for the use of component
identifiers when importing one schema into another.
As described in Type Definition Hierarchy (§2.2.1.1), each complex type is derived from a {base type definition} which is itself either a Simple Type Definition (§2.2.1.2) or a Complex Type Definition (§2.2.1.3). {derivation method} specifies the means of derivation as either extension or restriction (see Type Definition Hierarchy (§2.2.1.1)).
A complex type with an empty specification for {final} can be used as a
{base type definition} for other types derived by either of
extension or restriction; the explicit values extension, and restriction prevent further
derivations by extension and restriction respectively. If all values are specified, then [Definition:] the complex type is said to be
final, because no
further derivations are possible. Finality is not
inherited, that is, a type definition derived by restriction from a type
definition which is final for extension is not itself, in the absence of any
explicit final
attribute of its own, final for anything.
The {context} property is only relevant for anonymous type definitions, for which its value is the component in which this type definition appears as the value of a property, e.g. {type definition}.
Complex types for which {abstract} is true must not be used as the {type definition} for the ·validation· of element information items. It follows that they must not be referenced from an xsi:type (§2.6.1) attribute in an instance document. Abstract complex types can be used as {base type definition}s, or even as the {type definition}s of element declarations, provided in every case a concrete derived type definition is used for ·validation·, either via xsi:type (§2.6.1) or the operation of a substitution group.
{attribute uses} are a set of attribute uses. See Element Locally Valid (Complex Type) (§3.4.4) and Attribute Locally Valid (§3.2.4) for details of attribute ·validation·.
{attribute wildcard}s provide a more flexible specification for ·validation· of attributes not explicitly included in {attribute uses}. Informally, the specific values of {attribute wildcard} are interpreted as follows:
See Element Locally Valid (Complex Type) (§3.4.4) and Wildcard allows Namespace Name (§3.10.4) for formal details of attribute wildcard ·validation·.
{content type} determines the ·validation· of [children] of element information items. Informally:
{prohibited substitutions} determine whether an element declaration appearing in a · content model· is prevented from additionally ·validating· element items with an xsi:type (§2.6.1) attribute that identifies a complex type definition derived by extension or restriction from this definition, or element items in a substitution group whose type definition is similarly derived: If {prohibited substitutions} is empty, then all such substitutions are allowed, otherwise, the derivation method(s) it names are disallowed.
See Annotations (§3.13) for information on the role of the {annotations} property.
The XML representation for a complex type definition schema component is a <complexType> element information item.
The XML representation for complex type definitions with a {content type}with {variety} simple is significantly different from that of those with other {content type}s, and this is reflected in the presentation below, which displays first the elements involved in the first case, then those for the second. The property mapping is shown once for each case.
complexType
Element Information Item<complexType
abstract = boolean : false
block =
(#all | List of (extension | restriction))
final =
(#all | List of (extension | restriction))
id = ID
mixed = boolean : false
name = NCName
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (simpleContent | complexContent | ((group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?))))
</complexType>
targetNamespace
[attribute] of the <schema> ancestor
element information item if present, otherwise ·absent·.block
[attribute], if present, otherwise on the ·actual value· of the
blockDefault
[attribute] of the ancestor <schema> element
information item, if present, otherwise on the empty string. Call this the EBV (for effective block value). Then the value of this property is
the appropriate case among the following:#all
, then {
extension, restriction}
;blockDefault
[attribute] of <schema> may include values other than restriction orextension, those values are ignored in the determination of {prohibited substitutions} for complex type definitions (they are used elsewhere).final
and finalDefault
[attributes] in place of the
block
and blockDefault
[attributes].name
[attribute] is present, then ·absent·,
otherwise (the parent element information item will be <element>), the Element Declaration corresponding to that parent information item.<simpleContent
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (restriction | extension))
</simpleContent>
<restriction
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | maxScale | minScale | length | minLength | maxLength | enumeration | whiteSpace | pattern)*)?, ((attribute | attributeGroup)*, anyAttribute?))
</restriction>
<extension
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, ((attribute | attributeGroup)*, anyAttribute?))
</extension>
<attributeGroup
id = ID
ref = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</attributeGroup>
<anyAttribute
id = ID
namespace =
((##any | ##other) | List of
(anyURI | (##targetNamespace | ##local))
)
: ##any
processContents = (lax | skip | strict) : strict
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</anyAttribute>
ref
[attribute] of the <attributeGroup> [children], if any.base
[attribute] is a complex type definition, the
{attribute uses} of that type definition, unless
the <restriction> alternative is chosen, in which case some members of
that type definition's {attribute uses}
must not
be
included, namely those whose
{attribute declaration}'s
{name} and {target namespace} are the same as
one of the following:use
[attribute] of the relevant <attribute> among the
[children] of <restriction> being prohibited.namespace
and
processContents
[attributes] and the <annotation> [children], exactly as for the wildcard
corresponding to an <any> element as set out in XML Representation of Wildcard Schema Components (§3.10.2);base
[attribute] is a complex type definition
with an {attribute wildcard}, then that {attribute wildcard}.base
[attribute] is a complex type definition whose own {content type} has {variety} simple and the <restriction> alternative is chosen, then starting from either
base
[attribute]base
[attribute] is a complex type definition
whose own {content type} has {variety}
mixed and {particle} a Particle which
is ·emptiable·, as defined in Particle Emptiable (§3.9.6) and the <restriction> alternative is chosen, then starting from
the simple type definition corresponding to the <simpleType> among
the [children] of <restriction> (which
must be present)
a simple type definition which restricts that simple type definition with a
set of facet components corresponding to the appropriate element information
items among the <restriction>'s
[children] (i.e. those which specify facets, if any), as
defined in Simple Type Restriction (Facets) (§3.14.6);
base
[attribute] is a complex type definition
(whose own {content type} must have {variety} simple, see below) and the <extension> alternative is chosen, then
the {simple type definition} of the {content type} of that complex type definition;base
[attribute] is a simple type definition and
the <extension> alternative is chosen), then
that simple type definition.<complexContent
id = ID
mixed = boolean
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (restriction | extension))
</complexContent>
<restriction
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?))
</restriction>
<extension
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, ((group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?)))
</extension>
ref
[attribute] of the <attributeGroup> [children], if any.base
[attribute], unless
the <restriction> alternative
is chosen, in which case some members of
that type definition's {attribute uses} must not be
included, namely those whose
{attribute declaration}'s
{name} and {target namespace} are the same as
one of the following:use
[attribute] of the relevant <attribute> among the
[children] of <restriction> being prohibited.false
.minOccurs
[attribute] has the ·actual value· 0
;true
, then A particle whose properties are as follows:
true
, otherwise elementOnlybase
[attribute]base
[attribute] has a {content type} with {variety} empty, then a Content Type as per clause 3.1.2 above;true
, otherwise elementOnlybase
[attribute] followed by the
·effective content·.use
attribute of an <attribute> is in establishing
the correspondence between a complex type defined by restriction and its XML
representation. It serves to prevent
inheritance of an identically named attribute use from the {base type definition}. Such an <attribute> does not correspond to any component, and hence there is no interaction with either explicit or inherited wildcards in the operation of Complex Type Definition Validation Rules (§3.4.4) or Constraints on Complex Type Definition Schema Components (§3.4.6).Careful consideration of the above concrete syntax reveals that
a type definition need consist of no more than a name, i.e. that
<complexType name="anyThing"/>
is allowed.
<xs:complexType name="length1"> <xs:simpleContent> <xs:extension base="xs:nonNegativeInteger"> <xs:attribute name="unit" type="xs:NMTOKEN"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:element name="width" type="length1"/> <width unit="cm">25</width> <xs:complexType name="length2"> <xs:complexContent> <xs:restriction base=" ||xs:anyType|| ||xs:rootType|| "> <xs:sequence> <xs:element name="size" type="xs:nonNegativeInteger"/> <xs:element name="unit" type="xs:NMTOKEN"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="depth" type="length2"/> <depth> <size>25</size><unit>cm</unit> </depth> <xs:complexType name="length3"> <xs:sequence> <xs:element name="size" type="xs:nonNegativeInteger"/> <xs:element name="unit" type="xs:NMTOKEN"/> </xs:sequence> </xs:complexType>
length3
is the abbreviated alternative to
length2
: they correspond to identical type definition components.
<xs:complexType name="personName"> <xs:sequence> <xs:element name="title" minOccurs="0"/> <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="surname"/> </xs:sequence> </xs:complexType> <xs:complexType name="extendedName"> <xs:complexContent> <xs:extension base="personName"> <xs:sequence> <xs:element name="generation" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="addressee" type="extendedName"/> <addressee> <forename>Albert</forename> <forename>Arnold</forename> <surname>Gore</surname> <generation>Jr</generation> </addressee>
<xs:complexType name="simpleName"> <xs:complexContent> <xs:restriction base="personName"> <xs:sequence> <xs:element name="forename" minOccurs="1" maxOccurs="1"/> <xs:element name="surname"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="who" type="simpleName"/> <who> <forename>Bill</forename> <surname>Clinton</surname> </who>
<xs:complexType name="paraType" mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="emph"/> <xs:element ref="strong"/> </xs:choice> <xs:attribute name="version" type="xs:decimal"/> </xs:complexType>
mixed
attribute appearing on complexType
itself.base
[attribute] must be a complex type definition;base
[attribute] is
one of the following:<xs:complexType . . .mixed='true'
when the <simpleContent> alternative is chosen has no effect on the corresponding component, and should be avoided. This may be ruled out in a subsequent version of this specification.http://www.w3.org/2001/XMLSchema-instance
and whose [local name] is one of type
, nil
, schemaLocation
or noNamespaceSchemaLocation
,
the appropriate case among the following is true:Issue (RQ-22i):Issue 2852 (RQ-22 add normalized default)Constructed default attribute information items in the PSVI did not have a [normalized value] property, only a [schema normalized value], making them incompatible with ordinary attribute infoitems. On balance, it seems sensible to correct this.Resolution:
Add a [normalized value] property to the constructed attribute infoitem which arises when a default value is applied.
All complex type definitions (see Complex Type Definitions (§3.4)) must satisfy the following constraints.
[Definition:] A complex type T is a valid extension of its {base type definition} if and only if T has a {derivation method} of extension and satisfies the constraint Derivation Valid (Extension) (§3.4.6).
However no definition of membership in a type was provided, and this statement accordingly lacked force. We can now restate the intended sense of 'restriction' as follows:"Members of a type, A, whose definition is a restriction of the definition of another type, B, are always members of type B as well."
A type definition R is a valid ·restriction· of another type definition B if and only if:
[Definition:] An attribute or element information item I is abstractly valid with respect to a simple or complex type definition D if and only if schema-validity assessment of I with respect to D (as defined by Schema-Validity Assessment (Element) (§3.3.4) or Schema-Validity Assessment (Attribute) (§3.2.4)) either results in a [validity] property of valid, or would result in [validity] of valid if constraints on the abstractness of type definitions and element declarations were ignored.
In practice, it is difficult to enforce the definition above directly as a Constraint on Components, owing to a number of corner cases which are difficult to detect or describe concisely. The following constraint is the operationally normative statement.
The following constraint defines a relation appealed to elsewhere in this specification.
xsi:type
or
substitution groups), that the type used is actually derived from the expected
type, and that that derivation does not involve a form of derivation which was
ruled out by the expected type.Note:
The wording of clause 2.1 above appeals to a notion of component identity which is only incompletely defined by this version of this specification. In some cases, the wording of this specification does make clear the rules for component identity. These cases include:There is a Complex Type Definition corresponding to the root of the type hierarchy present in every schema by definition:
The outer particle of rootType contains a simple sequence:
The inner particle of rootType contains a skip wildcard:
The mixed
content specification together with the
skip wildcard and attribute specification produce the defining
property for the root of the type hierarchy, namely that every type
definition is (eventually) a restriction
of it: its permissions and requirements are
the least restrictive possible.
There is ||also ||a complex type definition ||nearly equivalent to the ·ur-type definition·||||for ·anyType·|| present in every schema by definition. It has the following properties:
The outer particle of ·anyType· contains a sequence with a single term:
The inner particle of ·anyType· contains a wildcard which matches any element:
rational
) and utility (e.g. array
) type definitions.
In particular, there is a text
type definition which is recommended for use
as the type definition in element declarations intended for general text
content, as it makes sensible provision for various aspects of
internationalization. For more details, see the schema document for the type
library at its namespace name: http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd.An attribute use is a utility component which controls the occurrence and defaulting behavior of attribute declarations. It plays the same role for attribute declarations in complex types that particles play for element declarations.
<xs:complexType> . . . <xs:attribute ref="xml:lang" use="required"/> <xs:attribute ref="xml:space" default="preserve"/> <xs:attribute name="version" type="xs:decimal" fixed="1.0"/> </xs:complexType>
The attribute use schema component has the following properties:
{required} determines whether this use of an attribute declaration requires an appropriate attribute information item to be present, or merely allows it.
{attribute declaration} provides the attribute declaration itself, which will in turn determine the simple type definition used.
{value constraint} allows for local specification of a default or fixed value. This must be consistent with that of the {attribute declaration}, in that if the {attribute declaration} specifies a fixed value, the only allowed {value constraint} is the same fixed value.
Attribute uses correspond to all uses of <attribute> which
allow a use
attribute. These in turn correspond to
two components in each case, an attribute use and its {attribute declaration} (although note the latter is not new when the attribute use is a reference to a top-level attribute declaration). The appropriate mapping is described in XML Representation of Attribute Declaration Schema
Components (§3.2.2).
All attribute uses (see AttributeUses (§3.5)) must satisfy the following constraints.
A schema can name a group of attribute declarations so that they may be incorporated as a group into complex type definitions.
Attribute group definitions do not participate in ·validation· as such, but the {attribute uses} and {attribute wildcard} of one or more complex type definitions may be constructed in whole or part by reference to an attribute group. Thus, attribute group definitions provide a replacement for some uses of XML's parameter entity facility. Attribute group definitions are provided primarily for reference from the XML representation of schema components (see <complexType> and <attributeGroup>).
<xs:attributeGroup name="myAttrGroup"> <xs:attribute . . ./> . . . </xs:attributeGroup> <xs:complexType name="myelement"> . . . <xs:attributeGroup ref="myAttrGroup"/> </xs:complexType>
The attribute group definition schema component has the following properties:
Attribute groups are identified by their {name} and {target namespace}; attribute group identities must be unique within an ·XML Schema·. See References to schema components across namespaces (<import>
) (§4.2.3) for the use of component
identifiers when importing one schema into another.
{attribute uses} is a set attribute uses, allowing for local specification of occurrence and default or fixed values.
{attribute wildcard} provides for an attribute wildcard to be included in an attribute group. See above under Complex Type Definitions (§3.4) for the interpretation of attribute wildcards during ·validation·.
See Annotations (§3.13) for information on the role of the {annotations} property.
The XML representation for an attribute group definition schema component is an <attributeGroup> element information item. It provides for naming a group of attribute declarations and an attribute wildcard for use by reference in the XML representation of complex type definitions and other attribute group definitions. The correspondences between the properties of the information item and properties of the component it corresponds to are as follows:
attributeGroup
Element Information Item<attributeGroup
id = ID
name = NCName
ref = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation?, ((attribute | attributeGroup)*, anyAttribute?))
</attributeGroup>
targetNamespace
[attribute] of the parent schema
element information item.ref
[attribute] of the <attributeGroup> [children], if any.The example above illustrates a pattern which
recurs in the XML representation of schemas: The same element, in this case attributeGroup
, serves both to
define and to incorporate by reference. In the first case the
name
attribute is required, in the second the ref
attribute is required, and the element must be empty. These two are mutually exclusive, and also conditioned
by context: the defining form, with a name
, must occur at the top
level of a schema, whereas the referring form, with a ref
, must
occur within a complex type definition or an attribute group definition.
ref
[attribute] which resolves to the component corresponding to this
<attributeGroup>. Indirect circularity is also ruled
out. That is, when QName resolution (Schema Document) (§3.15.3) is applied to a
·QName· arising from any <attributeGroup>s with a ref
[attribute] among the [children], it must not be the case that a
·QName· is encountered at any depth
which resolves to the component corresponding to this <attributeGroup>.All attribute group definitions (see Attribute Group Definitions (§3.6)) must satisfy the following constraint.
A model group definition associates a name and optional annotations with a Model Group. By reference to the name, the entire model group can be incorporated by reference into a {term}.
Model group definitions are provided primarily for reference from the XML Representation of Complex Type Definitions (§3.4.2) (see <complexType> and <group>). Thus, model group definitions provide a replacement for some uses of XML's parameter entity facility.
<xs:group name="myModelGroup"> <xs:sequence> <xs:element ref="someThing"/> . . . </xs:sequence> </xs:group> <xs:complexType name="trivial"> <xs:group ref="myModelGroup"/> <xs:attribute .../> </xs:complexType> <xs:complexType name="moreSo"> <xs:choice> <xs:element ref="anotherThing"/> <xs:group ref="myModelGroup"/> </xs:choice> <xs:attribute .../> </xs:complexType>
The model group definition schema component has the following properties:
Model group definitions are identified by their {name} and {target namespace}; model group identities must be unique within an ·XML Schema·. See References to schema components across namespaces (<import>
) (§4.2.3) for the use of component
identifiers when importing one schema into another.
Model group definitions per se do not participate in ·validation·, but the {term} of a particle may correspond in whole or in part to a model group from a model group definition.
{model group} is the Model Group for which the model group definition provides a name.
See Annotations (§3.13) for information on the role of the {annotations} property.
The XML representation for a model group definition schema component is a <group> element information item. It provides for naming a model group for use by reference in the XML representation of complex type definitions and model groups. The correspondences between the properties of the information item and properties of the component it corresponds to are as follows:
group
Element Information Item<group
id = ID
maxOccurs =
(nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
name = NCName
ref = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (all | choice | sequence)?)
</group>
name
[attribute] (in which case the
item will have <schema> or <redefine> as parent), then the item corresponds to
a model group definition component with properties as follows:targetNamespace
[attribute] of the parent schema
element information item.ref
[attribute],
in which case it corresponds to a particle component with properties as follows (unless minOccurs=maxOccurs=0
, in which case the item
corresponds to no component at all):maxOccurs
[attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs
[attribute], if present, otherwise 1
.ref
[attribute]The name of this section is slightly misleading, in that the second, un-named,
case above (with a
ref
and no name
) is not really a named model
group at all, but a reference to one. Also note that in the first (named)
case above no reference is made to minOccurs
or
maxOccurs
: this is because the schema for schemas does not allow
them on the child of <group> when it is named. This in turn is
because the {min occurs} and {max occurs} of
the particles which refer to the definition are what count.
Given the constraints on its appearance in content models, an <all> must only occur as the only item in the [children] of a named model group definition or a content model: see Constraints on Model Group Schema Components (§3.8.6).
All model group definitions (see Model Group Definitions (§3.7)) must satisfy the following constraint.
When the [children] of element information items are not constrained to be empty or by reference to a simple type definition (Simple Type Definitions (§3.14)), the sequence of element information item [children] content may be specified in more detail with a model group. Because the {term} property of a particle can be a model group, and model groups contain particles, model groups can indirectly contain other model groups; the grammar for content models is therefore recursive.
<xs:all> <xs:element ref="cats"/> <xs:element ref="dogs"/> </xs:all> <xs:sequence> <xs:choice> <xs:element ref="left"/> <xs:element ref="right"/> </xs:choice> <xs:element ref="landmark"/> </xs:sequence>
The model group schema component has the following properties:
specifies a sequential (sequence), disjunctive (choice) or conjunctive (all) interpretation of the {particles}. This in turn determines whether the element information item [children] ·validated· by the model group must:
=0
or
1
, {max occurs}=1
.When two or more particles contained directly or indirectly in the {particles} of a model group have identically named element declarations as their {term}, the type definitions of those declarations must be the same. By 'indirectly' is meant particles within the {particles} of a group which is itself the {term} of a directly contained particle, and so on recursively.
See Annotations (§3.13) for information on the role of the {annotations} property.
The XML representation for a model group schema component is either an <all>, a <choice> or a <sequence> element information item. The correspondences between the properties of those information items and properties of the component they correspond to are as follows:
all
Element Information Item<all
id = ID
maxOccurs = 1 : 1
minOccurs = (0 | 1) : 1
{any attributes with non-schema namespace . . .}>
Content: (annotation?, element*)
</all>
<choice
id = ID
maxOccurs =
(nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (element | group | choice | sequence | any)*)
</choice>
<sequence
id = ID
maxOccurs =
(nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (element | group | choice | sequence | any)*)
</sequence>
minOccurs=maxOccurs=0
, in which case the item
corresponds to no component at all):maxOccurs
[attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs
[attribute], if present, otherwise 1
.n
sub-sequences where n
is the length of {particles} such that each of the sub-sequences in order is ·valid·
with respect to the corresponding particle in the {particles} as defined in Element Sequence Locally Valid (Particle) (§3.9.4).n
sub-sequences where n
is the length of {particles} such that there is a one-to-one mapping between the sub-sequences and the {particles} where each sub-sequence is ·valid· with respect to the corresponding particle as defined in Element Sequence Locally Valid (Particle) (§3.9.4).0
), and each is ·valid· with respect to its corresponding declaration. The elements can occur in arbitrary order.All model groups (see Model Groups (§3.8)) must satisfy the following constraints.
=1
which is the {particle} of the {content type} of a
complex type definition.Issue (RQ-146i):Issue 2544 (RQ-146 element declarations consistent)Some corner cases, e.g. involving 'skip' wildcards, have emerged with respect to this constraint. It will be restated at a higher level of abstraction, in terms of desired outcome. See also (§3.4).Resolution:
This constraint will be restated in terms of intended outcome, i.e. that (modulo the impact of xsi:type) validation of an EII with a type definition will always assign the same type definitions to elements or attributes of the same name.
The following constraints define relations appealed to elsewhere in this specification.
0
if there are no {particles}).0
if there are no {particles}).0
if there are no {particles}).0
if there are no {particles}).As described in Model Groups (§3.8), particles contribute to the definition of content models.
<xs:element ref="egg" minOccurs="12" maxOccurs="12"/> <xs:group ref="omelette" minOccurs="0"/> <xs:any maxOccurs="unbounded"/>
The particle schema component has the following properties:
In general, multiple element information item [children], possibly with intervening character [children] if the content type is mixed, can be ·validated· with respect to a single particle. When the {term} is an element declaration or wildcard, {min occurs} determines the minimum number of such element [children] that can occur. The number of such children must be greater than or equal to {min occurs}. If {min occurs} is 0, then occurrence of such children is optional.
Again, when the {term} is an element declaration or wildcard, the number of such element [children] must be less than or equal to any numeric specification of {max occurs}; if {max occurs} is unbounded, then there is no upper bound on the number of such children.
When the {term} is a model group, the permitted occurrence range is determined by a combination of {min occurs} and {max occurs} and the occurrence ranges of the {term}'s {particles}.
Particles correspond to all three elements (<element> not immediately within <schema>, <group> not immediately within <schema> and <any>) which allow minOccurs
and maxOccurs
attributes. These in turn correspond to
two components in each case, a particle and its {term}. The appropriate mapping is described in XML Representation of Element Declaration Schema Components (§3.3.2), XML Representation of Model Group Schema Components (§3.8.2) and XML Representation of Wildcard Schema Components (§3.10.2) respectively.
n
sub-sequences such that
n
is greater than or equal to {min occurs}.All particles (see Particles (§3.9)) must satisfy the following constraints.
The following constraints define relations appealed to elsewhere in this specification.
=1
and its {term} is a sequence group whose {particles}' first member is a particle all of whose properties, recursively, are identical to those of B, with the exception of {annotation} properties.The approach to defining a type by restricting another type definition set out here is designed to ensure that types defined in this way are guaranteed to be a subset of the type they restrict. This is accomplished by requiring a clear mapping between the components of the base type definition and the restricting type definition. Permissible mappings are set out below via a set of recursive definitions, bottoming out in the obvious cases, e.g. where an (restricted) element declaration corresponds to another (base) element declaration with the same name and type but the same or wider range of occurrence.
Issue (RQ-11i): Issue 3042 (RQ-11 pointless occurrences rule), Issue 3043 (RQ-12 choice-vs-choice rules), Issue 2820 (RQ-17 simplify restriction rules) A number of cases have emerged in which the detailed rules in this section do not allow content models that common sense suggests should be allowed, or vice versa. The decision to move to a higher-level definition of restriction (see (§2.2.1.1)) means these issues have actually been overtaken.Resolution:
The decision to move to a higher-level definition of restriction means almost all of this constraint will disappear.
1
for each of the declarations in its ·substitution group·.0
.Base Particle | |||||||
---|---|---|---|---|---|---|---|
elt | any | all | choice | sequence | |||
Derived Particle | elt | NameAnd- TypeOK | NSCompat | Recurse- AsIfGroup | Recurse- AsIfGroup | RecurseAs- IfGroup | |
any | Forbidden | NSSubset | Forbidden | Forbidden | Forbidden | ||
all | Forbidden | NSRecurse- CheckCardinality | Recurse | Forbidden | Forbidden | ||
choice | Forbidden | NSRecurse- CheckCardinality | Forbidden | RecurseLax | Forbidden | ||
seq- uence | Forbidden | NSRecurse- CheckCardinality | Recurse- Unordered | MapAndSum | Recurse |
Issue (RQ-15i):Issue 2850 (RQ-15 restriction and identity constraints)Version 1.0 got the appropriate constraint for identity-constraint definitions and restriction backwards — the restricted definition must have the same or more constraints, not less.Resolution:
When you're constructing a restricted type, then
- the identity constraints of a local element are inherited;
- any new ones (those occurring in the declaration of E local to R) are added.
[IG Archive (W3C-member-only link)]
1
and with {particles} consisting of a single particle
the same as the element declaration must be a ·valid restriction· of the group as defined by Particle Derivation OK (All:All,Sequence:Sequence -- Recurse) (§3.9.6), Particle Derivation OK (Choice:Choice -- RecurseLax) (§3.9.6) or Particle Derivation OK (All:All,Sequence:Sequence -- Recurse) (§3.9.6), depending on whether the group is all, choice or sequence.Note:
The exception to the third clause above for derivations from the ·ur-type definition· is necessary as its wildcards have a {process contents} of lax, so without this exception, no use of wildcards with {process contents} of skip would be possible.0
.0
.In order to exploit the full potential for extensibility offered by XML plus namespaces, more provision is needed than DTDs allow for targeted flexibility in content models and attribute declarations. A wildcard provides for ·validation· of attribute and element information items dependent on their namespace name, but independently of their local name.
Issue (RQ-9i):Issue 2867 (RQ-9 wildcard namespace sets)In version 1.0 negated wildcards were restricted to negating only one namespace. Experience suggests that at least at the component level this may need to be expanded, but no final decision will be made on this until details of the change in interpretation of wildcards more generally (see (§3.4)) are worked out.At the moment wildcards can only negate a single namespace. To handle certain cases which become possible because to the change in interpretation of wildcards as subordinate to explicit elements (see (§3.4)), it may be necessary to negate/exclude a set of explicitly enumerated expanded names. This would be a change at the component level only.A related possibility, more likely motivated by versioning needs, would be to provide, perhaps again only at the component level for now, for sets of namespace names to be negated.
<xs:any processContents="skip"/> <xs:any namespace="##other" processContents="lax"/> <xs:any namespace="http://www.w3.org/1999/XSL/Transform"/> <xs:any namespace="##targetNamespace"/> <xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>
The wildcard schema component has the following properties:
{namespace constraint} provides for ·validation· of attribute and element items that:
{process contents} controls the impact on ·assessment· of the information items allowed by wildcards, as follows:
xsi:type
, and the
item must be ·valid· as
appropriate.
See Annotations (§3.13) for information on the role of the {annotations} property.
The XML representation for a wildcard schema component is an <any> or <anyAttribute> element information item. The correspondences between the properties of an <any> information item and properties of the components it corresponds to are as follows (see <complexType> and <attributeGroup> for the correspondences for <anyAttribute>):
any
Element Information Item<any
id = ID
maxOccurs =
(nonNegativeInteger | unbounded)
: 1
minOccurs = nonNegativeInteger : 1
namespace =
((##any | ##other) | List of
(anyURI | (##targetNamespace | ##local))
)
: ##any
processContents = (lax | skip | strict) : strict
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</any>
minOccurs=maxOccurs=0
, in which case the item
corresponds to no component at all):maxOccurs
[attribute] equals unbounded, otherwise the ·actual value· of the maxOccurs
[attribute], if present, otherwise 1
.namespace
[attribute]: if absent, then a Namespace Constraint with {variety} any, otherwise as follows:targetNamespace
[attribute] of the <schema> ancestor
element information item if present, otherwise·absent·##targetNamespace
, the corresponding member is the ·actual value· of the targetNamespace
[attribute] of the <schema> ancestor
element information item if present, otherwise ·absent·.##local
, the corresponding member is ·absent·.Wildcards are subject to the same ambiguity constraints (Unique Particle Attribution (§3.8.6)) as other content model particles: If an instance element could match either an explicit particle and a wildcard, or one of two wildcards, within the content model of a type, that model is in error.
All wildcards (see Wildcards (§3.10)) must satisfy the following constraint.
The following constraints define a relation appealed to elsewhere in this specification.
Identity-constraint definition components provide for uniqueness and reference constraints with respect to the contents of multiple elements and attributes.
<xs:key name="fullName"> <xs:selector xpath=".//person"/> <xs:field xpath="forename"/> <xs:field xpath="surname"/> </xs:key> <xs:keyref name="personRef" refer="fullName"> <xs:selector xpath=".//personPointer"/> <xs:field xpath="@first"/> <xs:field xpath="@last"/> </xs:keyref> <xs:unique name="nearlyID"> <xs:selector xpath=".//*"/> <xs:field xpath="@id"/> </xs:unique>
The identity-constraint definition schema component has the following properties:
Issue (RQ-14i):Issue 2848 (RQ-14 annotations on field and select)Version 1.0 provided no home for annotations onxs:field
andxs:select
. The overall reworking of annotation at the component level described in (§3.4.1) will take care of this.Resolution:
See (§3.4.1).
A restricted XPath (XML Path Language, James Clark and Steve DeRose, eds., W3C, 16 November 1999.) expression.
Editorial Note: Should be a bibref
If a value is present, its {identity-constraint category} must be key or unique.
Identity-constraint definitions are identified by their {name} and {target namespace}; Identity-constraint definition identities must be unique within an ·XML Schema·. See References to schema components across namespaces (<import>
) (§4.2.3) for the use of component
identifiers when importing one schema into another.
Informally, {identity-constraint category} identifies the Identity-constraint definition as playing one of three roles:
These constraints are specified along side the specification of types for the
attributes and elements involved, i.e. something declared as of type integer
may also serve as a key. Each constraint declaration has a name, which exists in a
single symbol space for constraints. The
identity
conditions
appealed to in checking these constraints apply to the
values of
the fields selected, not their
lexical representation, so that for example 3.0
and 3
would be conflicting keys if they were both
decimal, but non-conflicting if
they were both strings, or one was a string and one a decimal.
Overall the augmentations to XML's ID/IDREF
mechanism are:
{selector} specifies a restricted XPath ([XPath]) expression relative to instances of the element being declared. This must identify a node set of subordinate elements (i.e. contained within the declared element) to which the constraint applies.
{fields} specifies XPath expressions relative to each element selected by a {selector}. This must identify a single node (element or attribute) whose content or value, which must be of a simple type, is used in the constraint. It is possible to specify an ordered list of {fields}s, to cater to multi-field keys, keyrefs, and uniqueness constraints.
In order to reduce the burden on implementers, in particular implementers of streaming processors, only restricted subsets of XPath expressions are allowed in {selector} and {fields}. The details are given in Constraints on Identity-constraint Definition Schema Components (§3.11.6).
xsl:key
.See Annotations (§3.13) for information on the role of the {annotations} property.
The XML representation for an identity-constraint definition schema component is either a <key>, a <keyref> or a <unique> element information item. The correspondences between the properties of those information items and properties of the component they correspond to are as follows:
unique
Element Information Item<unique
id = ID
name = NCName
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (selector, field+))
</unique>
<key
id = ID
name = NCName
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (selector, field+))
</key>
<keyref
id = ID
name = NCName
refer = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (selector, field+))
</keyref>
<selector
id = ID
xpath = a subset of XPath expression, see below
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</selector>
<field
id = ID
xpath = a subset of XPath expression, see below
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</field>
targetNamespace
[attribute] of the parent schema
element information item.xpath
[attribute] of the <selector> element information item among the [children]xpath
[attribute]s of the <field> element information item [children], in order.refer
[attribute], otherwise ·absent·.<xs:element name="vehicle"> <xs:complexType> . . . <xs:attribute name="plateNumber" type="xs:integer"/> <xs:attribute name="state" type="twoLetterCode"/> </xs:complexType> </xs:element> <xs:element name="state"> <xs:complexType> <xs:sequence> <xs:element name="code" type="twoLetterCode"/> <xs:element ref="vehicle" maxOccurs="unbounded"/> <xs:element ref="person" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:key name="reg"> <!-- vehicles are keyed by their plate within states --> <xs:selector xpath=".//vehicle"/> <xs:field xpath="@plateNumber"/> </xs:key> </xs:element> <xs:element name="root"> <xs:complexType> <xs:sequence> . . . <xs:element ref="state" maxOccurs="unbounded"/> . . . </xs:sequence> </xs:complexType> <xs:key name="state"> <!-- states are keyed by their code --> <xs:selector xpath=".//state"/> <xs:field xpath="code"/> </xs:key> <xs:keyref name="vehicleState" refer="state"> <!-- every vehicle refers to its state --> <xs:selector xpath=".//vehicle"/> <xs:field xpath="@state"/> </xs:keyref> <xs:key name="regKey"> <!-- vehicles are keyed by a pair of state and plate --> <xs:selector xpath=".//vehicle"/> <xs:field xpath="@state"/> <xs:field xpath="@plateNumber"/> </xs:key> <xs:keyref name="carRef" refer="regKey"> <!-- people's cars are a reference --> <xs:selector xpath=".//car"/> <xs:field xpath="@regState"/> <xs:field xpath="@regPlate"/> </xs:keyref> </xs:element> <xs:element name="person"> <xs:complexType> <xs:sequence> . . . <xs:element name="car"> <xs:complexType> <xs:attribute name="regState" type="twoLetterCode"/> <xs:attribute name="regPlate" type="xs:integer"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element>
state
element is defined, which
contains a code
child and some vehicle
and person
children. A vehicle
in turn has a plateNumber
attribute,
which is an integer, and a state
attribute. State's
code
s are a key for them within the document. Vehicle's
plateNumber
s are a key for them within states, and
state
and
plateNumber
is asserted to be a key for
vehicle
within the document as a whole. Furthermore, a person
element has
an empty car
child, with regState
and
regPlate
attributes, which are then asserted together to refer to
vehicle
s via the carRef
constraint. The requirement
that a vehicle
's state
match its containing
state
's code
is not expressed here.All identity-constraint definitions (see Identity-constraint Definitions (§3.11)) must satisfy the following constraint.
Selector XPath expressions | ||||||||||||||||
|
child
axis whose abbreviated form is
as given above.Lexical productions | ||||||||
|
Path in Field XPath expressions | ||||
|
child
and/or attribute
axes whose abbreviated form is
as given above.Notation declarations reconstruct XML NOTATION declarations.
<xs:notation name="jpeg" public="image/jpeg" system="viewer.exe">
The notation declaration schema component has the following properties:
As defined in Extensible Markup Language (XML) 1.1, Second Edition, Tim Bray et al., eds., W3C, 4 February 2004.
Editorial Note: Should use bibref
Notation declarations do not participate in ·validation· as such. They are referenced in the course of ·validating· strings as members of the NOTATION simple type.
See Annotations (§3.13) for information on the role of the {annotations} property.
The XML representation for a notation declaration schema component is a <notation> element information item. The correspondences between the properties of that information item and properties of the component it corresponds to are as follows:
notation
Element Information Item<notation
id = ID
name = NCName
public = token
system = anyURI
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</notation>
targetNamespace
[attribute] of the parent schema
element information item.<xs:notation name="jpeg" public="image/jpeg" system="viewer.exe" /> <xs:element name="picture"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:hexBinary"> <xs:attribute name="pictype"> <xs:simpleType> <xs:restriction base="xs:NOTATION"> <xs:enumeration value="jpeg"/> <xs:enumeration value="png"/> . . . </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <picture pictype="jpeg">...</picture>
All notation declarations (see Notation Declarations (§3.12)) must satisfy the following constraint.
Annotations provide for human- and machine-targeted annotations of schema components.
<xs:simpleType fn:note="special"> <xs:annotation> <xs:documentation>A type for experts only</xs:documentation> <xs:appinfo> <fn:specialHandling>checkForPrimes</fn:specialHandling> </xs:appinfo> </xs:annotation>
The annotation schema component has the following properties:
{user information} is intended for human consumption,
{application information} for automatic processing. In both
cases, provision is made for an optional URI reference to supplement the local
information, as the value of the source
attribute of the
respective element information items. ·Validation· does not involve dereferencing these URIs, when present. In the case of {user information}, indication should be given as to the identity of the (human) language used in the contents, using the xml:lang
attribute.
{attributes} ensures that when schema authors take advantage of the provision for adding attributes from namespaces other than the XML Schema namespace to schema documents, they are available within the components corresponding to the element items where such attributes appear.
Issue (RQ-19i):Issue 2851 (RQ-19 annotations in PSVI)Out-of-band attributes were not always handled properly during component construction from schema documents. This is fixed by the overall reworking of annotation construction described in (§3.4.1).Resolution:
See (§3.4.1).
Annotations do not participate in ·validation· as such. Provided an annotation itself satisfies all relevant ·Schema Component Constraints· it cannot affect the ·validation· of element information items.
The name [Definition:] Annotated Component covers all the different kinds of component which may have annotations.
Annotation of schemas and schema components, with material for human or computer consumption, is provided for by allowing application information and human information at the beginning of most major schema elements, and anywhere at the top level of schemas. The XML representation for an annotation schema component is an <annotation> element information item. The correspondences between the properties of that information item and properties of the component it corresponds to are as follows:
annotation
Element Information Item<annotation
id = ID
{any attributes with non-schema namespace . . .}>
Content: (appinfo | documentation)*
</annotation>
<appinfo
source = anyURI
{any attributes with non-schema namespace . . .}>
Content: ({any})*
</appinfo>
<documentation
source = anyURI
xml:lang = language
{any attributes with non-schema namespace . . .}>
Content: ({any})*
</documentation>
The annotation component corresponding to the <annotation> element in the example above will have one element item in each of its {user information} and {application information} and one attribute item in its {attributes}.
None as such: the addition of annotations to the ·post-schema-validation infoset· is covered by the ·post-schema-validation infoset· contributions of the enclosing components.
All annotations (see Annotations (§3.13)) must satisfy the following constraint.
Simple type definitions provide for constraining character information item [children] of element and attribute information items.
<xs:simpleType name="fahrenheitWaterTemp"> <xs:restriction base="xs:decimal"> <xs:fractionDigits value="2"/> <xs:minExclusive value="0.00"/> <xs:maxExclusive value="100.00"/> </xs:restriction> </xs:simpleType>
The simple type definition schema component has the following properties:
Either an Attribute Declaration, an Element Declaration, a Complex Type Definition or a Simple Type Definition.
With one exception, the {base type definition} of any Simple Type Definition is a Simple Type Definition. The exception is ·anySimpleType·, which has ·anyType·, a Complex Type Definition, as its {base type definition}.
Simple types are identified by their {name} and {target namespace}. Except
for anonymous simple types (those with no {name}), since
type definitions (i.e. both simple and complex type definitions taken together) must be uniquely identified within an ·XML
Schema·, no simple type definition can have the same name as another
simple or complex type definition. Simple type {name}s and {target namespace}s
are provided for reference from
instances (see xsi:type (§2.6.1)), and for use in the XML
representation of schema components
(specifically in <element> and <attribute>). See References to schema components across namespaces (<import>
) (§4.2.3) for the use of component
identifiers when importing one schema into another.
A simple type definition with an empty specification for {final} can be used as the {base type definition} for other types derived by either of extension or restriction, or as the {item type definition} in the definition of a list, or in the {member type definitions} of a union; the explicit values extension, restriction, list and union prevent further derivations by extension (to yield a complex type) and restriction (to yield a simple type) and use in constructing lists and unions respectively.
{variety} determines whether the simple type corresponds to an atomic, list or union type as defined by [XML Schema: Datatypes].
As described in Type Definition Hierarchy (§2.2.1.1), every simple type definition is a ·restriction· of some other simple type (the {base type definition}), which is the ·simple ur-type definition· if and only if the type definition in question is ·anyAtomicType· or a list or union type definition which is not itself derived by restriction from a list or union respectively.A type definition has ·anyAtomicType· as its {base type definition} if and only if it is one of the built-in primitive datatypes. Each atomic type is ultimately a restriction of exactly one such built-in primitive datatype, which is its {primitive type definition}.
{facets} for each simple type definition are selected from those defined in [XML Schema: Datatypes]. For atomic definitions, these are restricted to those appropriate for the corresponding {primitive type definition}. Therefore, the value space and lexical space (i.e. what is ·validated· by any atomic simple type) is determined by the pair ({primitive type definition}, {facets}).
As specified in [XML Schema: Datatypes], list simple type definitions ·validate· space separated tokens, each of which conforms to a specified simple type definition, the {item type definition}. The item type specified must not itself be a list type, and must be one of the types identified in [XML Schema: Datatypes] as a suitable item type for a list simple type. In this case the {facets} apply to the list itself, and are restricted to those appropriate for lists.
A union simple type definition ·validates· strings which satisfy at least one of its {member type definitions}. As in the case of list, the {facets} apply to the union itself, and are restricted to those appropriate for unions.
The ·simple ur-type definition· or ·anyAtomicType· must not be named as the {base type definition} of any user-defined atomic simple type definitions: as they allow no constraining facets, this would be incoherent.
See Annotations (§3.13) for information on the role of the {annotations} property.
simpleType
Element Information Item<simpleType
final =
(#all | List of (list | union | restriction | extension))
id = ID
name = NCName
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (restriction | list | union))
</simpleType>
<restriction
base = QName
id = ID
{any attributes with non-schema namespace . . .}>
Content: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | maxScale | minScale | length | minLength | maxLength | enumeration | whiteSpace | pattern)*))
</restriction>
<list
id = ID
itemType = QName
{any attributes with non-schema namespace . . .}>
Content: (annotation?, simpleType?)
</list>
<union
id = ID
memberTypes = List of QName
{any attributes with non-schema namespace . . .}>
Content: (annotation?, simpleType*)
</union>
name
[attribute]
if present on the <simpleType> element,
otherwise ·absent·.targetNamespace
[attribute] of
the parent <schema>
element information item if present,
otherwise ·absent·.base
[attribute] of <restriction>, if present, otherwise the
type definition corresponding to the <simpleType> among
the [children] of <restriction>.{
restriction, extension, list,
union}
, determined as follows.
[Definition:] Let
FS be
the ·actual value· of the
final
[attribute],
if present, otherwise the ·actual value· of the
finalDefault
[attribute] of the ancestor
schema
element,
if present, otherwise the empty string. Then the property value is
the appropriate case among the following:
itemType
[attribute] of <list>,
or (b), corresponding to the <simpleType> among
the [children] of <list>, whichever is present.
itemType
[attribute] or a <simpleType> [child], but not both.memberTypes
[attribute] of <union>,
if any, and (b)
corresponding to the <simpleType>s among
the [children] of <union>, if any, in order.
memberTypes
[attribute] or one or more <simpleType> [children], or both.||Editorial Note: Priority Feedback Request||
base
[attribute]
or a <simpleType> among its [children], but not
both.itemType
[attribute] or a <simpleType> among its [children],
but not both.memberTypes
[attribute] or
it has at least one simpleType
[child].memberTypes
[attribute] which resolve to simple types
with {variety} union which
include among their
transitive
membership the component corresponding to the <simpleType>.All simple type definitions must satisfy both the following constraints.
[Definition:] A simple type definition T is a valid restriction of its {base type definition} if and only if T satisfies constraint Derivation Valid (Restriction, Simple) (§3.14.6).
The following constraint defines relations appealed to elsewhere in this specification.
||Editorial Note: Priority Feedback Request||
The Simple Type Definition of anySimpleType is present in every schema. It has the following properties:
anySimpleType
'http://www.w3.org/2001/XMLSchema
'The definition of ·anySimpleType· is the root of the simple type definition hierarchy, and as such mediates between the other simple type definitions, which all eventually trace back to it via their {base type definition} properties, and ·anyType·, which is its {base type definition}.
The Simple Type Definition of anyAtomicType is present in every schema. It has the following properties:
anyAtomicType
'http://www.w3.org/2001/XMLSchema
'Simple type definitions corresponding to all the built-in primitive datatypes, namely string, boolean, float, double, decimal, precisionDecimal, dateTime, duration, time, date, gMonth, gMonthDay, gDay, gYear, gYearMonth, hexBinary, base64Binary, anyURI, QName and NOTATION (see the Primitive Datatypes section of [XML Schema: Datatypes]) are present by definition in every schema.as follows:
http://www.w3.org/2001/XMLSchema
'[as appropriate]
Similarly, simple type definitions corresponding to all the other built-in datatypes (see the Other Built-in Datatypes section of [XML Schema: Datatypes]) are present by definition in every schema, with properties as specified in [XML Schema: Datatypes] and as represented in XML in Illustrative XML representations for the built-in ordinary type definitions.
http://www.w3.org/2001/XMLSchema
'A schema consists of a set of schema components.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.com/example"> . . . </xs:schema>
At the abstract level, the schema itself is just a container for its components.
A schema is represented in XML by one or more ·schema documents·, that is, one or more <schema> element information items. A ·schema document· contains representations for a collection of schema components, e.g. type definitions and element declarations, which have a common {target namespace}. A ·schema document· which has one or more <import> element information items corresponds to a schema with components with more than one {target namespace}, see Import Constraints and Semantics (§4.2.3.2).
schema
Element Information Item<schema
attributeFormDefault = (qualified | unqualified) : unqualified
blockDefault =
(#all | List of (extension | restriction | substitution))
: ''
elementFormDefault = (qualified | unqualified) : unqualified
finalDefault =
(#all | List of (extension | restriction | list | union))
: ''
id = ID
targetNamespace = anyURI
version = token
xml:lang = language
{any attributes with non-schema namespace . . .}>
Content: ((include | import | redefine | annotation)*, (((simpleType | complexType | group | attributeGroup) | element | attribute | notation), annotation*)*)
</schema>
<include>
) (§4.2.1) and References to schema components across namespaces (<import>
) (§4.2.3).<include>
) (§4.2.1) and References to schema components across namespaces (<import>
) (§4.2.3).<include>
) (§4.2.1) and References to schema components across namespaces (<import>
) (§4.2.3).<include>
) (§4.2.1) and References to schema components across namespaces (<import>
) (§4.2.3).<include>
) (§4.2.1) and References to schema components across namespaces (<import>
) (§4.2.3).<include>
) (§4.2.1) and References to schema components across namespaces (<import>
) (§4.2.3).<include>
) (§4.2.1) and References to schema components across namespaces (<import>
) (§4.2.3).Note that none of the attribute information items displayed above
correspond directly to properties of schemas. The blockDefault
,
finalDefault
, attributeFormDefault
, elementFormDefault
and targetNamespace
attributes are appealed to in the sub-sections above, as they provide
global information applicable to many representation/component correspondences. The
other attributes (id
and version
) are for user
convenience, and this specification defines no semantics for them.
The definition of the schema abstract data model in XML Schema Abstract Data Model (§2.2) makes clear that most components have a {target namespace}. Most components corresponding to representations within a given <schema> element information item will have a {target namespace} which corresponds to the targetNamespace
attribute.
Since the empty string is not a legal namespace name, supplying
an empty string for targetNamespace
is incoherent, and is not the same
as not specifying it at all. The appropriate form of schema document
corresponding to a ·schema· whose components have no
{target namespace} is one which has no
targetNamespace
attribute specified at all.
Although the example schema at the beginning of this section might be a complete XML document, <schema> need not be the document element, but can appear within other documents. Indeed there is no requirement that a schema correspond to a (text) document at all: it could correspond to an element information item constructed 'by hand', for instance via a DOM-conformant API.
Aside from <include> and <import>, which do not correspond directly to any schema component at all, each of the element information items which may appear in the content of <schema> corresponds to a schema component, and all except <annotation> are named. The sections below present each such item in turn, setting out the components to which it may correspond.
Reference to schema components from a schema document is managed in
a uniform way, whether the component corresponds to an element
information item from the same schema document or is imported
(References to schema components across namespaces (<import>
) (§4.2.3)) from an external schema
(which may, but need not, correspond to an actual schema
document). The form of all such references is a ·QName·.
[Definition:] A QName is a name with an optional namespace qualification, as defined in [XML-Namespaces 1.1]. When used in connection with the XML representation of schema components or references to them, this refers to the simple type QName as defined in [XML Schema: Datatypes].
[Definition:] An NCName is a name with no colon, as defined in [XML-Namespaces 1.1]. When used in connection with the XML representation of schema components in this specification, this refers to the simple type NCName as defined in [XML Schema: Datatypes].
In each of the XML
representation expositions in the following sections, an attribute is shown as
having type QName
if and only if it is
interpreted as referencing a schema component.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns="http://www.example.com" targetNamespace="http://www.example.com"> . . . <xs:element name="elem1" type="Address"/> <xs:element name="elem2" type="xhtml:blockquote"/> <xs:attribute name="attr1" type="xsl:quantity"/> . . . </xs:schema>
<import>
) (§4.2.3) for a discussion of importing.The names of schema components such as type definitions and element declarations are not of type ID: they are not unique within a schema, just within a symbol space. This means that simple fragment identifiers will not always work to reference schema components from outside the context of schema documents.
There is currently no provision in the definition of the interpretation
of fragment identifiers for the text/xml
MIME type, which is the
MIME type for schemas, for referencing
schema components as such. However,
[XPointer] provides a mechanism which maps well onto the
notion of symbol spaces as it is reflected in the XML representation of schema components. A fragment identifier of the form
#xpointer(xs:schema/xs:element[@name="person"])
will uniquely identify
the representation of a top-level element declaration with name person
, and similar fragment
identifiers can obviously be constructed for the other global symbol spaces.
Short-form fragment identifiers may also be used in some cases, that is
when a DTD or XML Schema is available for the schema in question, and the
provision of an id
attribute for the representations of all primary and secondary schema
components, which is of type
ID, has been exploited.
It is a matter for applications to specify whether they interpret document-level references of either of the above varieties as being to the relevant element information item (i.e. without special recognition of the relation of schema documents to schema components) or as being to the corresponding schema component.
[Definition:] Whenever the word resolve in any form is used in this chapter in connection with a ·QName· in a schema document, the following definition QName resolution (Schema Document) (§3.15.3) must be understood:
targetNamespace
[attribute].namespace
[attribute].targetNamespace
[attribute] of
the <schema> element information item of the schema document containing the ·QName·.namespace
[attribute] of some
<import> element information item contained in the <schema> element information item of that schema document.As the discussion above at Schema Component Details (§3) makes clear, at the level of schema components and ·validation·, reference to components by name is normally not involved. In a few cases, however, qualified names appearing in information items being ·validated· must be resolved to schema components by such lookup. The following constraint is appealed to in these cases.
targetNamespace
matches the sibling [schema namespace] property above (or whose
targetNamespace
was ·absent· but that contributed components to
that namespace by being <include>d by a schema document with that
targetNamespace
as per
Assembling a schema for a single target namespace from multiple schema definition documents (<include>
) (§4.2.1)):
All schemas (see Schemas as a Whole (§3.15)) must satisfy the following constraint.
Issue (RQ-151i):Issue 2824 (RQ-151 schema composition)Experience with version 1.0 has shown that the rules in this section miss a few cases, and are unclear in others. A full rewrite taking a more formal approach, without changing the intended semantics, will be done to address these problems.Resolution:
Give a complete and formal definition of schema composition, and use it for currently defined (e.g. include) and currently undefined (e.g. schema docs on command line) cases.
This chapter defines the mechanisms by which this specification establishes the necessary precondition for ·assessment·, namely access to one or more schemas. This chapter also sets out in detail the relationship between schemas and namespaces, as well as mechanisms for modularization of schemas, including provision for incorporating definitions and declarations from one schema in another, possibly with modifications.
Conformance (§2.4) describes three levels of conformance for schema processors, and Schemas and Schema-validity Assessment (§5) provides a formal definition of ·assessment·. This section sets out in detail the 3-layer architecture implied by the three conformance levels. The layers are:
Layer 1 specifies the manner in which a schema composed of schema components can be applied to in the ·assessment· of an instance element information item. Layer 2 specifies the use of <schema> elements in XML documents as the standard XML representation for schema information in a broad range of computer systems and execution environments. To support interoperation over the World Wide Web in particular, layer 3 provides a set of conventions for schema reference on the Web. Additional details on each of the three layers is provided in the sections below.
The fundamental purpose of the ·assessment· core is to define ·assessment· for a single element information item and its descendants with respect to a complex type definition. All processors are required to implement this core predicate in a manner which conforms exactly to this specification.
·assessment· is defined with reference to an ·XML Schema· (note not a ·schema document·) which consists of (at a minimum) the set of schema components (definitions and declarations) required for that ·assessment·. This is not a circular definition, but rather a post facto observation: no element information item can be fully assessed unless all the components required by any aspect of its (potentially recursive) ·assessment· are present in the schema.
As specified above, each schema component is associated directly or indirectly with a target namespace, or explicitly with no namespace. In the case of multi-namespace documents, components for more than one target namespace will co-exist in a schema.
Processors have the option to assemble (and perhaps to optimize or pre-compile) the entire schema prior to the start of an ·assessment· episode, or to gather the schema lazily as individual components are required. In all cases it is required that:
The obligation of a schema-aware processor as far as the ·assessment· core is concerned is to implement one or more of the options for ·assessment· given below in Assessing Schema-Validity (§5.2). Neither the choice of element information item for that ·assessment·, nor which of the means of initiating ·assessment· are used, is within the scope of this specification.
Although ·assessment· is defined recursively, it is also intended to be implementable in streaming processors. Such processors may choose to incrementally assemble the schema during processing in response, for example, to encountering new namespaces. The implication of the invariants expressed above is that such incremental assembly must result in an ·assessment· outcome that is the same as would be given if ·assessment· was undertaken again with the final, fully assembled schema.
The sub-sections of Schema Component Details (§3) define an XML representation for type definitions and element declarations and so on, specifying their target namespace and collecting them into schema documents. The two following sections relate to assembling a complete schema for ·assessment· from multiple sources. They should not be understood as a form of text substitution, but rather as providing mechanisms for distributed definition of schema components, with appropriate schema-specific semantics.
<include>
)Schema components for a single target namespace can be assembled from several ·schema documents·, that is several <schema> element information items:
include
Element Information Item<include
id = ID
schemaLocation = anyURI
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</include>
A <schema> information item may contain any number of <include> elements. Their schemaLocation
attributes, consisting of a URI reference, identify other ·schema documents·, that is <schema> information items.
The ·XML Schema· corresponding
to <schema> contains not only the components corresponding to its definition and declaration [children], but also
all the components of all the ·XML Schemas· corresponding to any <include>d schema documents.
Such included schema documents must either (a) have the same
targetNamespace
as the <include>ing schema document, or
(b) no targetNamespace
at all, in which case the <include>d schema document is converted to the <include>ing schema document's targetNamespace
.
schemaLocation
[attribute]
successfully resolves
one of the following must be true:application/xml
or text/xml
with an XML declaration
for preference, but this is not required), which in turn corresponds to a <schema>
element information item in a well-formed information set, which in turn
corresponds to a valid schema.targetNamespace
[attribute], and its ·actual value· is identical to the ·actual value· of the targetNamespace
[attribute] of SII’ (which must have such an [attribute]).targetNamespace
[attribute] of
SII’ is used. In particular, it replaces
·absent· in the following places:
code
was qualified)
nested within definitions;schemaLocation
[attribute] to fail to resolve it all,
in which case no corresponding inclusion is performed. It
is an error for it to resolve but the rest of clause 1
above to fail to be satisfied. Failure to resolve may well cause less than complete ·assessment· outcomes, of course.As discussed in Missing Sub-components (§5.3), ·QName·s in XML representations may fail to ·resolve·, rendering components incomplete
and unusable because of missing subcomponents. During schema
construction, implementations must retain ·QName· values for such references, in case
an appropriately-named component becomes available to discharge the
reference by the time it is actually needed. ·Absent· target ·namespace
name·s of such as-yet unresolved reference ·QName·s in <include>d
components must also be converted if clause 3.2 is
satisfied.<redefine>
)In order to provide some support for evolution and versioning, it is possible to incorporate components corresponding to a schema document with modifications. The modifications have a pervasive impact, that is, only the redefined components are used, even when referenced from other incorporated components, whether redefined themselves or not.
redefine
Element Information Item<redefine
id = ID
schemaLocation = anyURI
{any attributes with non-schema namespace . . .}>
Content: (annotation | (simpleType | complexType | group | attributeGroup))*
</redefine>
A <schema> information item may contain any number of <redefine> elements. Their schemaLocation
attributes, consisting of a URI reference, identify other ·schema documents·, that is <schema> information items.
The ·XML Schema· corresponding
to <schema> contains not only the components corresponding to its definition and declaration [children], but also
all the components of all the ·XML Schemas· corresponding to any <redefine>d schema documents.
Such schema documents must either (a) have the same
targetNamespace
as the <redefine>ing schema document, or
(b) no targetNamespace
at all, in which case the <redefine>d schema document is converted to the <redefine>ing schema document's targetNamespace
.
The definitions within the <redefine> element itself are restricted to be redefinitions of components from the <redefine>d schema document, in terms of themselves. That is,
Not all the components of the <redefine>d schema document need be redefined.
This mechanism is intended to provide a declarative and modular approach to schema modification, with functionality no different except in scope from what would be achieved by wholesale text copying and redefinition by editing. In particular redefining a type is not guaranteed to be side-effect free: it may have unexpected impacts on other type definitions which are based on the redefined one, even to the extent that some such definitions become ill-formed.
v1.xsd: <xs:complexType name="personName"> <xs:sequence> <xs:element name="title" minOccurs="0"/> <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:element name="addressee" type="personName"/> v2.xsd: <xs:redefine schemaLocation="v1.xsd"> <xs:complexType name="personName"> <xs:complexContent> <xs:extension base="personName"> <xs:sequence> <xs:element name="generation" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:redefine> <xs:element name="author" type="personName"/>
v2.xsd
has everything specified
by v1.xsd
, with the personName
type redefined, as
well as everything it specifies itself. According to
this schema, elements constrained
by the personName
type may end with a generation
element. This includes not only the author
element, but also the
addressee
element.schemaLocation
[attribute]
must successfully resolve.schemaLocation
[attribute]
successfully resolves
one of the following must be true:targetNamespace
[attribute], and its ·actual value· is identical to the ·actual value· of the targetNamespace
[attribute] of SII’ (which must have such an [attribute]).targetNamespace
[attribute] of SII’ is used (see clause 3.2 in Inclusion Constraints and Semantics (§4.2.1)
for details).restriction
or extension
among its
grand-[children] the ·actual value· of whose base
[attribute] must be the same as the ·actual value· of its own
name
attribute plus target namespace;ref
[attribute] is the same as the ·actual value· of its own
name
attribute plus target namespace, then
all of the following are true:minOccurs
and
maxOccurs
[attribute] is 1
(or ·absent·).name
attribute plus target
namespace successfully ·resolves· to a
model group definition in I.ref
[attribute] is the same as the ·actual value· of its own
name
attribute plus target namespace, then it has exactly one such group.name
attribute plus target
namespace successfully ·resolves· to an
attribute group definition in I.name
in
the <redefine>d schema document, as defined in Schema Component Details (§3), except that its {name} is ·absent· and its {context} is the redefining component, as defined in clause 1.2 below;ref
[attribute] whose ·actual value· is the same as the item's name
plus target namespace is resolved, a component which corresponds to the top-level definition item of that name and the appropriate kind in
I is used.<import>
)As described in XML Schema Abstract Data Model (§2.2), every top-level schema component is associated with
a target namespace (or, explicitly, with none). Furthermore,
each schema document carries on its <schema> element
at most one targetNamespace
attribute associating that document
with a target namespace. This section sets out
the
syntax and mechanisms by which references
may be made from within a ·schema
document· to components not within that document's target
namespace. Also included within the same syntax is an optional
facility for suggesting the URI of a
·schema document· containing
definitions and declarations for components from the foreign
target namespace.
schemaLocation
attribute.
Although the function of <import> is
unchanged in XML Schema Version 1.1, the presentation below has been
reorganized to clarify the two separate purposes served by
<import>.
import
Element Information Item<import
id = ID
namespace = anyURI
schemaLocation = anyURI
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</import>
The <import> element information item identifies namespaces
used in external references, i.e. those whose
·QName· identifies them as coming from a
different namespace (or none) than the enclosing schema document's
targetNamespace
.
At least two conditions must be satisfied for a
reference to be made to a foreign component: there must be not only a
means of addressing such foreign components but also a signal to
schema-aware processors that a schema document contains such
references. Thus, the <import> element information item
identifies namespaces used in external component
references, i.e. those whose
·QName· identifies them as coming
from a namespace different from that of the enclosing schema
document's targetNamespace
.
By contrast, a namespace used for other purposes in a schema document
need not be imported. There is no need, for example, to import the
namespace of a vocabulary such as HTML for use in schema <documentation> elements, unless that same namespace is also
used as the target namespace for component references.
The ·actual value· of
the
namespace
[attribute] indicates that the containing schema document may contain
qualified references to schema components in that namespace (via one or more
prefixes declared with namespace declarations in the normal way). If that
attribute is absent, then the import allows unqualified reference to components
with no target namespace.
Note that components to be imported need not be in the form of a
·schema document· and
need not in particular be declared in the particular schema document identified
by a schemaLocation
attribute; the processor
is free to access or construct components using means of its own
choosing, whether or not a schemaLocation
hint is provided.
html:p
. If there were no component reference, then
the import would be unnecessary; no import is needed for use of a namespace
in a <documentation>
or similar schema document element or attribute name.<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:html="http://www.w3.org/1999/xhtml" targetNamespace="uri:mywork" xmlns:my="uri:mywork"> <import namespace="http://www.w3.org/1999/xhtml"/> <annotation> <documentation> <html:p>[Some documentation for my schema]</html:p> </documentation> </annotation> . . . <complexType name="myType"> <sequence> <element ref="html:p" minOccurs="0"/> </sequence> . . . </complexType> <element name="myElt" type="my:myType"/> </schema>
The ·actual value· of the schemaLocation
attribute, if present on
an <import> element, gives a hint as to where a
serialization of a ·schema
document· with declarations and definitions for the
imported namespace (or none) may be found. When no schemaLocation
[attribute] is present, the schema author is leaving the
identification of that schema to the instance, application or user,
via the mechanisms described below in Layer 3: Schema Document Access and Web-interoperability (§4.3). When a
schemaLocation
attribute is present, it must contain a single URI
reference which the schema author warrants will resolve to a
serialization of a ·schema
document· containing
component(s) in the
<import>ed namespace.
Conformance profiles may further
restrict the use of the schemaLocation
attribute. For example,
one profile might mandate that the hint be
honored by the schema software, perhaps calling for a
processor-dependent error should the URI fail to resolve,
or mandating that the hint agree with some expected URI value;
another profile might mandate that the hint not
be honored,
etc.
namespace
and schemaLocation
[attribute] are optional, a bare <import/>
information item
is allowed. This simply allows unqualified reference to foreign
components with no target namespace without giving any hints as to where to find them.namespace
[attribute] is present, then its ·actual value· does not match the ·actual value· of the
enclosing <schema>'s targetNamespace
[attribute].namespace
[attribute] is not present, then the enclosing <schema> has a targetNamespace
[attribute]schemaLocation
and namespace
[attributes]||, provides a referent, as defined
by Schema Document Location Strategy (§4.3.2),||
one of the following must be true:namespace
[attribute], then its ·actual value· is identical to the ·actual value· of the targetNamespace
[attribute] of SII.schemaLocation
[attribute] is only a hint, it is open to applications to ignore all but the
first <import> for a given namespace, regardless of the ·actual value· of
schemaLocation
, but such a strategy risks missing useful
information when new schemaLocation
s are offered.Layers 1 and 2 provide a framework for ·assessment· and XML definition of schemas in a broad variety of environments. Over time, it is possible that a range of standards and conventions may well evolve to support interoperability of XML Schema implementations on the World Wide Web. Layer 3 defines the minimum level of function required of all conformant processors operating on the Web: it is intended that, over time, future standards (e.g. XML Packages) for interoperability on the Web and in other environments can be introduced without the need to republish this specification.
For interoperability, serialized ·schema documents·, like all other Web resources, should be identified by URI and retrieved using the standard mechanisms of the Web (e.g. http, https, etc.) Such documents on the Web must be part of XML documents (see clause 1.1), and are represented in the standard XML schema definition form described by layer 2 (that is as <schema> element information items).
Accept
header of application/xml,
text/xml; q=0.9, */*
is perhaps a reasonable starting point.As described in Layer 1: Summary of the Schema-validity Assessment Core (§4.1), processors are responsible for providing the schema components (definitions and declarations) needed for ·assessment·. This section introduces a set of normative conventions to facilitate interoperability for instance and schema documents retrieved and processed from the Web.
Processors on the Web are free to undertake ·assessment· against arbitrary schemas in any of the ways set out in Assessing Schema-Validity (§5.2). However, it is useful to have a common convention for determining the schema to use. Accordingly, general-purpose schema-aware processors (i.e. those not specialized to one or a fixed set of pre-determined schemas) undertaking ·assessment· of a document on the web must behave as follows:
targetNamespace
is
identical to the
namespace name, if any, of the element information item on which ·assessment· is undertaken.
The composition of the complete schema for use in ·assessment· is discussed in Layer 2: Schema Documents, Namespaces and Composition (§4.2) above. The means used to locate appropriate schema document(s) are processor and application dependent, subject to the following requirements:
schemaLocation
and noNamespaceSchemaLocation
[attributes] (in the XML Schema instance namespace,
that is, http://www.w3.org/2001/XMLSchema-instance
) (hereafter
xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
) are provided. The first records
the author's warrant with pairs of URI references (one for the namespace name, and
one for a hint as to the location of a schema document defining names for that
namespace name). The second similarly provides a URI reference as a hint as to
the location of a schema document with no targetNamespace
[attribute].Unless directed otherwise, for example by the invoking application
or by command line option, processors
should attempt to dereference each schema document location URI in the
·actual value· of such
xsi:schemaLocation
and xsi:noNamespaceSchemaLocation
[attributes], see details below.xsi:schemaLocation
and
xsi:noNamespaceSchemaLocation
[attributes] can occur on any
element. However, it is an error if such an attribute occurs
after the first appearance of an element or attribute information
item within an
element information item initially ·validated· whose [namespace name] it addresses. According to the rules of
Layer 1: Summary of the Schema-validity Assessment Core (§4.1), the corresponding schema may be lazily assembled, but is otherwise
stable throughout ·assessment·. Although schema location attributes can occur
on any element, and can be processed incrementally as discovered, their effect
is essentially global to the ·assessment·. Definitions and declarations remain
in effect beyond the scope of the element on which the binding is declared.
<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform http://www.w3.org/1999/XSL/Transform.xsd http://www.w3.org/1999/xhtml http://www.w3.org/1999/xhtml.xsd">
schemaLocation
can, but need not
be identical to those actually qualifying the element within whose start tag
it is found or its other attributes. For example, as above, all
schema location information can be declared on the document element
of a document, if desired,
regardless of where the namespaces are actually used. schemaLocation
,
xsi:schemaLocation
or xsi:noNamespaceSchemaLocation
,
schema-aware processors may implement any combination of the following
strategies, in any order:
Improved or alternative conventions for Web interoperability can be standardized in the future without reopening this specification. For example, the W3C is currently considering initiatives to standardize the packaging of resources relating to particular documents and/or namespaces: this would be an addition to the mechanisms described here for layer 3. This architecture also facilitates innovation at layer 2: for example, it would be possible in the future to define an additional standard for the representation of schema components which allowed e.g. type definitions to be specified piece by piece, rather than all at once.
Issue (RQ-144i):Issue 2822 (RQ-144 required properties) A much more systematic and detailed exposition will be provided of what kinds of processing/processors imply what sorts of requirements for properties and their values in the PSVI.Resolution:
Several overlapping but distinct positions have been offered on this issue. See http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Mar/0111.html) and http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Mar/0124.html (W3C-member-only links) for details. Summaries follow below:
Position 1
- We should say clearly that like the Infoset REC, our description of the PSVI defines, in the first instance, a vocabulary for describing the outcome of schema-validity assessment.
- The conformance section should say explicitly what it means to "completely and correctly implement . . . the Schema Information Set Contributions".What it should say is that a "Minimally conforming" processor must expose all the specified information.
- The existing classes of conformant processors should be renamed
And new definitions of corresponding "... special-purpose" processors should be added. These should allow 'self-consistent' subsets of Schema Component Constraints, Validation Rules, and Schema Information Set Contributions.
- Minimally conforming general-purpose;
- Minimally conforming general-purpose, in conformance to the XML Representation of Schemas;
- Fully conforming general-purpose.
Position 2
- Make support of the schema document format and the web media type orthogonal to levels of PSVI reporting. A processor that accepts schema documents "conforms to the XML representation of schemas."
- Make the processor conformance sections a completely separate chapter, to make clear that other people's processor conformance specs can appeal to the definition of the language and the PSVI.
- Make very clear that different specs can define processor conformance for different processor classes, and that our own processor classes are ones we recommend but not the only possible ones.
Position 3
- We might say that in order to conform w.r.t. the XML transfer syntax, a processor must not only accept all valid schema documents, but should reject or flag all invalid ones (i.e. it's not enough that the processor accept every member of the valid set; it must recognize the valid set by distinguishing it from its complement).
- The crucial bit might be the production of some part of the PSVI. The reason an off the shelf XSLT is not a schema processor is that it doesn't produce any actual PSVI output. If it did, it could be.
SynthesisIt was proposed to amend RQ-144 to make it say (not necessarily in these exact words):
- There should be a clean separation between descriptions of the language(s) and descriptions of processors.
- We should make a good attempt to call out (in a separate chapter) a particular specification of processor classes that we hope will be useful and widely deployed.
- We should make clear that other processor class descs are OK.
The architecture of schema-aware processing allows for a rich characterization of XML documents: schema validity is not a binary predicate.
This specification distinguishes between errors in schema construction and structure, on the one hand, and schema validation outcomes, on the other.
Before ·assessment· can be attempted, a schema is required.
Special-purpose applications are free to determine a schema for
use in ·assessment· by whatever
means are appropriate, but general purpose processors should implement
||the strategy set out in
Schema Document Location Strategy (§4.3.2)||||and
document a
strategy for locating schema components, exploiting at least some if not all of the non-hard-coded
methods outlined in
Terminology of schema construction
(§D.2)||, starting with the
namespaces declared in the document whose ·assessment·
is being undertaken, and the ·actual value·s of the
xsi:schemaLocation
and xsi:noNamespaceSchemaLocation
[attributes] thereof, if any, along with any other information about
schema identity or schema document location provided by users in
application-specific ways, if any.
It is an error if a schema and all the components which are the value of any of its properties, recursively, fail to satisfy all the relevant Constraints on Schemas set out in the last section of each of the subsections of Schema Component Details (§3).
If a schema is derived from one or more schema documents (that is, one or more <schema> element information items) based on the correspondence rules set out in Schema Component Details (§3) and Schemas and Namespaces: Access and Composition (§4), two additional conditions hold:
The three cases described above are the only types of error which this specification defines. With respect to the processes of the checking of schema structure and the construction of schemas corresponding to schema documents, this specification imposes no restrictions on processors after an error is detected. However ·assessment· with respect to schema-like entities which do not satisfy all the above conditions is incoherent. Accordingly, conformant processors must not attempt to undertake ·assessment· using such non-schemas.
With a schema which satisfies the conditions expressed in Errors in Schema Construction and Structure (§5.1) above, the schema-validity of an element information item can be assessed. ||Three||||Four|| primary approaches to this are possible:
xsi:type
) or not.
||The name for this method of invocation
reflects the fact that it is analogous to the
validation of an element information item which matches a
lax wildcard.||xsi:type
), then
·strict· assessment ensues;
if they do not identify any declaration or definition,
then no schema-validity assessment is performed (and
in typical cases the invoking process
will report an error to its environment; if no such
error is desired, lax wildcard validation will be used instead).
The name for this method of invocation
reflects the fact that it is analogous to the
validation of an element information item which matches a
strict wildcard.
The outcome of this effort, in any case, will be manifest in the [validation attempted] and [validity] properties on the element information item and its [attributes] and [children], recursively, as defined by Assessment Outcome (Element) (§3.3.5) and Assessment Outcome (Attribute) (§3.2.5). It is up to applications to decide what constitutes a successful outcome.
Note that every element and attribute information item participating in the ·assessment· will also have a [validation context] property which refers back to the element information item at which ·assessment· began. [Definition:] This item, that is the element information item at which ·assessment· began, is called the validation root.
At the beginning of Schema Component Details (§3), attention is drawn to the fact that most kinds of schema components have properties which are described therein as having other components, or sets of other components, as values, but that when components are constructed on the basis of their correspondence with element information items in schema documents, such properties usually correspond to QNames, and the ·resolution· of such QNames may fail, resulting in one or more values of or containing ·absent· where a component is mandated.
If at any time during ·assessment·, an element or attribute information item is being ·validated· with respect to a component of any kind any of whose properties has or contains such an ·absent· value, the ·validation· is modified, as following:
Because of the value specification for [validation attempted] in Assessment Outcome (Element) (§3.3.5), if this situation ever arises, the document as a whole cannot show a [validation attempted] of full.
Schema-aware processors are responsible for processing XML documents, schemas and schema documents, as appropriate given the level of conformance (as defined in Conformance (§2.4)) they support, consistently with the conditions set out above.
The XML representation of the schema for schema documents is presented here as a normative part of the specification, and as an illustrative example of how the XML Schema language can define itself using its own constructs. The names of XML Schema language types, elements, attributes and groups defined here are evocative of their purpose, but are occasionally verbose.
There is some annotation in comments, but a fuller annotation will require the use of embedded documentation facilities or a hyperlinked external annotation for which tools are not yet readily available.
Like any other XML document, schema
documents may carry XML and document type declarations. An XML
declaration and a document type declaration are provided here for
convenience. Since this schema document describes the XML Schema
language, the targetNamespace
attribute on the
schema
element refers to the XML Schema namespace
itself.
Schema documents conforming to this specification may be in XML 1.0 or XML 1.1. Conforming implementations may accept input in XML 1.0 or XML 1.1 or both. See Dependencies on Other Specifications (§1.3).
<!DOCTYPE xs:schema PUBLIC "-//W3C//DTD XMLSCHEMA 200102//EN" "XMLSchema.dtd" [ <!-- provide ID type information even for parsers which only read the internal subset --> <!ATTLIST xs:schema id ID #IMPLIED> <!ATTLIST xs:complexType id ID #IMPLIED> <!ATTLIST xs:complexContent id ID #IMPLIED> <!ATTLIST xs:simpleContent id ID #IMPLIED> <!ATTLIST xs:extension id ID #IMPLIED> <!ATTLIST xs:element id ID #IMPLIED> <!ATTLIST xs:group id ID #IMPLIED> <!ATTLIST xs:all id ID #IMPLIED> <!ATTLIST xs:choice id ID #IMPLIED> <!ATTLIST xs:sequence id ID #IMPLIED> <!ATTLIST xs:any id ID #IMPLIED> <!ATTLIST xs:anyAttribute id ID #IMPLIED> <!ATTLIST xs:attribute id ID #IMPLIED> <!ATTLIST xs:attributeGroup id ID #IMPLIED> <!ATTLIST xs:unique id ID #IMPLIED> <!ATTLIST xs:key id ID #IMPLIED> <!ATTLIST xs:keyref id ID #IMPLIED> <!ATTLIST xs:selector id ID #IMPLIED> <!ATTLIST xs:field id ID #IMPLIED> <!ATTLIST xs:include id ID #IMPLIED> <!ATTLIST xs:import id ID #IMPLIED> <!ATTLIST xs:redefine id ID #IMPLIED> <!ATTLIST xs:notation id ID #IMPLIED> ]> <?xml version='1.0'?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" blockDefault="#all" elementFormDefault="qualified" xml:lang="EN" targetNamespace="http://www.w3.org/2001/XMLSchema" version="Id: structures.xsd,v 1.2 2004/01/15 11:34:25 ht Exp "> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html"> The schema corresponding to this document is normative, with respect to the syntactic constraints it expresses in the XML Schema language. The documentation (within <documentation> elements) below, is not normative, but rather highlights important aspects of the W3C Recommendation of which this is a part</xs:documentation> </xs:annotation> <xs:annotation> <xs:documentation> The simpleType element and all of its members are defined in datatypes.xsd</xs:documentation> </xs:annotation> <xs:include schemaLocation="datatypes.xsd"/> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"> <xs:annotation> <xs:documentation> Get access to the xml: attribute groups for xml:lang as declared on 'schema' and 'documentation' below </xs:documentation> </xs:annotation> </xs:import> <xs:complexType name="openAttrs"> <xs:annotation> <xs:documentation> This type is extended by almost all schema types to allow attributes from other namespaces to be added to user schemas. </xs:documentation> </xs:annotation> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="annotated"> <xs:annotation> <xs:documentation> This type is extended by all types which allow annotation other than <schema> itself </xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="xs:openAttrs"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="id" type="xs:ID"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:group name="schemaTop"> <xs:annotation> <xs:documentation> This group is for the elements which occur freely at the top level of schemas. All of their types are based on the "annotated" type by extension.</xs:documentation> </xs:annotation> <xs:choice> <xs:group ref="xs:redefinable"/> <xs:element ref="xs:element"/> <xs:element ref="xs:attribute"/> <xs:element ref="xs:notation"/> </xs:choice> </xs:group> <xs:group name="redefinable"> <xs:annotation> <xs:documentation> This group is for the elements which can self-redefine (see <redefine> below).</xs:documentation> </xs:annotation> <xs:choice> <xs:element ref="xs:simpleType"/> <xs:element ref="xs:complexType"/> <xs:element ref="xs:group"/> <xs:element ref="xs:attributeGroup"/> </xs:choice> </xs:group> <xs:simpleType name="formChoice"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="qualified"/> <xs:enumeration value="unqualified"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="reducedDerivationControl"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:derivationControl"> <xs:enumeration value="extension"/> <xs:enumeration value="restriction"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="derivationSet"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> <xs:documentation> #all or (possibly empty) subset of {extension, restriction}</xs:documentation> </xs:annotation> <xs:union> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#all"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:list itemType="xs:reducedDerivationControl"/> </xs:simpleType> </xs:union> </xs:simpleType> <xs:simpleType name="typeDerivationControl"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:derivationControl"> <xs:enumeration value="extension"/> <xs:enumeration value="restriction"/> <xs:enumeration value="list"/> <xs:enumeration value="union"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="fullDerivationSet"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> <xs:documentation> #all or (possibly empty) subset of {extension, restriction, list, union}</xs:documentation> </xs:annotation> <xs:union> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#all"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:list itemType="xs:typeDerivationControl"/> </xs:simpleType> </xs:union> </xs:simpleType> <xs:element name="schema" id="schema"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-schema"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:openAttrs"> <xs:sequence> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="xs:include"/> <xs:element ref="xs:import"/> <xs:element ref="xs:redefine"/> <xs:element ref="xs:annotation"/> </xs:choice> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:group ref="xs:schemaTop"/> <xs:element ref="xs:annotation" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:sequence> <xs:attribute name="targetNamespace" type="xs:anyURI"/> <xs:attribute name="version" type="xs:token"/> <xs:attribute name="finalDefault" type="xs:fullDerivationSet" default="" use="optional"/> <xs:attribute name="blockDefault" type="xs:blockSet" default="" use="optional"/> <xs:attribute name="attributeFormDefault" type="xs:formChoice" default="unqualified" use="optional"/> <xs:attribute name="elementFormDefault" type="xs:formChoice" default="unqualified" use="optional"/> <xs:attribute name="id" type="xs:ID"/> <xs:attribute ref="xml:lang"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:key name="element"> <xs:selector xpath="xs:element"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="attribute"> <xs:selector xpath="xs:attribute"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="type"> <xs:selector xpath="xs:complexType|xs:simpleType"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="group"> <xs:selector xpath="xs:group"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="attributeGroup"> <xs:selector xpath="xs:attributeGroup"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="notation"> <xs:selector xpath="xs:notation"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="identityConstraint"> <xs:selector xpath=".//xs:key|.//xs:unique|.//xs:keyref"/> <xs:field xpath="@name"/> </xs:key> </xs:element> <xs:simpleType name="allNNI"> <xs:annotation> <xs:documentation> for maxOccurs</xs:documentation> </xs:annotation> <xs:union memberTypes="xs:nonNegativeInteger"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="unbounded"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> <xs:attributeGroup name="occurs"> <xs:annotation> <xs:documentation> for all particles</xs:documentation> </xs:annotation> <xs:attribute name="minOccurs" type="xs:nonNegativeInteger" default="1" use="optional"/> <xs:attribute name="maxOccurs" type="xs:allNNI" default="1" use="optional"/> </xs:attributeGroup> <xs:attributeGroup name="defRef"> <xs:annotation> <xs:documentation> for element, group and attributeGroup, which both define and reference</xs:documentation> </xs:annotation> <xs:attribute name="name" type="xs:NCName"/> <xs:attribute name="ref" type="xs:QName"/> </xs:attributeGroup> <xs:group name="typeDefParticle"> <xs:annotation> <xs:documentation> 'complexType' uses this</xs:documentation> </xs:annotation> <xs:choice> <xs:element name="group" type="xs:groupRef"/> <xs:element ref="xs:all"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> </xs:choice> </xs:group> <xs:group name="nestedParticle"> <xs:choice> <xs:element name="element" type="xs:localElement"/> <xs:element name="group" type="xs:groupRef"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> <xs:element ref="xs:any"/> </xs:choice> </xs:group> <xs:group name="particle"> <xs:choice> <xs:element name="element" type="xs:localElement"/> <xs:element name="group" type="xs:groupRef"/> <xs:element ref="xs:all"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> <xs:element ref="xs:any"/> </xs:choice> </xs:group> <xs:complexType name="attribute"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:element name="simpleType" type="xs:localSimpleType" minOccurs="0"/> </xs:sequence> <xs:attributeGroup ref="xs:defRef"/> <xs:attribute name="type" type="xs:QName"/> <xs:attribute name="use" default="optional" use="optional"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="prohibited"/> <xs:enumeration value="optional"/> <xs:enumeration value="required"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="default" type="xs:string"/> <xs:attribute name="fixed" type="xs:string"/> <xs:attribute name="form" type="xs:formChoice"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="topLevelAttribute"> <xs:complexContent> <xs:restriction base="xs:attribute"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:element name="simpleType" type="xs:localSimpleType" minOccurs="0"/> </xs:sequence> <xs:attribute name="ref" use="prohibited"/> <xs:attribute name="form" use="prohibited"/> <xs:attribute name="use" use="prohibited"/> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:group name="attrDecls"> <xs:sequence> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="attribute" type="xs:attribute"/> <xs:element name="attributeGroup" type="xs:attributeGroupRef"/> </xs:choice> <xs:element ref="xs:anyAttribute" minOccurs="0"/> </xs:sequence> </xs:group> <xs:element name="anyAttribute" type="xs:wildcard" id="anyAttribute"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-anyAttribute"/> </xs:annotation> </xs:element> <xs:group name="complexTypeModel"> <xs:choice> <xs:element ref="xs:simpleContent"/> <xs:element ref="xs:complexContent"/> <xs:sequence> <xs:annotation> <xs:documentation> This branch is short for <complexContent> <restriction base="xs:anyType"> ... </restriction> </complexContent></xs:documentation> </xs:annotation> <xs:group ref="xs:typeDefParticle" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> </xs:sequence> </xs:choice> </xs:group> <xs:complexType name="complexType" abstract="true"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:group ref="xs:complexTypeModel"/> <xs:attribute name="name" type="xs:NCName"> <xs:annotation> <xs:documentation> Will be restricted to required or forbidden</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="mixed" type="xs:boolean" default="false" use="optional"> <xs:annotation> <xs:documentation> Not allowed if simpleContent child is chosen. May be overriden by setting on complexContent child.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="abstract" type="xs:boolean" default="false" use="optional"/> <xs:attribute name="final" type="xs:derivationSet"/> <xs:attribute name="block" type="xs:derivationSet"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="topLevelComplexType"> <xs:complexContent> <xs:restriction base="xs:complexType"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:complexTypeModel"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="localComplexType"> <xs:complexContent> <xs:restriction base="xs:complexType"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:complexTypeModel"/> </xs:sequence> <xs:attribute name="name" use="prohibited"/> <xs:attribute name="abstract" use="prohibited"/> <xs:attribute name="final" use="prohibited"/> <xs:attribute name="block" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="restrictionType"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:choice minOccurs="0"> <xs:group ref="xs:typeDefParticle"/> <xs:group ref="xs:simpleRestrictionModel"/> </xs:choice> <xs:group ref="xs:attrDecls"/> </xs:sequence> <xs:attribute name="base" type="xs:QName" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="complexRestrictionType"> <xs:complexContent> <xs:restriction base="xs:restrictionType"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:annotation> <xs:documentation>This choice is added simply to make this a valid restriction per the REC</xs:documentation> </xs:annotation> <xs:group ref="xs:typeDefParticle"/> </xs:choice> <xs:group ref="xs:attrDecls"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="extensionType"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:group ref="xs:typeDefParticle" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> </xs:sequence> <xs:attribute name="base" type="xs:QName" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="complexContent" id="complexContent"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-complexContent"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:choice> <xs:element name="restriction" type="xs:complexRestrictionType"/> <xs:element name="extension" type="xs:extensionType"/> </xs:choice> <xs:attribute name="mixed" type="xs:boolean"> <xs:annotation> <xs:documentation> Overrides any setting on complexType parent.</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:complexType name="simpleRestrictionType"> <xs:complexContent> <xs:restriction base="xs:restrictionType"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:annotation> <xs:documentation>This choice is added simply to make this a valid restriction per the REC</xs:documentation> </xs:annotation> <xs:group ref="xs:simpleRestrictionModel"/> </xs:choice> <xs:group ref="xs:attrDecls"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="simpleExtensionType"> <xs:complexContent> <xs:restriction base="xs:extensionType"> <xs:sequence> <xs:annotation> <xs:documentation> No typeDefParticle group reference</xs:documentation> </xs:annotation> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="simpleContent" id="simpleContent"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-simpleContent"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:choice> <xs:element name="restriction" type="xs:simpleRestrictionType"/> <xs:element name="extension" type="xs:simpleExtensionType"/> </xs:choice> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="complexType" type="xs:topLevelComplexType" id="complexType"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-complexType"/> </xs:annotation> </xs:element> <xs:simpleType name="blockSet"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> <xs:documentation> #all or (possibly empty) subset of {substitution, extension, restriction}</xs:documentation> </xs:annotation> <xs:union> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#all"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:list> <xs:simpleType> <xs:restriction base="xs:derivationControl"> <xs:enumeration value="extension"/> <xs:enumeration value="restriction"/> <xs:enumeration value="substitution"/> </xs:restriction> </xs:simpleType> </xs:list> </xs:simpleType> </xs:union> </xs:simpleType> <xs:complexType name="element" abstract="true"> <xs:annotation> <xs:documentation> The element element can be used either at the top level to define an element-type binding globally, or within a content model to either reference a globally-defined element or type or declare an element-type binding locally. The ref form is not allowed at the top level.</xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:choice minOccurs="0"> <xs:element name="simpleType" type="xs:localSimpleType"/> <xs:element name="complexType" type="xs:localComplexType"/> </xs:choice> <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attributeGroup ref="xs:defRef"/> <xs:attribute name="type" type="xs:QName"/> <xs:attribute name="substitutionGroup" type="xs:QName"/> <xs:attributeGroup ref="xs:occurs"/> <xs:attribute name="default" type="xs:string"/> <xs:attribute name="fixed" type="xs:string"/> <xs:attribute name="nillable" type="xs:boolean" default="false" use="optional"/> <xs:attribute name="abstract" type="xs:boolean" default="false" use="optional"/> <xs:attribute name="final" type="xs:derivationSet"/> <xs:attribute name="block" type="xs:blockSet"/> <xs:attribute name="form" type="xs:formChoice"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="topLevelElement"> <xs:complexContent> <xs:restriction base="xs:element"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:element name="simpleType" type="xs:localSimpleType"/> <xs:element name="complexType" type="xs:localComplexType"/> </xs:choice> <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="ref" use="prohibited"/> <xs:attribute name="form" use="prohibited"/> <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="localElement"> <xs:complexContent> <xs:restriction base="xs:element"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:element name="simpleType" type="xs:localSimpleType"/> <xs:element name="complexType" type="xs:localComplexType"/> </xs:choice> <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="substitutionGroup" use="prohibited"/> <xs:attribute name="final" use="prohibited"/> <xs:attribute name="abstract" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="element" type="xs:topLevelElement" id="element"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-element"/> </xs:annotation> </xs:element> <xs:complexType name="group" abstract="true"> <xs:annotation> <xs:documentation> group type for explicit groups, named top-level groups and group references</xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:group ref="xs:particle" minOccurs="0" maxOccurs="unbounded"/> <xs:attributeGroup ref="xs:defRef"/> <xs:attributeGroup ref="xs:occurs"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="realGroup"> <xs:complexContent> <xs:restriction base="xs:group"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0" maxOccurs="1"> <xs:element ref="xs:all"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> </xs:choice> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="namedGroup"> <xs:complexContent> <xs:restriction base="xs:realGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="1" maxOccurs="1"> <xs:element name="all"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:all"> <xs:group ref="xs:allModel"/> <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="choice" type="xs:simpleExplicitGroup"/> <xs:element name="sequence" type="xs:simpleExplicitGroup"/> </xs:choice> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:attribute name="ref" use="prohibited"/> <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="groupRef"> <xs:complexContent> <xs:restriction base="xs:realGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="ref" type="xs:QName" use="required"/> <xs:attribute name="name" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="explicitGroup"> <xs:annotation> <xs:documentation> group type for the three kinds of group</xs:documentation> </xs:annotation> <xs:complexContent> <xs:restriction base="xs:group"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:nestedParticle" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="prohibited"/> <xs:attribute name="ref" type="xs:QName" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="simpleExplicitGroup"> <xs:complexContent> <xs:restriction base="xs:explicitGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:nestedParticle" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:group name="allModel"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>This choice with min/max is here to avoid a pblm with the Elt:All/Choice/Seq Particle derivation constraint</xs:documentation> </xs:annotation> <xs:element name="element" type="xs:narrowMaxMin"/> </xs:choice> </xs:sequence> </xs:group> <xs:complexType name="narrowMaxMin"> <xs:annotation> <xs:documentation>restricted max/min</xs:documentation> </xs:annotation> <xs:complexContent> <xs:restriction base="xs:localElement"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:choice minOccurs="0"> <xs:element name="simpleType" type="xs:localSimpleType"/> <xs:element name="complexType" type="xs:localComplexType"/> </xs:choice> <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="minOccurs" default="1" use="optional"> <xs:simpleType> <xs:restriction base="xs:nonNegativeInteger"> <xs:enumeration value="0"/> <xs:enumeration value="1"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="maxOccurs" default="1" use="optional"> <xs:simpleType> <xs:restriction base="xs:allNNI"> <xs:enumeration value="0"/> <xs:enumeration value="1"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="all"> <xs:annotation> <xs:documentation> Only elements allowed inside</xs:documentation> </xs:annotation> <xs:complexContent> <xs:restriction base="xs:explicitGroup"> <xs:group ref="xs:allModel"/> <xs:attribute name="minOccurs" default="1" use="optional"> <xs:simpleType> <xs:restriction base="xs:nonNegativeInteger"> <xs:enumeration value="0"/> <xs:enumeration value="1"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="maxOccurs" default="1" use="optional"> <xs:simpleType> <xs:restriction base="xs:allNNI"> <xs:enumeration value="1"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="all" type="xs:all" id="all"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-all"/> </xs:annotation> </xs:element> <xs:element name="choice" type="xs:explicitGroup" id="choice"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-choice"/> </xs:annotation> </xs:element> <xs:element name="sequence" type="xs:explicitGroup" id="sequence"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-sequence"/> </xs:annotation> </xs:element> <xs:element name="group" type="xs:namedGroup" id="group"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-group"/> </xs:annotation> </xs:element> <xs:complexType name="wildcard"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="namespace" type="xs:namespaceList" default="##any" use="optional"/> <xs:attribute name="processContents" default="strict" use="optional"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="skip"/> <xs:enumeration value="lax"/> <xs:enumeration value="strict"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="any" id="any"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-any"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:wildcard"> <xs:attributeGroup ref="xs:occurs"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:annotation> <xs:documentation> simple type for the value of the 'namespace' attr of 'any' and 'anyAttribute'</xs:documentation> </xs:annotation> <xs:annotation> <xs:documentation> Value is ##any - - any non-conflicting WFXML/attribute at all ##other - - any non-conflicting WFXML/attribute from namespace other than targetNS ##local - - any unqualified non-conflicting WFXML/attribute one or - - any non-conflicting WFXML/attribute from more URI the listed namespaces references (space separated) ##targetNamespace or ##local may appear in the above list, to refer to the targetNamespace of the enclosing schema or an absent targetNamespace respectively</xs:documentation> </xs:annotation> <xs:simpleType name="namespaceList"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> </xs:annotation> <xs:union> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="##any"/> <xs:enumeration value="##other"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:list> <xs:simpleType> <xs:union memberTypes="xs:anyURI"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="##targetNamespace"/> <xs:enumeration value="##local"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> </xs:list> </xs:simpleType> </xs:union> </xs:simpleType> <xs:element name="attribute" type="xs:topLevelAttribute" id="attribute"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-attribute"/> </xs:annotation> </xs:element> <xs:complexType name="attributeGroup" abstract="true"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:group ref="xs:attrDecls"/> <xs:attributeGroup ref="xs:defRef"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="namedAttributeGroup"> <xs:complexContent> <xs:restriction base="xs:attributeGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> <xs:group ref="xs:attrDecls"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:attribute name="ref" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="attributeGroupRef"> <xs:complexContent> <xs:restriction base="xs:attributeGroup"> <xs:sequence> <xs:element ref="xs:annotation" minOccurs="0"/> </xs:sequence> <xs:attribute name="ref" type="xs:QName" use="required"/> <xs:attribute name="name" use="prohibited"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="attributeGroup" type="xs:namedAttributeGroup" id="attributeGroup"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-attributeGroup"/> </xs:annotation> </xs:element> <xs:element name="include" id="include"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-include"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="redefine" id="redefine"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-redefine"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:openAttrs"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="xs:annotation"/> <xs:group ref="xs:redefinable"/> </xs:choice> <xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/> <xs:attribute name="id" type="xs:ID"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="import" id="import"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-import"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="namespace" type="xs:anyURI"/> <xs:attribute name="schemaLocation" type="xs:anyURI"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="selector" id="selector"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-selector"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="xpath" use="required"> <xs:simpleType> <xs:annotation> <xs:documentation>A subset of XPath expressions for use in selectors</xs:documentation> <xs:documentation>A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:annotation> <xs:documentation>The following pattern is intended to allow XPath expressions per the following EBNF: Selector ::= Path ( '|' Path )* Path ::= ('.//')? Step ( '/' Step )* Step ::= '.' | NameTest NameTest ::= QName | '*' | NCName ':' '*' child:: is also allowed </xs:documentation> </xs:annotation> <xs:pattern value="(\.//)?(((child::)?((\i\c*:)?(\i\c*|\*)))|\.)(/(((child::)?((\i\c*:)?(\i\c*|\*)))|\.))*(\|(\.//)?(((child::)?((\i\c*:)?(\i\c*|\*)))|\.)(/(((child::)?((\i\c*:)?(\i\c*|\*)))|\.))*)*"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="field" id="field"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-field"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="xpath" use="required"> <xs:simpleType> <xs:annotation> <xs:documentation>A subset of XPath expressions for use in fields</xs:documentation> <xs:documentation>A utility type, not for public use</xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:annotation> <xs:documentation>The following pattern is intended to allow XPath expressions per the same EBNF as for selector, with the following change: Path ::= ('.//')? ( Step '/' )* ( Step | '@' NameTest ) </xs:documentation> </xs:annotation> <xs:pattern value="(\.//)?((((child::)?((\i\c*:)?(\i\c*|\*)))|\.)/)*((((child::)?((\i\c*:)?(\i\c*|\*)))|\.)|((attribute::|@)((\i\c*:)?(\i\c*|\*))))(\|(\.//)?((((child::)?((\i\c*:)?(\i\c*|\*)))|\.)/)*((((child::)?((\i\c*:)?(\i\c*|\*)))|\.)|((attribute::|@)((\i\c*:)?(\i\c*|\*)))))*"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:complexType name="keybase"> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:sequence> <xs:element ref="xs:selector"/> <xs:element ref="xs:field" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:group name="identityConstraint"> <xs:annotation> <xs:documentation>The three kinds of identity constraints, all with type of or derived from 'keybase'. </xs:documentation> </xs:annotation> <xs:choice> <xs:element ref="xs:unique"/> <xs:element ref="xs:key"/> <xs:element ref="xs:keyref"/> </xs:choice> </xs:group> <xs:element name="unique" type="xs:keybase" id="unique"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-unique"/> </xs:annotation> </xs:element> <xs:element name="key" type="xs:keybase" id="key"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-key"/> </xs:annotation> </xs:element> <xs:element name="keyref" id="keyref"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-keyref"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:keybase"> <xs:attribute name="refer" type="xs:QName" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="notation" id="notation"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-notation"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:annotated"> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:attribute name="public" type="xs:public"/> <xs:attribute name="system" type="xs:anyURI"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:simpleType name="public"> <xs:annotation> <xs:documentation> A utility type, not for public use</xs:documentation> <xs:documentation> A public identifier, per ISO 8879</xs:documentation> </xs:annotation> <xs:restriction base="xs:token"/> </xs:simpleType> <xs:element name="appinfo" id="appinfo"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-appinfo"/> </xs:annotation> <xs:complexType mixed="true"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:any processContents="lax"/> </xs:sequence> <xs:attribute name="source" type="xs:anyURI"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="documentation" id="documentation"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-documentation"/> </xs:annotation> <xs:complexType mixed="true"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:any processContents="lax"/> </xs:sequence> <xs:attribute name="source" type="xs:anyURI"/> <xs:attribute ref="xml:lang"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="annotation" id="annotation"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/2006/WD-xmlschema11-1-20060330/structures.html#element-annotation"/> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xs:openAttrs"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="xs:appinfo"/> <xs:element ref="xs:documentation"/> </xs:choice> <xs:attribute name="id" type="xs:ID"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:annotation> <xs:documentation> notations for use within XML Schema schemas</xs:documentation> </xs:annotation> <xs:notation name="XMLSchemaStructures" public="structures" system="http://www.w3.org/2000/08/XMLSchema.xsd"/> <xs:notation name="XML" public="REC-xml-19980210" system="http://www.w3.org/TR/1998/REC-xml-19980210"/> <xs:complexType name="anyType" mixed="true"> <xs:annotation> <xs:documentation> Not the real urType, but as close an approximation as we can get in the XML representation</xs:documentation> </xs:annotation> <xs:sequence> <xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax"/> </xs:sequence> <xs:anyAttribute processContents="lax"/> </xs:complexType> </xs:schema>
To facilitate consistent reporting of schema errors and ·validation·
failures, this section tabulates and provides unique names for all the
constraints listed in this document. Wherever such constraints have numbered
parts, reports must use the name given below plus the part number, separated
by a period ('.'). Thus for example cos-ct-extends.1.2
must be
used to report a violation of the clause 1.2 of
Derivation Valid (Extension) (§3.4.6).
Issue (RQ-137i):RQ-137 (error-codes)The promise that each error and failure defined in this spec. would have a distinct identifier was not systematically delivered on in version 1.0. Version 1.1 will do better.Resolution:
Add markup and/or an operational definition to support the generation of an appropriate error code for any schema error or validation failure specified outside a named constraint or rule, e.g. uses of must and, in particular, phrases such as "it is an error" in Errors in Schema Construction and Structure (§5.1).
This section defines some terms for use in describing choices made by implementations in areas where the effect of XML Schema language features is explicitly implementation-defined.
Future versions of this specification are expected to use the terminology defined here to specify conformance profiles. Conformance profiles may also be defined by other specifications without requiring any revision to this specification.
This specification defines a number of ways in which the information set taken as input is augmented in the course of schema-validity assessment. Conforming processors may provide access to some or all of this information; in the interests of simplifying discussion and documentation, this section defines names for several subsets of the PSVI, with the intention of simplifying short-hand descriptions of processors. These terms may be used to describe what parts of the PSVI a particular schema processor provides access to, or to specify requirements for processors, or for other purposes. A processor provides access to a particular subset of the PSVI if and only if it makes accessible some representation of the information in question, for information items to which it is applicable. (The properties labeled "if applicable" or "where applicable" below are simply the most obvious cases of properties which do not apply to every information item; the same qualification implicitly applies to all properties listed below.)
If other subsets of the PSVI prove important in practice it is expected that definitions of those subsets may be provided by other specifications or in later revisions of this one.
The definition in this section of a term denoting a particular subset of the PSVI does not constitute a requirement that conforming processors provide access to that subset.
Conforming processors may implement any combination of the following strategies for locating schema components, in any order. They may also implement other strategies.
The terminology offered here is intended to be useful in discussions of processor behavior, whether documenting existing behavior or describing required behavior.
Some terms describe how a processor identifies locations from which schema components can be sought:
rddl:resource
elements with the well-known property xlink:role
= "http://www.w3.org/2001/XMLSchema
"
and the processor attempts
to dereference the location(s) indicated on the
xlink:href
attribute of the link.
Some terms describe various methods of indirection through local catalogs, search paths, or local repositories of schema documents and/or schema components. In each of these, a ‘search key’ is assumed which helps to control the indirection. Terms for different sorts of search key are defined below.
Locating schema components by means of any of the ‘indirect’ methods just identified will sometimes involve the specification of a value of some kind as a search key. Processors may vary in their choice of values to use as the key:
When more than one location is available for a given namespace, two distinct behaviors can be distinguished; these are orthogonal to other terms defined here:
General-purpose processors should support multiple methods for locatin