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, entities and their contents and notations. 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 .

Any schema is ipso facto an element information item. It follows that the rules specified herein for validity apply to all of the following kinds of XML element information items:

Elements that are not schemas;

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 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 is itself a set 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 datatypes defined in , but some are complex. We use the archetype element when declaring elements which allow elements in their content and/or may carry attributes. For example, we can define an archetype 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 datatype or an archetype, and there are separate symbol spaces for these two, the possibility of ambiguity arises. This is resolved in favour of the archetype, e.g. even if a datatype called Address existed (either builtin or user-defined), the above declaration for shipTo would refer to the user-defined archetype of that name.

A definition creates a new archetype or datatype; 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 an archetype, 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 datatype:

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

As well as naming a datatype or archetype 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 .

The next chapter sets out the &XSP1; approach to schemas and formal definitions of their component parts. Here we informally summarize the key constructs used in defining schemas. A 'Yes' in the 'Name apears 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 datatype, 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 datatype 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 'Namespaces in XML' ).

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 archetype 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 an archetype definition) reside in their own symbol space.

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

See for discussion of schemas, instances and namespaces.

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 model property is discussed in . The schema's export, import and include properties are discussed in .

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 an NCName and an optional schemaRef, a reference to an external schema. In a few cases, some qualification 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 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 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.

We provide for the refinement of archetypes defined in a schema. An archetype definition may identify one or more other archetypes from which it specifies the creation of a (joint) refinement.

This chapter describes facilities to provide for validation of namespace-qualified instance document elements and attributes, and potentially (subject to enhancements to the Namespaces recommendation), entities and notations.

We envision applications of Extensible Markup Language (XML) where a single XML document may contain elements and attributes (here referred to as a 'markup vocabulary') that are defined for and used by multiple software modules. One motivation for this is modularity; if such a markup vocabulary exists which is well-understood and for which there is useful software available, it is better to re-use this markup rather than re-invent it. Such documents, containing multiple markup vocabularies, pose problems of recognition and collision. Software modules need to be able to recognize the tags and attributes which they are designed to process, even in the face of 'collisions' occurring when markup intended for some other software package uses the same element or attribute name. These considerations require that document constructs should have universal names, whose scope extends beyond their containing document. This specification describes a mechanism, XML Schema namespaces, which accomplishes this.

&XSP1; provides facilities to enable declaration and modular composition of schemas.

The balance of this section as it appeared in the previous public WD has been withdrawn, pending further discussion in the WG. A Task Force created from within the WG has investigated a range of issues and options for implementing the desired functionality. The Task Force has produced a report , which will form the basis of a design to be filled in here.

The TF report recommends a layered approach, where the base layer simply addresses the process of schema validation where the element information item to be validated and the schema to validate it with are known. The second layer discusses mechanisms by which processors may locate schemas, but emphasises that this is always in the end an processor- and environment-dependent process. The following candidate mechanisms are identified:

The namespace URI of the item to be validated is dereferenced and yields a schema;

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 item, RUE and information set.) 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.

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 nam