W3C XML Schema Definition Language (XSDL) 1.1 Part 1: Structures

1.1 Introduction to Version 1.1

The Working Group has three main goals for this version of W3C XML Schema:

• Significant improvements in simplicity of design and clarity of exposition without loss of backward or forward compatibility;
• Provision of support for versioning of XML languages defined using this specification, including the XML transfer syntax for schemas itself.
• Provision of support for co-occurrence constraints, that is constraints which make the presence of an attribute or element, or the values allowable for it, depend on the value or presence of other attributes or elements.

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:

1. Support for versioning (acknowledging that this may be slightly disruptive to the XML transfer syntax at the margins)
2. Support for co-occurrence constraints (which will certainly involve additions to the XML transfer syntax, which will not be understood by 1.0 processors)
3. Bug fixes (unless in specific cases we decide that the fix is too disruptive for a point release)
4. Editorial changes
5. Design cleanup will possibly change behavior in edge cases
6. Non-disruptive changes to type hierarchy (to better support current and forthcoming international standards and W3C recommendations)
7. Design cleanup will possibly change component structure (changes to functionality restricted to edge cases)
8. No significant changes in existing functionality
9. No changes to XML transfer syntax except those required by version control hooks, co-occurrence constraints and bug fixes

The aim with regard to compatibility is that

• All schema documents conformant to version 1.0 of this specification should also conform to version 1.1, and should have the same validation behavior across 1.0 and 1.1 implementations (except possibly in edge cases and in the details of the resulting PSVI);
• The vast majority of schema documents conformant to version 1.1 of this specification should also conform to version 1.0, leaving aside any incompatibilities arising from support for versioning or co-occurrence constraints, and when they are conformant to version 1.0 (or are made conformant by the removal of versioning information), should have the same validation behavior across 1.0 and 1.1 implementations (again except possibly in edge cases and in the details of the resulting PSVI);

1.2 Purpose

The purpose of XML Schema Definition Language: Structures is to define the nature of !! 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 XSDL 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 can 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 Definition Language: 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 formalism defined here to express syntactic, structural and value constraints applicable to its document instances. The XSDL 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 applications. Some applications will require constraint capabilities not expressible in this language, and so will need to perform their own additional validations.

1.3 Namespaces and Language Identifiers

1.4 Dependencies on Other Specifications

The definition of XML Schema Definition Language: Structures depends on the following specifications: [XML-Infoset], [XML-Namespaces 1.1], [XPath 2.0], 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.

1.5 Documentation Conventions and Terminology

The section introduces the highlighting and typography as used in this document to present technical material.

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 determines which of several different components corresponds to the source declaration, 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.

References 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).

2.1 Overview of XSDL

An XSDL schema 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 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 some or all of the PSVI, as described in Subset of the Post-schema-validation Infoset (§D.1). The mechanisms by which processors provide such access to the PSVI are neither defined nor constrained by this specification.

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.

2.2 XSDL Abstract Data Model

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, XSDL schemas can be described in terms of an abstract data model. In defining schemas in terms of an abstract data model, this specification rigorously specifies the information which must be available to a conforming XSDL 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 make up the abstract data model of the schema. [Definition:]   An XSDL schema is a set of ·schema components·. There are 14 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:

• Simple type definitions
• Complex type definitions
• Attribute declarations
• Element declarations

The secondary components, are as follows:

• Attribute group definitions
• Identity-constraint definitions
• Type alternatives
• Assertions
• Model group definitions
• Notation declarations

Finally, the "helper" components provide small parts of other components; they are not independent of their context:

• Annotations
• Model groups
• Particles
• Wildcards
• Attribute Uses

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 will ·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 is ·validated· with respect to an attribute declaration, a list of element information items 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·.

<!ELEMENT A . . .>
<!ATTLIST A . . .>

2.3 Constraints and Validation Rules

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.

2.4 Conformance

Within the context of this specification, conformance can be claimed for schema documents and for XSDL-aware processors.

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 be schema-document aware. Such processors must, when processing schema documents, completely and correctly implement (or enforce) 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:]  Web-aware processors are network-enabled processors which are not only both ·minimally conforming· and ·schema-document aware·, but which additionally must be capable of accessing schema documents from the World Wide Web 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.

2.5 Names and Symbol Spaces

As discussed in XSDL 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. There is a single distinct symbol space within a given ·target namespace· for each kind of definition and declaration component identified in XSDL 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.

2.6 Schema-Related Markup in Documents Being Validated

XML Schema Definition Language: Structures defines several attributes for direct use in any XML documents. These attributes are in the schema instance namespace (http://www.w3.org/2001/XMLSchema-instance) described in The Schema Instance Namespace (xsi) (§1.3.1.2) above. 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).