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

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 ↓XML Schema: Structures↓↑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 ↓may↓↑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 ↓XML Schema: Structures↓ formalism ↑defined here↑ to express syntactic, structural and value constraints applicable to its document instances. The ↓XML Schema: Structures↓↑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 ↓any application↓↑ applications↑. Some applications ↓may↓↑will↑ require constraint capabilities not expressible in this language, and so ↓may↓↑will↑ need to perform their own additional validations.

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],↓ ↑[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.

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 ↓may determine↓↑determines↑ which of several different components ↓may arise↓↑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:

↓Following [XML 1.1], w↓↑W↑ithin normative prose in this specification, the words may↓ and↓↑, should↑↑,↑ must↑ and must not↑ are defined as follows:

↓Note however that this↓↑This↑ specification provides a definition of error and of conformant processors' responsibilities with respect to errors ↓(see↓↑in↑ Schemas and Schema-validity Assessment (§5)↓) which is considerably more complex than that of [XML 1.1]↓.

2.1 Overview of ↓XML Schema↓↑XSDL↑

An ↓XML Schema↓↑XSDL 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↓↑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 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 ↓XML Schema↓↑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, ↓XML Schemas↓↑XSDL schemas↑ can be described in terms of an abstract data model. In defining ↓XML Schemas↓↑schemas↑ in terms of an abstract data model, this specification rigorously specifies the information which must be available to a conforming ↓XML Schema↓↑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 ↓comprise↓↑make up↑ the abstract data model of the schema. ↓[Definition:]   An XML Schema is a set of ·schema components·↓↑[Definition:]   An XSDL schema is a set of ·schema components·↑. There are ↓13↓↑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, ↓which must have names, ↓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↓↑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↓↑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 ↓may ·validate·↓↑is ·validated·↑ 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·.

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