1.1 Documentation Conventions

This Working Draft document was produced using an [XML] DTD and an [XSLT] stylesheet.

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

[Definition: ] A term is something we use a lot.

Example

A non-normative example illustrating use of the schema language, or a related instance. <schema name='http://www.muzmo.com/XMLSchema/1.0/mySchema.xsd' > And an explanation of the example.

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

Issue (dummy): A recorded issue.

Ed. Note: Notes shared among the editorial team.

NOTE: General comments directed to all readers.

1.2 Purpose

The purpose of XML Schema: Structures is to provide an inventory of XML markup constructs with which to write schemas.

The purpose of an XML Schema: Structures 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, XML Schema: 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 to express syntactic, structural and value constraints applicable to its document instances. The XML Schema: Structures 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.

1.3 Relationship To Other Work

The definition of XML Schema: Structures 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

XML Datatype Language

XML Schema: Structures has a dependency on the data typing mechanisms defined in its companion [XML Schemas: Datatypes], published simultaneously with this recommendation.

Document Object Model

XML Schema: Structures has not yet identified requirements or dependencies.

HTML

XML Schema: Structures has a requirement to support modularization of HTML.

Internationalization Working Group

See http://www.w3.org/XML/Group/1999/03/xml-schema-i18n-notes

RDF Schema

XML Schema: Structures has not yet documented requirements or dependencies.

WAI

XML Schema: Structures has a requirement to support accessibility.

XML Information Set

XML Schema: Structures has significant dependencies on [XML-Infoset].

XML Schema: Structures defines its own Information Set Contributions.

XML Schema: Structures will have requirements for subsequent Information Set Working Drafts .

XML Linking WG

XML Schema: Structures has not yet identified requirements or dependencies.

XML Syntax

XML Schema: Structures must interoperate with XML 1.0 and subsequent revisions.

XSL WG

XML Schema: Structures has a requirement to support dimensions and aggregate datatypes.

1.4 Terminology

The terminology used to describe XML Schema: Structures 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 XML Schema: Structures processors:

[Definition: ] may

Conforming documents and processors are permitted to but need not behave as described.

[Definition: ] must

Conforming documents and processors are required to behave as described; otherwise they are in error.

[Definition: ] error

A violation of the rules of this specification; results are undefined. Conforming software may detect and report an error and may recover from it.

[Definition: ] fatal error

An error which a conforming processor must detect and report to the application.

[Definition: ] match

(Of strings or names:) Two strings or names being compared must be character for character the same.

[Definition: ] identical

(Of URIs or schemaNames:) identical, according to the rules for identity in [XML-Namespaces].

2.1 Kinds of XML Documents

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

[Definition: ] Instance

An XML document whose structure conforms to some schema. See Associating Instance Document Constructs with Corresponding Schemata for the means by which an instance identifies the schema(s) to which it conforms.

[Definition: ] Schema

A set of rules for constraining the structure and articulating the information set of XML documents.

[Definition: ] Schema Definition

An XML document that defines a schema. See Access to Schemata for the means by which schema definition documents are accessed during processing. The term "Schema Definition" may also be abbreviated to "schema" where no confusion is likely.

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

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;
• Schema definitions applicable to documents that are not schema definitions;
• The schema definition applicable to schema definitions.

2.2 On schemas, constraints and contributions

The [XML] 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 XML Schema: Structures components on instances are distinguished in this specification:

[Definition: ] Constraint on Schemas

Constraints on the form and content of schemas themselves, above and beyond those expressed in (normative) Schema for Schemas;

[Definition: ] Schema-Validity Constraint

Constraints on the form of instances which they must satisfy to be schema-valid;

[Definition: ] Schema Information Set Contribution

Augmentations to the information sets of instances which follow as a consequence of schema-validation.

NOTE: Schema Information Set Contributions are not as new as might at first appear: XML 1.0 validation augments the XML 1.0 information set in similar ways, e.g. by providing values for attributes not present in instances, and by implicitly exploiting type information for normalization or access, e.g. consider the effect of NMTOKENS on attribute whitespace, and the semantics of ID and IDREF. By including Schema Information Set Contributions, we are trying to make explicit something XML 1.0 left implicit.

XML Schema: Structures 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.

2.3 On 'types'

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.

2.4 Schemas and their component parts

The next chapter Schema Definitions and Declarations sets out the XML Schema: Structures 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.

2.5 Names and Symbol Spaces

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. [Definition: ] Accordingly we introduce the idea of a symbol space (avoiding 'name space' to avoid confusion with 'Namespaces in XML' [XML-Namespaces]).

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.

2.6 Abstract and Concrete Syntax

XML Schema: Structures is presented here primarily in the form of an [Definition: ] 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 [URI]) 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 XML Schema: Structures, 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 [Definition: ] concrete syntax of XML Schema: Structures, 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 (normative) Schema for Schemas and (normative) DTD for Schemas. The emphasis in this version has been to stay quite close to the abstract syntax.

3.1 The Schema

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

preamble consists of an xmlSchemaRef specifying the URI for XML Schema: Structures; 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.

Example

<!DOCTYPE schema PUBLIC '-//W3C//DTD XML Schema Version 1.0//EN' SYSTEM 'http://www.w3.org/1999/05/06-xmlschema-1/structures.dtd' > <schema name='file:/usr/schemas/xmlschema/mySchema.xsd' version='M.n' xmlns='http://www.w3.org/1999/05/06-xmlschema-1/structures.xsd'> ... </schema> Note that the abstract syntax xmlSchemaRef is realised via a default namespace declaration in the concrete syntax.

The schema's model property is discussed in Archetype Refinement. The schema's export, import and include properties are discussed in Schema Composition and Namespaces.

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

Example

The following illustrates the basic model for declaring all XML Schema: Structures components: <datatype name='myDatatype'> ... </datatype> <archetype name='myArchetype'> ... </archetype> <elementType name='myElementType'> ... </elementType> <attrGroup name='myAttrGroup'> ... </attrGroup> <modelGroup name='myModelGroup'> ... </modelGroup> <notation name='myNotation' ... /> <textEntity name='myTextEntity'> ... </textEntity> <externalEntity name='myExternalEntity' ... /> <unparsedEntity name='myUnparsedEntity' ... /> </schema> When creating a new component, we declare that its name is associated with the specification for that component. Each new component definition creates a new entry in the symbol space for that kind of component.

Issue (no-evolution): This draft does not deal with the requirement "for addressing the evolution of schemata" (see [XML Schema Requirements]).

3.2 The Document and its Root

NOTE: We have not so far seen any need to reconstruct the XML 1.0 notion of root. For the connection from document instances to schemas, see Schema Validity.

3.3 References to Schema Constructs

Uniform means are provided for reference to a broad variety of schema constructs, both within a single schema and to features imported (Schema Import) from external schemas. The name used to reference any component of XML Schema: Structures 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.

Example

<archetypeRef name='Address'/> <elementTypeRef name='BLOCKQUOTE' schemaAbbrev='HTML'/> <datatypeRef name='quantityi' schemaName='http://www.w3.org/xsl.xsd'/> The first of these is a local reference, the other two refer to schemas elsewhere. The elementTypeRef example assumes the schemaAbbrev HTML has been declared for import; the datatypeRef example similarly assumes that the given (imaginary as of this writing) URL has been declared for import. See Schema Importfor a discussion of importing.

[Definition: ] 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 Preorder Priority for Included Definitions Constraint on Schemas may also obtain.

3.4 Types, Elements and Attributes

Like XML 1.0 DTDs, XML Schema: Structures 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. [Definition: ] We refer hereafter to the combination of schema constraints and information set contributions with the abbreviation SC. Compared to DTDs, XML Schema: Structures provides for a richer set of SCs, and improved capabilities for sharing SCs across sets of elements and attributes.

3.5 Archetype Refinement

NOTE: 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.

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 closed interpretation is as per XML 1.0, where content type and attribute declarations specify all and only what must be present in instances.
• The open interpretation removes the 'and only', i.e. it interprets the content type and attribute declarations as requiring (non-optional) items to be present, but not as excluding others.
• The refinable interpretation requires the declared (non-optional) items to be present, and also admits such others as have been explicitly declared in refinements.

The relevant abstract syntax productions are as follows:

Example

<archetype name='chair' model='refinable'> <refines> <archetypeRef name='furniture'/> </refines> <attrDecl name='noOfSeats'>. . .</attrDecl> </archetype> An archetype which not only refines another by adding an attribute, but also is itself (further) refinable. The furniture archetype must have been declared refinable(or open).

We distinguish between explicit, acquired and effective validation constraints for any archetype. [Definition: ] Explicit constraints are those explicitly present, via attrDecls or contentType, in the definition of the archetype. [Definition: ] Acquired constraints come from the ancestors of an archetype, if it has any refinements. [Definition: ] 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.

Issue (default-model): Should the default model be open, refinable or closed?

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

• For attribute declarations, any attribute name defined in the explicit constraints must not also be defined in any of the acquired constraints, and any attribute name defined in a constraint acquired from one ancestor must not also be defined in a constraint acquired from another, unless they both acquired it from a common ancestor. The effective attribute declarations are defined by the simple set union of the explicit and the acquired attribute definitions.

• For content models, either
  • all the explicit and acquired content models are vacuous in which case the effective model is vacuous;
  or
  • all but one of the explicit and the acquired content models are vacuous, in which case that one becomes the effective model;
  or
  • No element type is referenced by more than one of the explicit and acquired content models (unless two or more acquired models share modelElts acquired from a common ancestor, in which case such modelElts shall be ignored in all but the first for the purpose of constructing the effective model), in which case if the non-vacuous explicit and acquired models are all eltOnly the effective model is a sequence of all the non-vacuous acquired models, in the order in which they are specified in the refinements list, followed by the explicit model (if it is non-vacuous), or else if the non-vacuous explicit and acquired models are all mixed, the effective model is a mixed whose elementTypeRefs and elementTypeDecls are the union of the elementTypeRefs and elementTypeDecls of all the non-vacuous explicit and acquired models.

[Definition: ] 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.

[Definition: ] 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. [Definition: ] AT2 is then said to be an ancestor of AT1.

NOTE: Refinements are by definition substitutable for any of their ancestors.

[Definition: ] 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:

• Any archetype with no attributes is substitutable for an archetype with no attributes and a contentModel of any;
• Any archetype which differs from another only by the specialization of one or more of its attributes (and/or of its datatype if its content is character data) is substitutable for that archetype;
• Any archetype which differs from another only by allowing only character data content (i.e. whose contentType is datatypeRef) where the other has mixed content is substitutable for that archetype.

Example

Refinement by definition creates substitutable archetypes: <archetype name='Address' model='refinable'> <sequence> <elementTypeRef name='street'/> <elementTypeRef name='city'/> </sequence> </archetype> <archetype name='USAddress'> <refines> <archetypeRef name='Address'/> </refines> <sequence> <elementTypeRef name='state'/> <elementTypeRef name='zip'/> </sequence> </archetype> USAddress is substitutable for Address: the effective content model (simplifying in the obviously legitmate way) is <sequence> <elementTypeRef name='street'/> <elementTypeRef name='city'/> <elementTypeRef name='state'/> <elementTypeRef name='zip'/> </sequence> Here is a richer example: <archetype name='transclude' model='refinable'> <mixed/> <attrDecl name='xml:link'> <fixed>simple</fixed> </attrDecl> <attrDecl name='actuate'> <fixed>auto</fixed> </attrDecl> <attrDecl name='href' required='true'> <datatypeRef name='uri'/> </attrDecl> </archetype> <archetype name='anchor' interp='open'> <mixed/> <attrDecl name='id'> <datatypeRef name='ID'/> </attrDecl> </archetype> <archetype name='nestHere'> <refines> <archetypeRef name='transclude'/> <archetypeRef name='anchor'/> </refines> <empty/> <attrDecl name='show'> <fixed>embed</fixed> </attrDecl> </archetype> <elementType name='nestHere' archetype='nestHere'/> <nestHere href='http://www.ltg.ed.ac.uk/~ht/password.xml' id='mpw'/> The final instance element satisfies all the effective constraints associated with the nestHere archetype: its xml:link, actuate and href attributes are constrained by constraints acquired from transclude, its id attribute is constrained by a constraint acquired from anchor and its show attribute is constrained by its own explicit constraint. The effective content model for nestHere is empty, under the second clause of the discussion above: only the explicit content model is there at all, so it gets to be the effective one. Note that because they are refinable and open respectively, both transclude and anchor are satisfied by the nestHere instance, i.e. the substitutability requirement on refining archetypes is satisfied.

Example

Here's a case which merges content models and specializes an attribute definition: <archetype name='polygon' model='refinable'> <elementTypeRef name='bbox'/> <attrDecl name='n' required='yes'/> <attrDecl name='regular'> <datatypeRef name='enumeratedSymbol'> <enumeration> <literal>yes</literal> <literal>no</literal> </enumeration> </datatypeRef> </attrDecl> </archetype> <elementType name='regularPolygon'> <refines> <archetypeRef name='polygon'/> </refines> <elementTypeRef name='side'/> <attrDecl name='regular'> <fixed>yes</fixed> </attrDecl> </elementType> Here we see not only the merging of two content models, with the two elementTypeRefs being concatenated to produce the effective sequence model for the refined archetype, but also the provision in an explicit constraint of a fixed value for an attribute consistent with its acquired constraint. (Strictly speaking, this goes beyond the constraints on refinement set out above, but it obviously preserves substitutability, and will be allowed as soon as more detailed constraints are drafted.) <regularPolygon n='3'> <bbox>...</bbox> <side length='3cm'/> </regularPolygon>

NOTE: The intention of the formal validity definition ref-satisfies is that element item should be valid with respect to an archetypeSpec that is refinable if it is valid with respect to that archetypeSpec itself or any archetypeSpec that refines it. It might them be possible for validating parser to begin by checking daughters with respect to the declared archetypeSpec if it is element only, since any refinement can only add to the end of a sequence of daughters.

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

To parse against an open content model:

informal statement

ignore all daughters which are NOT mentioned explicitly anywhere in the content model: what's left must match the model in the old, deterministic, XML 1.0 way.

formal statement

Consider the edge-labelled FSM for recognizing the declared content model under a 'closed' (i.e. deterministic, XML 1.0) interpretation.

Call the set of all transition labels anywhere in the FSM (i.e. the tags mentioned anywhere anywhere in the model) T.

For each state s in the FSM, call the set of tags which label transitions from that state T[s].

Then to turn the FSM into one which interprets the content model as open, for each state s

1. add a transition to failure for every label in T-T[s];
2. add a transition to s for the complement of T, i.e. a default loopback.

Issue (formal-refinement-FSM): Does refinement need this, or is it covered already?

3.6 Entities and Notations

4.1 Associating Instance Document Constructs with Corresponding Schemata

During validation, the standard mechanisms of [XML-Namespaces] 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 Access to Schemata. Comprehensive rules for validation are discussed in Conformance.

Example

For example (refer to schema definitions in the previous example): <SomeDocument xmlns='http://coolbits.com/someschema.xsd' xmlns:o='http://xyzcorp.com/otherschema.xsd' xmlns:p='http://xyzcorp.com/yetanotherschema.xsd'> <someelement> <name1/> <o:name2 p:someattr='123'/> </someelement> </SomeDocument> 'somelement' and 'name1' (which happens to be empty) are validated against their definitions in 'http://coolbits.com/someschema.xsd'. Similarly, 'name2' is validated against its definition in 'http://xyzcorp.com/otherschema.xsd'. The existence of 'name1' and 'name2' as content of 'somelement', and specifically their URI qualification, is validated against the corresponding content model declaration for 'someelement' in 'http://coolbits.com/someschema.xsd'. Validation definition attrs-satisfy determines whether 'p:someattr' is correctly namespace qualified according to the content model definition for 'name2'.

4.2 Exporting Schema Constructs

NOTE: Experience with programming languages and similar schema definition systems suggests that there is value in distinguishing the internal implementation of a module from the features or interfaces that it provides for reuse by others. For example, a schema defined to describe an automobile might intend that its definitions for 'automobile' and 'engine' be building blocks for use in other schemas, but that other constructs such as 'screw' or 'bolt' be reserved for internal use.

XML Schema: Structures 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:

Example

<schema name='http://coolbits.com/someschema.xsd'> <export datatypes='false' archetypes='false' elementTypes='true' <!-- redundant: default is 'true'> ... /> [...schema body here...] </schema> This declaration restricts export of datatypes and archetypes and explicitly, although redundantly, enables export of element types.

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 Schema Import 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:

Example

<elementType name='myElementType' export='true'> <sequence> <elementTypeRef name='e1'/> <elementTypeRef name='e2'/> </sequence> <attrGroupRef name='attrgrpname'/> </elementType> This element type declares that export is enabled.

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.

NOTE: For example, if schema B exports 'myElement', which relies on unexported constructs from schema B, instances of myElement must conform to its declared content model, including to elements and attributes which might themselves not be overtly exported.

4.3 Facilities for Schema Composition

Section Exporting Schema Constructs 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 Schema Import and Schema Inclusion 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.

NOTE: As described below, import and include operations are effected by declarations at the head of the schema. Therefore, it is possible to discover all of a schema's external dependencies by inspection of its import and include declarations.

4.4 Schema Import

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

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

Example

<schema name='http://coolbits.com/someschema.xsd'> <!-- Establish 'other' abbrev for use in schema --> <import schemaAbbrev='other' schemaName='http://coolbits.com/otherschema.xsd'/> <!-- can use 'other' anywhere in schema body --> <elementType name='myNewElement'> <choice> <elementTypeRef schemaAbbrev='other' name='myElement'/> <elementTypeRef schemaAbbrev='other' name='otherElement'/> </choice> </elementType> </schema> A valid instance would look like the following, delta any namespace prefix changes: <myNewElement xmlns='http://coolbits.com/someschema.xsd' xmlns:pref1='http://coolbits.com/otherschema.xsd'> <pref1:myElement/> <pref1:otherElement/> </myNewElement> The default namespace establishes that myNewElement is an element name in the default namespace, and the two subordinate elements are from the namespace associated with the pref1 prefix.

Use of schema abbreviations is explained in detail below.

4.5 Using Abbreviations to Reference Imported Schemas

As described in The Schema, the schema's schemaName property supplies a [URI] 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 Schema Import mechanism.

Example

The following example illustrates the general role of abbreviations in qualifying references to composed schemas: <schema name='http://coolbits.com/someschema.xsd'> <import schemaAbbrev='schema2' schemaName='http://coolbits.com/otherschema.xsd'/> <elementType name='someelement'> <sequence> <elementTypeRef name='name1'/> <elementTypeRef name='name2' schemaAbbrev='schema2' /> </sequence> </elementType> </schema> The example illustrates the use of references, in a single content model, to an unqualified and a abbreviation-qualified element type. A schema named with the URI 'http://coolbits.com/someschema.xsd' is shown importing features from another schema named 'http://coolbits.com/otherschema.xsd'. No abbreviation is used in the content model for element 'someelement', to indicate that 'name1' is a reference to an element defined locally. In contrast, 'name2' is qualified by the 'schema2' abbreviation and is therefore defined in 'otherschema.xsd'.

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

4.6 Import Restrictions

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

Example

The following example illustrates control of schema import by category: <schema name='http://coolbits.com/someschema.xsd'> <!-- Establish abbrev1 abbrev for use in schema --> <import schemaAbbrev='abbrev1' schemaName='http://coolbits.com/otherschema.xsd' archetypes='true' datatypes='true' > <elementTypeRef name='myElement'/> <elementTypeRef name='otherElement'/> <import> <choice> <elementRef schemaAbbrev='abbrev1' name='myElement'/> <elementRef schemaAbbrev='abbrev1' name='otherElement'/> </choice> </schema> In the example, all datatypes and achetypes that are exported from 'otherschema', as well as the elements named 'myElement' and 'otherElement' are imported.

NOTE: A question arises as to whether imported definitions are re-exported for use by yet a third schema. Because of the difficulties in managing abbrev associations, the answer is 'no', at least in this draft of the specification.

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.

4.7 Schema Inclusion

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.

Example

The following example illustrates inclusion: <schema name='http://coolbits.com/someschema.xsd'> <include schemaName='http://coolbits.com/otherschema.xsd'> <elementRef name='myElement'/> <elementRef name='otherElement'/> <include> <!-- Note unqualified references below --> <choice> <elementTypeRef name='myElement'/> <elementTypeRef name='otherElement'/> </choice> </schema> The two elements, myElement and otherElement, are deemed to part of the overall schema's namespace. Barring accidental name collision, these two foreign element types can be treated just as though they were defined in the current schema. The definitions of their datatypes, achetypes, elements and attributes, are also implicitly included.

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.

NOTE: There is some question as to whether all such features should be implicitly imported, or whether features should be imported only when needed to complete the specification of some explicitly included feature (e.g. an imported attribute needed on an included element type.)

An inclusion is treated as a local definition, so naming collisions are possible with other locally defined or included constructs. [Definition: ] 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.

[Definition: ] 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.

[Definition: ] 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.

4.8 Access to Schemata

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 [URL].

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.

NOTE: Why this choice? Several reasons, including:

• URL's are not appropriate to all the storage environments in which schema access is required.
• We cannot assume that a schema which was once accessible via URL will remain so for all time. Companies fail, organizations reorganize, but the schemas they have written and named should remain usable without modification. We cannot require a fixed website in perpetuity to host each schema.
• For widely used schemas (e.g. [HTML-4], or the schema for XML schemas), access to a single copy or even to a centrally managed replica can result in scaleability and availability problems.
• URN's are intended as at least a partial solution, but they are not yet widely deployed, and their effectiveness has yet to be proven on a large scale. Should they prove successful, this design is fully compatible with and will require no modification for URN-based naming of schemas.

6.1 Schema Validity

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 [XML-Infoset] 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.

[Definition: ] 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,
• the XML Schema 1.0 DTD (or the equivalent DTD from a successor to this specification)

• The XML Schema 1.0 schema (or the equivalent schema from a successor to this specification).

[Definition: ] 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;
• it and its descendants satisfy all Constraints on Schemas stated in this specification.

[Definition: ] 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.

Issue (namespace-declaration-items): Namespace items associated with namespace declarations have disappeared from the most recent version [XML-Infoset]. Several WGs need them, we expect they'll be back, otherwise we can reconstruct what we need from element and attribute namespace items alone with some effort.

[Definition: ] 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.

[Definition: ] 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.

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

• the document element

• the daughter of an element which is not schema-governed.

The provision within XML Schema: Structures 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 [Definition: ] 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.

[Definition: ] 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.

[Definition: ] 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;
• attribute item names and namespace items (if any) are the same as those of OEI;
• attribute value items are the respective value items of OEI's attribute items with the string-infoset-in-context of the declared expansion of every RUE in those values replacing those RUEs;
• children based on the children of OEI as follows:
  • Character, PI and comment child items carried over unchanged;
  • Element child items replaced with their respective effective element items;
  • RUE child items replaced by the string-infoset-in-context of their declared expansions, with any RUE or element item in that string-infoset-in-context itself being recursively replaced per this or the above definition respectively.

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.

[Definition: ] A document is schema-valid if and only if:

1. It is nearly-well-formed;
2. It is schema-ready;
3. Every schema root element item in the set of element items consisting of the effective element item of the document element item in the document's information set and all the element items anywhere inside that effective element item, is independently valid.

NOTE: The validity of all other schema-governed element items follows from (3) above by the recursive nature of the Schema-validity Constraint referenced there.

NOTE: It is intentional that the above definition labels as schema-valid a document with no namespace declarations or with only namespace declarations which do not nominate schemas.

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:

• A document may be well-formed, (DTD) invalid and schema-valid all at the same time;
• If document has a DTD which includes parsed entity declarations, the schema-validation process may well apply to material whose original home was in those entities (internal or external);
• Where or not a document has a DTD, the (XML 1.0) infoset we're schema-validating may well include 'RUE items', that is, references to unknown entities, unknown, that is, as far as the definitions of XML 1.0 are concerned. As long as the document's schema provides schema definitions for these 'undefined' entities, it still may be schema-valid.

NOTE: The above is silent on whether schema-valid documents must be Namespace-conforming.

[Definition: ] 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.

6.2 Responsibilities of Schema-aware processors

NOTE: This section has fallen out of alignment with the rest of the specification, but is included none-the-less to give a feeling for how this section will eventually look: the details should not be taken too seriously.

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

A conforming XML Schema processor must:

1. Test for XML 1.0 well-formedness;
2. Construct the XML 1.0 information set. This will include identifying and distinguishing all namespace declarations and uses, and expanding any entity references whose XML 1.0 declarations are accessible;
3. Starting from the root, traverse the information set in pre-order until an element information item with a namespace declaration which refers to an accessible schema is found;
4. Schema-validate the information set subtree rooted at that element information item using that schema, i.e.
   • Expand the information set by replacing the remaining entity references as described in Schema Validity;
   • Schema-validate the resulting information set, as described in Schema Validity;
   • Expand the information set per all Schema Information Set Contributions encountered
     • for each namespace: its prefixes and URI, and access to a schema corresponding to that URI.
     • for each element: its name (URI+GI), its content, its datatype or archetype, its attributes
     • for each attribute: its name, its value(s), its datatype, and whether its presence is required on an element.
     • for each datatype: its names, its heritage (or type lattice), its value space, its refinable facets.
     • for data: its type (and type lattice), whether it's presence is required, and its lexical constraints.
     • for each archetype: its name, its content model or datatype, its heritage (or type lattice), its attributes, and whether it is open/closed or can be refined.
     • for each element type: its name, its datatype or archetype or content model, its attributes, and whether it is open/closed or can be refined.
     • for each model: whether it is any, empty, mixed, or a group of one or more element types -- in which case, the grammar of the group, and whether it is open/closed or can be refined.
5. Go back to (3) above and continue traversing, starting with the successor in document order to the item just schema-validated, unless there is no successor;
6. Provide for an external processing system to have access to the combined information set: document instance plus schema information.

NOTE: Note that the schema contribution to the information set above is meant to be suggestive only at this point, until we've articulated all the Schema Information Set Contributions in the preceding sections.

6.3 Lexical representation

NOTE: The editors did not get to this.

6.4 Information set

NOTE: The editors did not get to this.