XML Schema Part 1: Structures

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" > 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 from the editors to themselves or the Working Gorup.

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

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

XML Schema: Structures has a dependency on the mechanisms for defining simple types provided in its companion [XML Schemas: Datatypes], published simultaneously with this document. Together these two documents constitute the XML Schema Recommendation.

Document Object Model

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

HTML

XML Schema: Structures has been requested to support modularization of (X)HTML.

Internationalization Working Group

See http://www.w3.org/XML/Group/1999/03/xml-schema-i18n-notes (W3C Member only)

RDF Schema

XML Schema: Structures has not yet documented requirements or dependencies. See [Cambridge Communiqué] for a clarification of the relationship between the two, which includes requirements arising from web architecture considerations.

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 which are compatible with [XML-Infoset] although not defined as such therein.

XML Linking WG

Unique, key and key reference constraints (§3.7) uses XPath expressions, as defined in [XPath].

XML Syntax

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

XSL WG

The XSL Working Group has requested XML Schema: Structures to support dimensions and aggregate datatypes: not discharged in this WD.

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

[Definition:]  Instance

An XML element information item which conforms to some schema. See [XML-Infoset] for a discussion of information items: in brief, [Definition:]  an element information item is the component of an infoset which corresponds to an element. From it other information items are accessible, including attributes, namespace declarations and content. See Layer 3: Web-interoperability (§4.3) and Schema Validity * (§6.1) for the means by which an instance identifies the schema(s) to which it conforms. Note we will often speak loosely about an (XML) instance document, but this is just shorthand for the element information item associated with the document element of an XML document. Similarly, we will often speak of elements when we mean element information item.

[Definition:]  XML Schema

An XML element information item which, along with its descendants, satisfies all the Constraints on Schemas in this specification. An XML Schema establishes a set of rules for constraining the structure and articulating the information set of XML document instances.

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

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 (§A);

[Definition:]  Schema-Validity Constraint

Constraints on the form and content of instances, which the instances must satisfy to be schema-valid;

[Definition:]  Schema Information Set Contribution

Augmentations to post-validation information sets 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 numeral sequences representing integers in a specified range.

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

2.3 Schemas, Types and Elements

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

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

Example

<?xml version='1.0'?> <PurchaseOrder orderDate="1999-05-20" xmlns="http://www.myco.com/MYPO"> <shipTo type="US"> <name>Alice Smith</name> <street>123 Maple Street</street> <city>Mill Valley</city> <state>CA</state> <zip>90952</zip> </shipTo> <shipDate>1999-05-25</shipDate> <comment>Get these things to me in a hurry, my lawn is going wild!</comment> <Items> <Item pno="333-333"> <productName>Lawnmower, model BUZZ-1</productName> <quantity>1</quantity> <price>148.95</price> <comment>Please confirm this is the electric model</comment> </Item> <Item pno="444-444"> <productName>Baby Monitor, model SNOOZE-2</productName> <quantity>1</quantity> <price>39.98</price> </Item> </Items> </PurchaseOrder>

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

Example

<type name="Address" > <element name="name" type="string" /> <element name="street" type="string" /> <element name="city" type="string" /> <element name="state" type="string" /> <element name="zip" type="integer" /> <attribute name="type" type="string" /> </type> The consequence of this definition is that an element whose type is declared to be Address must consist of five elements and may have one attribute. Though each has a distinct name, four of the elements and the attribute will simply contain a string in a document instance while one will contain an integer.

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:

Example

<element name="comment" type="string" /> This declaration restricts the comment element to text content and no attributes.

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

Example

<type name="PurchaseOrderType"> <element name="shipTo" type="po:Address" /> <element name="shipDate" type="date" /> <element ref="po:comment" minOccurs="0" /> <element name="Items" type="po:Items" /> <attribute name="orderDate" type="date" /> </type> The shipDate element daughter of PurchaseOrderType is declared above as having a simple type, as in the Address example above. The comment daughter is declared by reference to a global element declaration. Since this definition is in the namespace being defined, and apparently the default namespace is being used for the schema elements themselves (e.g. element, attribute), we use a prefix (po) on this reference which would have to be declared with the same URI as the target namespace URI for the containing schema. Similarly, the shipTo and Items daughters are declared as having complex types which must be defined elsewhere in the current schema. The comment daughter and the orderDate attribute are optional, the others are obligatory.

Issue (type-decl-syntax): Further integration of the concrete syntax for type definitions is desireable, e.g. by using 'type' for both simple and complex types, but the details of a consistent and clear way to do this have not yet been agreed.

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

Issue (note-two-sses): The separation of the simple and complex type name symbol spaces is primarily motivated by the decision to allow unqualified reference to the ab initio and built-in simple types. Should this decision be reversed, as was suggested in the report of the simplification Task Force, then the unification of the two symbol spaces could proceed with minimal negative impact. The potential for error which arises from unexpected shadowing of an old simple type by a new complex type would be removed.

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

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

Example

<attribute name="orderDate" type="date" />

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

Example

<element name="shipTo" type="po:Address" /> <element name="comment" type="string" /> Because Address is defined in the schema to have certain elements as its content and to allow a certain attribute, any shipTo element appearing in an instance must include those elements and may have that attribute, while any comment element may not have any attributes, but any text content.

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

Example

<type name="Items"> <element name="Item" minOccurs="0" maxOccurs="*"> <type> <element name="productName" type="string" /> <element name="quantity"> <datatype source="integer"> <minExclusive value="0"/> </datatype> </element> <element name="price" type="decimal" /> <element ref="po:comment" minOccurs="0" /> <attribute name="pno" type="string"/> </type> </element> </type> Here not only is the type of the Item element given in line, but also the simple type of its quantity daughter (the built-in simple type integer) is qualified inline by adding a subrange constraint.

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 Sample Schema (non-normative) (§F).

2.4 Schemas and their component parts

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

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

2.5 Names and Symbol Spaces

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

If all such names were assigned from the same 'pool', then it would be impossible to have e.g. a type named 'integer' and an element with the name 'integer' in the same schema. [Definition:]  Accordingly we introduce the idea of a symbol space (avoiding 'name space' to avoid confusion with the term defined in [XML-Namespaces]). A symbol space is similar to the non-normative concept of namespace partition introduced in [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': within a given symbol space, names are unique, but the same name may appear in more than one symbol space without conflict. In particular note that the same name can refer to both a type and an element, without conflict or necessary relation between the two.

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

2.6 Referencing Schema Components

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

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

2.7 Association of components with a target namespace

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

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

    <schema targetNamespace="someNSURI">
      ...every global declaration & def'n here...
      ...is in targetNamespace
    </schema>

2.8 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, paradigms and in (normative) Schema for Schemas (§A) and (normative) DTD for Schemas (§B). 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.

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 targetNamespace specifying the URI of the namespace which this schema is about; and a schemaVersion specification for private version documentation purposes and version management.

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

See Schema Access and Composition (§4) for discussion of schemas, instances and namespaces, and also for import and include.

Example

<!DOCTYPE schema PUBLIC '-//W3C//DTD XML Schema Version 1.0//EN' SYSTEM 'http://www.w3.org/TR/1999/WD-xmlschema-1-19991217/structures.dtd' > <schema targetNS="http://purl.org/metadata/dublin_core" version="M.n" xmlns="http://www.w3.org/1999/XMLSchema"> ... </schema> Note that the abstract syntax xmlSchemaRef is realised via a default namespace declaration in the concrete syntax.

Although the schema above is a complete XML document, schema need not be the document element, but can appear within other documents. Indeed there is no requirement that a schema be derived from a (text) document at all: it could be built 'by hand' via e.g. a DOM-conformant API.

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

Example

The following illustrates the basic model for declaring or defining all XML Schema: Structures components: <datatype name="myDatatype"> ... </datatype> <type name="myType"> ... </type> <element name="myElement"> ... </element> <attributeGroup name="myAttrGroup"> ... </attributeGroup> <group name="myModelGroup"> ... </group> <notation name="myNotation" ... /> </schema> When creating a component, we establish an association between its name and the specification for that component. Each new component therefore creates a new entry in the symbol space for that kind of component.

Ed. Note: make sure that discussion of targetNamespace is up-to-date.

The Unique Definition (§6.2.1) Constraint on Schemas obtains.

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 Layer 3: Web-interoperability (§4.3) and Schema Validity * (§6.1).

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 (References to schema components across namespaces (§4.2.2)) from external schemas. The name used to reference any component of XML Schema: Structures from within a schema consists of a QName. In a few cases, some elaboration may be added to a reference: this is made clear as the individual reference forms are introduced below.

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

Example

<element name="elem1" type="Address"/> <element name="elem2" type="XHTML:BLOCKQUOTE"/> <attribute name="attr1" type="xsl:quantity"/> The first of these is a local reference, the other two refer to schemas elsewhere and assume that the prefixes used have been declared and their namespaces declared for import. See References to schema components across namespaces (§4.2.2) for a discussion of importing.

The Consistent Import (§6.2.2) Constraint on Schemas obtains.

The identify definition wrt schema-validity obtains.

The Preorder Priority for Included Definitions (§6.2.6) Constraint on Schemas also obtains.

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 call a set of SCs intended for use in this way a type definition.

[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 Wildcards

In order to exploit the full potential for extensibility offered by XML plus namespaces, more provision is needed than DTDs allow for targeted flexibility in content models and attribute declarations. At a given point in a content model, in addition to what DTDs provide for we need particles that allow the following:

1. Any well-formed XML element item: any tag, any namespace, any attributes, any content, as long as it's well-formed;
2. Any well-formed XML element item, provided it's in some other namespace than the one we're defining a type for;
3. Any well-formed XML element item, provided it's in a specified namespace;
4. Any well-formed XML element item, provided it's from the same namespace as the one we're defining a type for.

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

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

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

All of the above are subject to the same ambiguity constraints (Unambiguous Content Model (§3.4.6)) as other content model particles: If an instance element could match either an explicit particle and a wildcard, or one of two wildcards, within the content model of a type, that model is in error.

Example

<any/> <any namespace="##other"/> <any namespace="http://www.w3.org/1999/Style/Transform/"> <any namespace="##targetNamespace"/> <anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/> Concrete examples of the four cases listed above, plus one attribute case.

3.6 Deriving Type Definitions

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

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

<type name="ur-type" content="mixed">
 <any/>
 <anyAttribute/>
</type>

3.7 Unique, key and key reference constraints

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

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

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

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

• Not just attribute values, but also element content and combinations of values and content can be declared to be unique;
• Constraints can be specified to have document-wide scope or to hold within the scope of particular elements;
• (Combinations of) attribute values and/or element content can be declared to be keys, that is, not only unique, but always present and non-nullable.

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

field specifies an XPath expression relative to each element selected by a selector. This must identify a single node (element or attribute, not necessarily within the selected element) whose content or value, which must be of a simple type, is used in the constraint. It is possible to specify an ordered list of fields, to cater to multi-field keys, keyrefs, and uniqueness constraints. A field must not evaluate to the same element or attribute as any other field in a given instance of a generalConstraint.

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

Issue (restrictConstrXPaths): Xpaths can take arbitrarily complicated forms and it is unnecessary to burden XML Schema implementations with supporting every feature of XPath. The XPaths in selector and field should be restricted to certain specified simple forms.

Issue (fieldOnlyKeyref): Should the selector be made optional in a keyref, with default the element it's contained within?

Issue (islandValidConstraint): What are the implications of constraints if we support island validation constraints?

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

NOTE: If reference to a key or unique defined in a scoping element which may occur more than once is envisaged, then the scoping elements themselves must have keys (typically with global scope), and the scoped keys must include the key of their scoping element among their fields.

Example

<element name="state"> <type> <element name="stateCode" type="twoLetterCode"/> <element name="vehicle"> <type> . . . <attribute name="regNo" type="integer"/> </type> </element> . . . </type> </element> <key name="regKey"> <selector>.//vehicle[@regNo]</selector> <field>@regNo</field> <field>ancestor::state/stateCode</field> <!-- scope needs to be involved --> </key> <element name="person"> <type> . . . <element name="car"> <type model="empty"> . . . <attribute name="regRef" type="integer"/> <attribute name="regState" type="twoLetterCode"/> </type> </element> </type> <keyref name="carRef" refer="regKey"> <selector>.//car[@regRef]</selector> <field>@regRef</field> <field>../person/@regState</field> </keyref> </element> A state element is defined, which inter alia contains a stateCode descendant and some vehicle descendants. A vehicle in turn has a regNo attribute, which is an integer. The combination of stateCode and regNo is asserted to be a key for vehicle within state. Furthermore, a person element has inter-alia an empty car element, with regRef and regState attributes, which are then asserted together to refer to vehicles via the regKey constraint.

3.8 Notations

4.1 Layer 1: Summary of the schema-validation core

Ed. Note: Some of this text will probably end up in Chapter 6

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

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

As specified above, each schema component is associated directly or indirectly with a target namespace, or explicitly with no namespace. In the case of multi-namespace documents, components for more than one target namespace will co-exist in the complete component set.

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

• The processor succeed in locating the definitions and declarations transitively required to complete a validation;
• that no definition or declaration changes once it has been located;
• If the processor chooses to acquire declarations and definitions dynamically, that there be no side effects of such dynamic acquisition that would cause the results of validation to differ from that which would have been obtained from the same schema components acquired in bulk.

NOTE: the validation core is defined in terms of the schema components comprising a complete component set; no mention is made of the schema definition syntax (i.e. <schema>). Although many processors will acquire schemas in this format, others may operate on compiled representations, on a programmatic representation as exposed in some programming language, etc.

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

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

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

4.2 Layer 2: Schema definitions in XML

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

NOTE: The two following sections relate to assembling the complete component set for validation from multiple sources. They should not be understood as a form of text substitution, but rather as providing mechanisms for distributed definition of schema components, with appropriate schema-specific semantics.

Ed. Note: "schemaLocation" really belongs at layer 3 . . .

4.3 Layer 3: Web-interoperability

Layers 1 and 2 provide a framework for validation and XML definition of schemas in a broad variety of environments. Over time, we expect that a range of standards and conventions will evolve to support interoperability of XML Schema implementations on the World Wide Web. Layer 3 defines the minimum level of function required of all conformant processors operating on the Web: it is intended that, over time, future standards (e.g. XML Packages) for interoperability on the Web and in other environments can be introduced without the need to republish this specification.

NOTE: The core validation architecture requires that the complete component set of appropriate declarations for each global element and attribute be available. This requires may involve both resolving both instance->schema and schema->schema references. As observed above, we anticipate that the precise mechanisms for resolving such references will evolve over time. In support of such evolution, we have attempted to observe the design principle that references from one schema to another use mechanisms that directly parallel those used to reference a schema from an instance document.

 <stylesheet xmlns="http://www.w3.org/1999/Style/Transform"
            xmlns:html="http://www.w3.org/1999/XHTML"
            xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance"
            xsi:schemaLocation="http://www.w3.org/1999/Style/Transform
                                http://www.w3.org/1999/Style/Transform/xslt.xsd
                                http://www.w3.org/1999/XHTML
                                http://www.w3.org/1999/XHTML/xhtml.xsd"

6.1 Schema Validity *

NOTE: This section is in the process of being redrafted, and is not guaranteed to be coherent yet. The material after the stale below here editorial note is in many cases out of sync with the material above in sections 3 and 4.

We use the terms schema and type definition and perhaps others in more careful way than has been the case heretofore, reserving them for abstract datatypes with content as per the abstract syntax, as opposed to XML elements per the concrete syntax. This change will have to be reflected upwards in due course.

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 XML information set and information item. Please note that the formal definitions below are explicitly not couched in processing terms: they describe properties of an information set, but do not tell you how to check an information set to see if it has those properties.

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

First we define our terms:

[Definition:]  An EII is an element information item from an XML information set which conforms to [XML-Infoset] with Namespace processing.

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

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

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

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

• The type definition is simple and
• the EII's attribute set is empty and
• the EII's content list contains no element information items and
• the string formed by concatenating the characters of each of the character information items in the EII's content list, if any, or else the empty string, is an instance of the effective stype defined by the simple type definition's datatypeDefn with respect to the set of schemas.

or

• The type definition is complex (use the name ECT for the effective ctype as defined by the complex type definition's typeDefn with respect to the set of schemas) and
• the EII's attribute set is an instance of ECT's attribute set and
• the sequence of information items consisting of the element information items and character information items in the EII's content list is an instance of ECT's content type with respect to the type definition's TNS and the set of schemas.

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

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

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

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

Ed. Note: The formal nature of a complex type is slightly different to that of a simple type. A simple type is a 3-tuple of value space, lexical space and facets. A value space is a (possibly infinite) set of values, a lexical space is a (possibly infinite) set of strings. A complex type is a (possibly infinite) set of element information items. These items form equivalence classes as a result of the optionality of some properties of information items: a pair of information items whose required properties are equivalent are themselves equivalent. A complex type is defined by a set of constraints which must be satisfied by every member of that type.

Ed. Note: We can either think in terms of shallow validity, which only requires a type definition, and checks that all attribute II and daughter EII names are as they should be, and full (recursive) validity in which the types of those attribute IIs and daughter EIIs are also checked. Alas because of element references in content models the schema set parameterises BOTH of those, I was hoping shallow was just a matter for the type. . .

Ed. Note: ************ STALE BELOW HERE *************

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)

or

• 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

or

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

Ed. Note: All this has to go, now that we don't provide for entity definition or substitution.

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

The Expansions Schema-Ready (§6.2.7) Schema Validity Constraint obtains.

The Ungoverned RUE (§6.2.7) Schema Validity Constraint obtains.

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

[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 declarations 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 Detailed validity constraints and definitions *

6.3 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.
   • Schema-validate the resulting information set, as described in Schema Validity * (§6.1);
   • 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 type, 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 datatype (and type lattice), whether its presence is required, and its lexical constraints.
     • for each type: 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: its name, its datatype or type 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 elements -- 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.4 Lexical representation *

NOTE: The editors did not get to this.

6.5 Information set *

NOTE: The editors did not get to this.