This Working Draft document was produced using an DTD and an stylesheet.

The following highlighting is used to present technical material in this document:

A term is something we use a lot.

The following highlighting is used for non-normative commentary in this document:

The purpose of &XSP1; is to provide an inventory of XML markup constructs with which to write schemas.

The purpose of an &XSP1; schema is to define and describe a class of XML documents by using these constructs to constrain and document the meaning, usage and relationships of their constituent parts: datatypes, elements and their content, attributes and their values. Schema constructs may also provide for the specification of additional information such as default values. Schemas are intended to document their own meaning, usage, and function through a common documentation vocabulary. Thus, &XSP1; 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 &XSP1; formalism to express syntactic, structural and value constraints applicable to its document instances. The &XSP1; formalism will allow a useful level of constraint checking to be described and validated 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 &XSP1; is a part of the W3C XML Activity. It is in various ways related to other ongoing parts of that Activity and other W3C WGs

The terminology used to describe &XSP1; is defined in the body of this specification. The terms defined in the following list are used in building those definitions and in describing the actions of &XSP1; processors:

Since XML schemas are themselves specified as XML documents or elements within documents, it is useful to clarify the relationships between certain kinds of XML documents and elements:

Note that it is possible to specify a schema to which schemas themselves must conform, and this is given in . An XML 1.0 DTD to which schemas must conform is also provided in .

The 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.

Three kinds of normative statements about the impact of &XSP1; components on instances are distinguished in this specification:

&XSP1; not only reconstructs the DTD constraints of XML 1.0 using XML instance syntax, it also adds the ability to define new kinds of constraints. For example, although the author of an XML 1.0 DTD may declare an element type as containing character data, elements, or mixed content, there is no mechanism with which to constrain the contents of elements to only character data of a particular form, such as only numeral sequences representing integers in a specified range.

This specification supports the expression of just such constraints by including in the mechanism for the declaration of elements the option of specifying that its contents must consist of a valid string expression of a particular datatype. A number of other mechanisms are added which improve the expressive power, usability and maintainability of schemas as a means to defining the structure of XML documents.

The purpose of a schema is to identify a set of components for use in XML documents and to provide the rules for their correct combination.

The schema language itself defines an XML form for itself in terms of elements and attributes. We will describe these, and show how they are used. But first, a quick example of an XML document.

The purchase order consists of a main element with several subordinate elements. Most of the subelements have simple atomic types such as string or date, drawn from the repertoire of built-in simple types defined in , but some are complex. We use the type element when declaring elements which allow elements in their content and/or may carry attributes. For example, we can define a type called Address as follows:

If we're going to use the same element in a number of places, we can declare it once and refer to it by name elsewhere:

We can define a PurchaseOrderType for our PurchaseOrder element, referring to the definitions of Address and comment as above, as:

Since an element declaration's type can identify either a simple or a complex type, and there are separate symbol spaces for these two, the possibility of ambiguity arises. This is resolved in favour of the complex type, e.g. even if a simple type called Address existed (either builtin or user-defined), the above declaration for shipTo would refer to the user-defined complex type of that name.

A definition creates a new type; a declaration enables the appearance in a document instance of an element or attribute with a specific name and type. In the schema, we see both the definition of several types, and also several elements and attributes declared as usages of these types. For example, Address is defined to be a type, while within the definition of Address we see five declarations of elements and one attribute declaration. These declarations are not themselves types, but rather an association between a name and constraints which govern the appearance of that name in documents governed by the containing schema.

In the case of attribute declarations, the constraints are on the allowed value, always by reference to a simple type:

In the case of element declarations, the constraints are on the allowed content and attributes, by reference to a complex or a simple type (in which case no attributes are allowed):

As well as naming a type in an attribute or element declaration, we can embed the type definition immediately within the element declaration:

Taken together the examples above constitute a complete schema for the initial PurchaseOrder example instance. They are drawn together in a single complete schema in .

Schemas are composed of: schema components: a set of type definitions, attribute group definitions, model group definitions, element declarations, and attribute declarations. Note that it is the abstract idea of a component we are talking about here, along with its name: an XML element such as <element> is a standardized representation for a component, not the component itself.

The next chapter sets out the &XSP1; approach to schemas, with formal definitions of their component parts and presentations of standardized representations for each of them. Here we informally summarize the key constructs used in defining schemas. A 'Yes' in the 'Name appears in instances?' column indicates that the name will appear in instances -- other names are for schema use only.

As indicated in the third column of the tables above, most of the components listed have names, which provide for references within the schema, and sometimes from one schema to another. For example, an attribute declaration can refer to a named type, such as 'integer'. A content model can refer to an element, and so on.

If all such names were assigned from the same 'pool', then it would be impossible to have e.g. a type named 'integer' and an element with the name 'integer' in the same schema. Accordingly we introduce the idea of a symbol space (avoiding 'name space' to avoid confusion with the term defined in ). A symbol space is similar to the non-normative concept of namespace partition introduced in .

There is a single distinct symbol space within a given schema for each of the abstractions named above other than 'Attribute' and 'element': within a given symbol space, names are unique, but the same name may appear in more than one symbol space without conflict. In particular note that the same name can refer to both a type and an element, without conflict or necessary relation between the two.

Attributes and local element declarations are special, in that every type defines its own attribute symbol space and local element symbol space, which are distinct from each other. In addition, top-level elements (whose declarations are not contained within a type definition) reside in their own symbol space.

The names of schema components such as type definitions and element declarations are not of type ID, as explained above: they are not unique within a schema, just within a symbol space. This means that simple fragment identifiers will not work to reference schema components.

In the long run we expect to provide some mechanism suitable for referencing the semantic components of schemas as such. In the mean time, we observe that provides a mechanism which maps well onto our notion of symbol spaces. An fragment identifier of the form #xpointer(schema/element[@name="person"]) will uniquely identify the element declaration with name person, and similar fragment identifiers can obviously be constructed for the other top-level symbol spaces.

Every element and attribute declaration is associated with a target namespace URI, or with no namespace. More specifically, each symbol space is associated directly (in the case of global declarations) or indirectly (in the case of local declarations) with a target namespace or with no namespace. So, the name of each global declaration is effectively qualified by the target namespace in which it is defined. Locally scoped element and attribute declarations are named in a symbol space defined by their containing type definition.

Global element and attribute declarations are used to validate instance document constructs in the namespace identified by the URI of the target namespace for the corresponding declaration. Declarations with a null target namespace validate non-namespace qualified instance document constructs.

&XSP1; is presented here primarily in the form of an abstract syntax, which provides a formal specification of the information provided for each declaration and definition in the schema language. The abstract syntax is presented using a simplified BNF. Defined terms are to the left. Their components are to the right, with a small amount of meta-syntax: ()s for grouping, | to separate alternatives, ? for optionality, * and + for iteration. Terms in italics are primitives, not expanded here, either because they are defined elsewhere (e.g. URI, defined by ) or because they can only be grounded once a concrete syntax is decided on (e.g. choice).

An abstract syntax production prefixed with a number in brackets (e.g. [3]) is normative; other abstract syntax is either for purposes of explanation, or is a duplicate (for convenience) of a normative definition to be found elsewhere.

The abstract syntax illustrates the expressive power of the language, and the relationships among its component parts. The abstract syntax can be used to evaluate the expressive power of &XSP1;, but not its look and feel. In particular, please note that neither ordering within or between productions or choice of names is significant, and that any particular concrete syntax is not constrained by these.

The concrete syntax of &XSP1;, the exact element and attribute names used in a schema, are a key feature of its proposed design. The concrete syntax is the form in which the schema language is used by schema authors. Though its elements and attributes are often different from the terms of the abstract syntax BNF, the features and expressive power of the two are congruent. The concrete syntax profoundly affects the convenience and usability of the schema language.

We include a preliminary concrete syntax in this draft, via examples, paradigms and in and . Unlike the previous version, in which the intention was to stay quite close to the abstract syntax, in this version we have begun to take convenience and clarity into account.

A schema contains some preamble information and a set of definitions and declarations.

preamble consists of an xmlSchemaRef specifying the URI for &XSP1;; the targetNamespace specifying the URI of the namespace which this schema is about; and a schemaVersion specification for private version documentation purposes and version management.

finalDefault and exactDefault provide defaults for final and exact respectively for type definitions and element declarations. The default for these properties is empty in both cases.

See for discussion of schemas, instances and namespaces, and also for import and include.

Although the schema above is 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 be derived from a (text) document at all: it could be built 'by hand' via e.g. a DOM-conformant API.

The schema's declarations and definitions, discussed in detail in , provide for the creation of new schema components:

The Constraint on Schemas obtains.

Uniform means are provided for reference to a broad variety of schema constructs, both within a single schema and to features imported () from external schemas. The name used to reference any component of &XSP1; from within a schema consists of a QName. In a few cases, some elaboration may be added to a reference: this is made clear as the individual reference forms are introduced below.

The abstract syntax above characterizes the reference mechanisms used in this specification.

The Constraint on Schemas obtains.

The identify definition wrt schema-validity obtains.

The Constraint on Schemas also obtains.

Like XML 1.0 DTDs, &XSP1; provides facilities for constraining the contents of elements and the values of attributes, and for augmenting the information set of instances, e.g. with defaulted values and type information. We call a set of SCs intended for use in this way a type definition.

We refer hereafter to the combination of schema constraints and information set contributions with the abbreviation SC. Compared to DTDs, &XSP1; provides for a richer set of SCs, and improved capabilities for sharing SCs across sets of elements and attributes.

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. At a given point in a content model, in addition to what DTDs provide for we need particles that allow the following:

Of course, by qualifying one of these with a *, we allow for any amount of (localized) flexibility in validation.

Attributes need the same kind of flexibility: a good-citizen schema should probably allow any attributes from the xml: namespace, for instance.

The four alternatives for wildcard correspond to the four kinds of flexibility listed above.

All of the above are subject to the same ambiguity constraints () 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.

This section articulates what has only been hinted at above, namely a considerable increase in the power and expressiveness of schema declarations, by explaining what was provided for in the abstract syntax in the previous section, but not explained much if at all at that point: the potential for deriving new type definitions on the basis of old ones. We call such a new definition a derived type definition, and the old definition it is derived from the source type definition.

We provide two means for deriving type definitions from other type definitions, each of which implies a partial order over the types defined in a schema: A type definition may either restrict or extend another type definition.

We supplement the simple uniqueness and reference mechanisms provided by ID and IDREF in XML 1.0 and SGML with three new kinds of constraint, for uniqueness, keys and key references.

The unique and key constraints provide for selected elements to be checked as having locally or globally unique identities. The keyref constraint provides for checking referential consistency with respect to a declared unique or key constraint.

These constraints are specified independently of the types of the attributes and elements involved, i.e. something declared as of type integer may also serve as a key, unlike ID and IDREF. Each constraint declaration has a name, which exists in a single symbol space for constraints.

Overall the augmentations to XML's ID/IDREF mechanism are:

selector specifies an XPath expression relative to instances of the element being declared, or to the root for generalConstraints declared at the top level. This must identify a node set of subelements (i.e. elements contained within the declared element) to which the constraint applies.

field specifies an XPath expression relative to each element selected by a selector. This must identify a single node (element or attribute, not necessarily within the selected element) 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, to cater to multi-field keys, keyrefs, and uniqueness constraints. A field must not evaluate to the same element or attribute as any other field in a given instance of a generalConstraint.

Provision for multi-field keys etc. goes beyond what is supported by xsl:key.

The refer of a keyref must match the constraintName of a unique or a key. The number of fields of the keyref must be the same as the number of fields of the referenced unique or key. For every element which is identified in a given scope by the selector of a keyref defined for that scope (call this ref), there must be an element in that scope identified by the selector of the named unique or key (call this target) such that the values of the fields of the keyref evaluated with respect to ref, taken in order, match the values of the fields of the unique or key evaluated with respect to target.

The fundamental purpose of the schema-validation core is to define schema-validatity for a single element information item and its descendants with respect to a specified type definition. All processors are required to implement this core predicate in a manner which conforms exactly to this specification.

Schema-validity is defined with reference to a complete component set which consists of (at a minimum) the set of schema components (definitions and declarations) required for that validation. This is not a circular definition, but rather a post facto observation: no element information item can be schema-valid unless all the components required by any aspect of its (potentially recursive) validation are present in the complete component set.

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 the complete component set.

Processors have the option to assemble ( and perhaps to optimize or pre-compile) the entire complete component set prior to the start of a validation episode, or to gather the complete component set lazily as individual components are required. In all cases it is required that:

The fundamental schema-valid predicate applies to an element information item (EII) and a type definition against the background of a set of schema components comprising a complete component set.

The obligation of a schema-aware processor as far as the schema-validation core is concerned is to implement the definition of schema-valid. The choice of EII, as well as the determination of the type definition and complete component set. is not specified at layer 1.

The schema-valid predicate is defined recursively, and e.g. streaming processors may implement it in a way that augments the complete component set during processing in response to encountering new namespaces. The implication of the invariants expressed above is that schema-valid must be implemented so that the same validation outcome is given in such cases as would be given if the initial invocation of schema-valid was re-performed with the final complete component set. replacing the one initially employed.

This is basically provided by chapter 3 of the current WD, which defines an XML syntax for defining types and declaring elements, specifying their target namespace and collecting them into schema definitions (i.e. XML documents). On the perspective argued for here, chapter 3 should be understood as doing two things: defining the requirements on an XML 1.0 document for it to qualify as a schema definition; specifying how the concrete syntax of that document (at the infoset level) maps on to type definitions and element declarations.

Layers 1 and 2 provide a framework for validation and XML definition of schemas in a broad variety of environments. Over time, we expect that a range of standards and conventions will 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.

We approach the definition of schema validity one step at a time. In the definitions below we deal primarily in terms of information sets, rather than the documents which give rise to them: see for definitions of XML information set and information item. Please note that the formal definitions below are explicitly not couched in processing terms: they describe properties of an information set, but do not tell you how to check an information set to see if it has those properties.

Schema-validity is first and foremost a property of element information items with respect to type definitions and schemas. This recommendation does not cover all aspects of how the type definitions and schemas are identified, but it does specify quite carefully what it means to be schema-valid once you've got them.

First we define our terms:

An EII is an element information item from an XML information set which conforms to with Namespace processing.

A TNS (for Target Namespace Set) is a set, possibly empty, of namespace names, all denoting the same namespace.

A schema is a set of named type definitions and element declarations, each associated with a TNS.

A type definition is a TNS and either a complex type definition as defined by the typeDefn production or a simple type definition as defined by the datatypeDefn production.

An EII is schema-valid with respect to a type definition and a set of schemas if and only if:

The type definition is simple and

The effective stype of a datatypeDefn with respect to a set of schemas is [TBFI].

A string is an instance of an effective stype if and only if [TBFI]

The effective ctype of a typeDefn with respect to a set of schemas is [TBFI]. We refer to the set of all attribute declarations in an effective ctype as its attribute set. We refer to the simple type or content model in an effective ctype as its content type

A sequence of element and information items is an instance of an effective ctype's content type with respect to a TNS and a set of schemas if and only if [TBFI]

First we have to get to the schema(s) involved. This is slightly tricky, as not all namespace declarations will resolve to schemas, and not everything that purports to be a schema will be one.

A URI is said to nominate a schema if it resolves to an element item in the information set of a well-formed XML 1.0 document whose local name is schema and whose namespace item's URI identifies either

this specification or one of its successors,

A URI is said to resolve successfully to a schema if it nominates a schema, and the element item it resolves to represents an XML schema, that is:

If it were the document element item of an information set corresponding to an XML document whose DOCTYPE identified the XML Schema 1.0 DTD (or the equivalent DTD from a successor to this specification) as its DTD, that document would be valid per XML 1.0;

An element item is schema-ready if the URI of any of its namespace declaration items which nominates a schema resolves successfully to a schema.

A document is schema-ready if every element item anywhere in its information set is schema-ready.

Note that this means that documents with no namespace declarations, or only namespace declarations which do not nominate schemas are none-the-less schema-ready.

We say an element item is schema-governed if its name is in a namespace, and the URI of the information item for that namespace resolves successfully to a schema.

We use the name schema root for any element item which is schema-governed and which is either

the document element

The provision within &XSP1; of a mechanism for defining parsed entities presents problems for the relationship between schema-validity and XML 1.0 well-formedness, since references to entities declared only in a schema are undefined from the XML 1.0 perspective. Strictly speaking, a well-formed XML document may contain references to undefined entities only if it is declared as standalone="no" and contains either an external subset or one or more references to external parameter entities in their internal subset. We get around this by defining a nearly well-formed XML document to be one which either is well-formed per XML 1.0, or which fails to be well-formed only because of undefined general entity references, but which would be well-formed if it were standalone="no" and identified an external subset. We consider this justified on the grounds that the use of a namespace declaration which refers to a schema functions rather as an external subset, and from the XML 1.0 perspective such a reference almost of necessity renders the document non-standalone when schema-validation is applied.

We use the name string-infoset-in-context for the XML 1.0 information set items arising from the interpretation of a string in the context of a particular point in an XML 1.0 information set.

The effective element item of an element item (call this OEI) is an element item whose

name and namespace items (if any) are the same as those of OEI;

The Schema Validity Constraint obtains.

The Schema Validity Constraint obtains.

Note that the above constraints and definition mean that in error-free documents, all element items, even ones which are not schema-governed, have well-defined effective element items.

A document is schema-valid if and only if:

Note that there is no requirement that the schema root mentioned above be the root of its document, or that schemas be the roots of their documents, or that schema and schema root be in different documents. Accordingly, it is possible for a single schema-valid document to contain both a schema and the material which it validates.

The interaction between XML 1.0 DTDs and XML Schemas is complex but clear:

The augmented information set of a schema-valid document is the information set rooted in the effective element item of its document element, augmented by all the information items described in any Schema Information Set Contributions which apply to any information items anywhere within it.

Each step in the following presupposes the successful outcome of the previous step.

A conforming XML Schema processor must: