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

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, it is useful to clarify the relationships between certain kinds of XML documents:

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

Any schema definition is therefore also an instance. The editors will make an attempt to always use the most precise of these terms, but the reader should note that rules specified herein for instances do apply to all of the following kinds of XML document:

Documents that are not schema definitions;

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 element types 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 use of the word 'type' has caused confusion in earlier discussions of schema technologies. Here, the word is used in several different contexts for a constraint on the form of (parts of) an element or attribute in an instance document. So, there are types that are suitable for constraining individual attributes, others that apply to entire elements (of which attributes may be a part), and so on. We use the words 'define' and 'definition' when speaking of types, and the words 'declare' and 'declaration' when specifying for an attribute or element type the type which constrains its form in instance documents.

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. An asterisk (*) in the 'Named?' 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 are given names, which provide for references within the schema, and sometimes from one schema to another. For example, an attribute definition can refer to a named datatype, such as 'integer'. A content model can refer to an element type, 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 type 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 type': 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 an archetype and an element type, without conflict or necessary relation between the two.

Attributes and local element type declarations are special, in that every archetype defines its own attribute and local element type symbol spaces.

&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 and in and . The emphasis in this version has been to stay quite close to the abstract syntax.

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

preamble consists of an xmlSchemaRef specifying the URI for &XSP1;; the schemaIdentity specifying the URI by which this schema is to be identified; and a schemaVersion specification for private version documentation purposes and version management.

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:

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 definition. 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 BNF above illustrates the reference mechanisms used in this specification.

A ...Ref identifies a ...Spec provided there is a definition or declaration of that ...Spec in the appropriate schema whose NCName matches the NCName of the ...Ref's ...Name. If there is no schemaRef in the ...Name, the appropriate schema is the current schema or a schema it eventually includes; if there is a schemaRef, the URI contained in or abbreviated by it must resolve successfully to a schema, which is then the appropriate schema. The Constraint on Schemas may also obtain.

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 declared in a schema. An archetype definition may identify one or more other archetypes from which it specifies the creation of a (joint) refinement.

We provide for interpreting archetypes as imposing constraints on instance elements in either a closed, refinable or open fashion.

The relevant abstract syntax productions are as follows:

We distinguish between explicit, acquired and effective validation constraints for any archetype. Explicit constraints are those explicitly present, via attrDecls or contentType, in the definition of the archetype. Acquired constraints come from the ancestors of an archetype, if it has any refinements. The effective constraints are the union of the explicit and the acquired. The effective constraints are what actually constrain any element type declared with reference to a refining archetype.

For the present, the permitted refinements and the resulting effective constraints are as follows:

A refinable or open mixed content model is called vacuous if it has no declared elementTypeRefs or elementTypeDecls within it. This is because any archetype is substitutable for an archetype with a vacuous content model and no declared attributes.

An archetype AT1 is said to refine an archetype AT2 if and only if AT1 is declared to refine either AT2 or (recursively) some archetype that refines AT2. AT2 is then said to be an ancestor of AT1.

We define a substitutability relation between two archetypes as follows:

One archetype is substitutable for another if any schema-valid instance of the former is necessarily a schema-valid instance of the latter.

Some simple cases:

There follows a semi-formal definition of validity with respect to an open content model.

To parse against an open content model:

During validation, the standard mechanisms of are interpreted to create associations between instance document prefixes and schema definitions. Thus, there is in each valid instance document a namespace associated with each schema to which the instance conforms. Each namespace qualified element (or eventually entity or notation), its attributes and its content, is validated against its declaration in the corresponding URI-named schema. In that sense, each schema defines and is coextensive with a namespace. The means by which schemas are located during processing is discussed below in . Comprehensive rules for validation are discussed in .

&XSP1; constructs must be exported for external use. By default, all datatypes, archetypes, elementTypes, attribute definitions, model groups, attribute groups, entities and notations are exported. The export declaration can be used within a schema declaration to override the default behavior for each such class of declaration or definition:

The default for all attributes of the export declaration is 'true'. Therefore, all constructions are exported by default if 'export' is not specified, and only the constructions that are not specifically disabled are exported if 'export' is specified. If a schema A imports some other schema B, then by default, all definitions imported from B are exported from A. See below.

Export can also be controlled individually for each particular elementType, archetype, model group, attribute group, datatype, entity or notation. Attribute definitions are implicitly exported (or not) along with the elementTypes in which they appear. An export declaration appearing on an individual elementType, archetype, or other declaration or definition overrides any default export behavior established at the schema level.

The following abstract syntax is repeated from elsewhere in this document:

As with any other construct, an elementType or attribute which is not exported cannot be imported for use in the declaration of a content model in an importing schema. However, an instance document providing a namespace qualified element is required to conform with the full archetype of that element, including attributes and elements which might not have been explicitly exported or imported; validating processors are required to check for conformance with the full archetype as declared in the exporting schema.

Similarly, an exported archetype applied to an elementType definition in an importing schema confers its full content type and attribute definitions, including references to elements, content models and attributes which may not have been explicitly exported.

Section describes the means by which one schema can offer constructs for use in other schemas. Here we contrast two facilities which are provided for combining two or more schemas into a single schema definition. These facilities are referred to as and respectively.

Schema import provides for schema validation of content models for instance documents that refer to two or more namespaces. Schema inclusion supports modular development and composition of a schema that is ultimately indistinguishable from an equivalent schema developed as a monolithic unit. Stated another way, imported schema components retain their original URI schema name association; included components are effectively re-declared in the including schema, and are thus indistinguishable from similar constructions declared locally.

An external schema must be explicitly imported for use via a declaration at the head of the importing schema document.

As explained in , imported features can be accessed through an explict schemaName URI or through a shorthand abbreviation (schemaAbbrev).

Use of schema abbreviations is explained in detail below.

As described in , the schema's schemaName property supplies a to name the schema being declared. When multiple schemas are composed, a schemaRef (which is either the full schemaName URI or the shorthand schemaAbbrev) is used to reference definitions and declarations from imported schemas. schemaAbbrevs are introduced via the mechanism.

Further details of schema composition are spelled out formally in the sections below.

Import can be restricted to categories such as datatypes, archetypes, element types, and so on:

Imported constructs are not implicitly and cannot explicitly be re-exported. However, any element or archetype is imported with its full content model, even when that content model depends on recursively imported elements or attributes. Similarly, an attribute definition can carry a datatype from an external schema, and so on. In other words, myElement in the example above might have a content model that draws on many schemas. Element1 itself is usable as shown above, but its constituent components are only available for use in new content models if explicitly imported.

Furthermore, if some schema B includes features of schema A, and if schema C includes features of B, then C can also explicitly include the same features of schema A directly.

Although the declarations for schema inclusion resemble those for importation, the purpose is quite different. Element types, attributes, model groups, etc. are effectively redeclared when included in a schema. Specifically, the resulting construct is named in a symbol space of the including schema. As seen by authors of instance documents and other schemas, the result is indistinguishable from a definition or declaration made in the including schema.

An include specification is equivalent to a local definition of the corresponding elementTypes, archetypes, datatypes, attributes, model groups, entities, notations, and attribute groups.

Because the intention is to hide the inclusion hierarchy from users, any declarations or definitions on which the inclusion depends, and which are themselves declared locally in or included by the included schema, are similarly redeclared in the including schema. Conversely, definitions or declarations imported by an included schema are effectively imported when used in an including schema.

An inclusion is treated as a local definition, so naming collisions are possible with other locally defined or included constructs. All include declarations encountered in a schema form a schema path in the order encountered. When two or more includes would cause the definition or declaration of identically named elements (I.e. the same NCName in the same symbol space), the first one encountered in the schema path (I.e. the first included) is used and any others are ignored. A local definition or declaration in an including schema supersedes any definition or declaration from any included schema.

A schema directly includes another schema if the first schema has an include and the URI contained in or abbreviated by the schemaRef of that include resolves successfully to the second schema.

A schema eventually includes another schema if the first schema directly includes the second, or if the first schema directly includes some other schema which itself eventually includes the second.

Validation requires that one or more schemas be available to the validating processor. As specified above, schemas are named by URI's, which can but need not resemble in form a .

The means used by some particular processor to access a schema, based on its URI, are beyond the scope of this specification, and are expected to vary from processor to processor. Whether a URI that resembles a URL is indeed usable as a URL during validation is application- and processor-dependent. This specification requires that the transitive closure of all schemas required for validation must be accessible to the processor, through whatever means, based on the URI name of each 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 defined 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;

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: