W3C

XML Schema Part 1: Structures

W3C Working Draft 25 February 2000

This version:
http://www.w3.org/TR/2000/WD-xmlschema-1-20000225/
(in XML (with its own DTD, XSL stylesheet (Nov REC version) and IE5 stylesheet (XSL as supported by version 5 of Microsoft's Internet Explorer)) and HTML, with separate provision of the schema and DTD for schemas described herein.
Latest version:
http://www.w3.org/TR/xmlschema-1/
Previous versions:
http://www.w3.org/TR/1999/WD-xmlschema-1-19991217/
http://www.w3.org/TR/1999/WD-xmlschema-1-19991105/
http://www.w3.org/TR/1999/WD-xmlschema-1-19990924/
http://www.w3.org/1999/05/06-xmlschema-1/
Editors:
Henry S. Thompson (University of Edinburgh) <ht@cogsci.ed.ac.uk>
David Beech (Oracle Corp.) <dbeech@us.oracle.com>
Murray Maloney (Commerce One) <murray@muzmo.com>
Noah Mendelsohn (Lotus Development Corporation) <Noah_Mendelsohn@lotus.com>

Copyright ©1999-2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.


Abstract

XML Schema: Structures specifies the XML Schema definition language, which offers facilities for describing the structure and constraining the contents of XML 1.0 documents. The schema language, which is itself represented in XML 1.0, provides a superset of the capabilities found in XML 1.0 document type definitions (DTDs). This specification depends on XML Schema Part 2: Datatypes.

Status of this document

This is a public working draft of XML Schema 1.0 for review by the public and by members of the World Wide Web Consortium.

It has been reviewed by the XML Schema Working Group, and the Working Group has agreed to its publication. The WG believes this draft to be `feature-complete': the functionality included here is substantially complete and is expected to be stable. We do not expect to add major new functionality, or to make major changes to the functionality described in this draft. Some sections of the draft (in particular those on conformance), and some aspects of the design (in particular details of the transfer syntax for schemas), on the other hand, are still rough and are expected to be revised.

Following a period of review and polishing, it is the WG's intent to issue a Last Call for Review by other W3C working groups sometime during March, 2000, and to submit this specification thereafter for publication as a Candidate Recommendation. This schedule may vary, depending on the comments of the public and of other W3C working groups on this draft. Such comments are instrumental in the WG's deliberations, and we encourage readers to review the draft and send comments to www-xml-schema-comments@w3.org

This working draft has been substantially restructured since the previous public release. This structural reorganisation is not yet complete. In this draft, unrestructured material is distinguished as follows:

[Unrestructured material elided]

The restructuring of Chapters 1 through 3 is largely completed: Attributes and Attribute groups give the clearest picture of how Chapters 5 and 6 will eventually look.

The lengthy introductory example material from the old Chapter 2 has been moved out of line into a non-normative companion document ([XML Schema: Exposition] and expanded considerably. Pointers to this will in due course be added to this document.

Although the Working Group does not anticipate further substantial changes to the functionality described here, this is still a working draft, subject to change. The present version should be implemented only by those interested in providing a check on its design or by those preparing for an implementation of the Candidate Recommendation. The Schema WG will not allow early implementation to constrain its ability to make changes to this specification prior to final release.

A list of current W3C working drafts can be found at http://www.w3.org/TR/. They may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress".

Table of contents

1 Introduction
    1.1 Purpose
    1.2 Dependencies on Other Specifications
    1.3 Documentation Conventions and Terminology
2 Conceptual Framework
    2.1 Overview of XML Schema
    2.2 XML Schema Abstract Data Model
        2.2.1 Type Definition Components
            2.2.1.1 Type Definition Hierarchy
            2.2.1.2 Simple Type Definition
            2.2.1.3 Complex Type Definition
        2.2.2 Declaration Components
            2.2.2.1 Element Declaration
            2.2.2.2 Element Equivalence Class
            2.2.2.3 Attribute Declaration
            2.2.2.4 Notation Declaration
        2.2.3 Model Group Components
            2.2.3.1 Model Group
            2.2.3.2 Particle
            2.2.3.3 Wildcard
        2.2.4 Identity-constraint Definition Components
        2.2.5 Group Definition Components
            2.2.5.1 Model Group Definition
            2.2.5.2 Attribute Group Definition
        2.2.6 Annotation Components
    2.3 Constraints and Contributions
    2.4 Conformance
    2.5 Names and Symbol Spaces
    2.6 Schema-Related Markup in Documents Being Schema-Validated
        2.6.1 xsi:type
        2.6.2 xsi:null
        2.6.3 xsi:schemaLocation
    2.7 Representation of Schemas on the World Wide Web
3 Schema Component Details
    3.1 Attribute Declaration Details
    3.2 Element Declaration Details
    3.3 Complex Type Definition Details
    3.4 Attribute Group Definition Details
    3.5 Model Group Definition Details
    3.6 Model Group Details
    3.7 Particle Details
    3.8 Wildcard Details
    3.9 Identity-constraint Definition Details
    3.10 Notation Declaration Details
    3.11 Annotation Details
    3.12 Simple Type Definition Details
4 XML Representation of Schemas and Schema Components
    4.1 XML Representations of Schemas
    4.2 The Document and its Root
    4.3 References to Schema Components
        4.3.1 References to Schema Components from Elsewhere
    4.4 XML Representation of Schema Components
        4.4.1 XML Representation of Attribute Declaration Schema Components
        4.4.2 XML Representation of Element Declaration Schema Components
        4.4.3 XML Representation of Complex Type Definition Schema Components
        4.4.4 XML Representation of Attribute Group Definition Schema Components
        4.4.5 XML Representation of Model Group Definition Schema Components
        4.4.6 XML Representation of Model Group Schema Components
        4.4.7 XML Representation of Wildcard Schema Components
        4.4.8 XML Representation of Identity-constraint Definition Schema Components
        4.4.9 XML Representation of Notation Declaration Schema Components
        4.4.10 XML Representation of Annotation Schema Components
        4.4.11 XML Representation of Simple Type Definition Schema Components
5 Schema Access and Composition
    5.1 Layer 1: Summary of the schema-validation core
    5.2 Layer 2: Schema definitions in XML
        5.2.1 Assembling a schema for a single namespace from multiple schema definition documents
        5.2.2 References to schema components across namespaces
    5.3 Layer 3: Web-interoperability
        5.3.1 Standards for representation and retrieval of schema definitions on the Web
        5.3.2 How schema definitions are located on the Web
6 Conformance *
    6.1 Schema Validity *
    6.2 Missing Sub-components
    6.3 Detailed Validity Constraints on Schema Components *
        6.3.1 Attribute Declaration Constraints
        6.3.2 Element Declaration Constraints
        6.3.3 Identity-constraint Definition Constraints
        6.3.4 Attribute Group Definition Constraints
        6.3.5 Wildcard Constraints
        6.3.6 Model Group Definition Constraints
        6.3.7 Model Group Constraints
        6.3.8 Notation Constraints
        6.3.9 Annotation Constraints
        6.3.10 Particle Constraints
        6.3.11 Complex Type Definition Constraints
        6.3.12 Simple Type Definition Constraints
        6.3.13 The Schema *
        6.3.14 References to Schema Components *
        6.3.15 Types, Elements and Attributes *
            6.3.15.1 Datatypes *
            6.3.15.2 Type Definition *
            6.3.15.3 Attribute Declaration *
            6.3.15.4 Element Content Model *
            6.3.15.5 Mixed Content *
            6.3.15.6 Element-only Content *
            6.3.15.7 Element Declaration *
        6.3.16 Type Refinement *
        6.3.17 Import Restrictions *
        6.3.18 Schema Inclusion *
        6.3.19 Schema Validity *
    6.4 Responsibilities of Schema-aware processors *

Appendices

A (normative) Schema for Schemas
B (normative) DTD for Schemas
C Glossary (normative) *
D References (normative) *
E Acknowledgements (non-normative)
F Tabulation of changes
G Open Issues

1 Introduction

This document sets out the structural part (XML Schema: Structures) of the XML Schema definition language.

Chapter 2 presents a Conceptual Framework (§2) for XML Schemas, including an introduction to the nature of XML Schemas and a formal specification of the XML Schema abstract data model, along with other terminology used throughout this document.

Chapter 3, Schema Component Details (§3), specifies the precise semantics of each component of the abstract model.

Chapter 4, XML Representation of Schemas and Schema Components (§4), presents the XML representation that maps to the abstract model, in the form of a DTD and XML Schema for an XML Schema document type, along with rules and conventions for identifying the components needed for any particular validation.

Chapter 5 presents Schema Access and Composition (§5), including the connection between documents and schemas, the import and inclusion of declarations and definitions and the foundations of schema-validity.

Chapter 6 discusses Conformance * (§6), including the rules by which documents are validated, and responsibilities of schema-aware processors.

The normative appendices include a (normative) DTD for Schemas (§B) and a (normative) Schema for Schemas (§A) for the transfer syntax, a Glossary (normative) * (§C) [not yet written] and References (normative) * (§D).

1.1 Purpose

The purpose of XML Schema: Structures is to define the nature of XML schemas and their component parts, provide an inventory of XML markup constructs with which to represent schemas, and define the application of schemas to XML documents.

The purpose of an XML Schema: Structures schema is to define and describe a class of XML documents by using schema components to constrain and document the meaning, usage and relationships of their constituent parts: datatypes, elements and their content and attributes and their values. Schemas may also provide for the specification of additional document information, such as default values for attributes and elements. Schemas have facilities for self-documentation. 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 allows 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.2 Dependencies on Other Specifications

The definition of XML Schema: Structures depends on the following specifications: [URI], [XML-Infoset], [XML-Namespaces], [XPath], and [XML Schemas: Datatypes].

1.3 Documentation Conventions and Terminology

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

Special terms are defined at their point of introduction in the text; hyperlinks connect other uses of the term to the definition. For example, a definition of term might read: [Definition:]  A term is something we use a lot. The definition is labeled as such and the term is highlighted typographically. The end of the definition is not specially marked in the displayed or printed text.

The following terms are used in building definitions and describing the actions of XML Schema: Structures processors:

[Definition:]  may
Conforming documents and processors are permitted to but need not behave as described.

[Unrestructured material elided]

Non-normative examples are set off typographically and accompanied by a brief explanation:

Example
<schema
        targetNamespace="http://www.muzmo.com/XMLSchema/1.0/mySchema" >
And an explanation of the example.

The definition of each kind of schema component consists of a list of its properties and their contents, followed by descriptions of the semantics of the properties:

Schema ComponentExample
[example property]
Definition of the property.

The correspondence between an element information item which is part of the XML representation of a schema and one or more schema components is presented in a tableau which illustrates the element information item(s) involved, followed by a tabulation of the correspondence between properties of the component and properties of the information item. Where context may determine which of several different components may arise, several tabulations, one per component, are given. In the XML representation, bold-face attribute names (e.g. count below) indicate a required attribute information item, and the rest are optional. Where an attribute information item has an enumerated type definition, the values are shown separated by vertical bars, as for size below; if there is a default value, it is shown following a colon. The allowed content of the information item is shown as a grammar fragment, using the Kleene operators ?, * and +. The property correspondences are normative, but the illustration of the XML representation element information items is not.

XML Representation Summaryexample Element Information Item

<example
  count = integer
  size = large | medium | small : medium>
  Content: (child1 | child2*)
</example>

Example Schema Component
PropertyRepresentation
{example property}Description of what the property corresponds to, e.g. the value of the size [attribute]

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

NOTE: General comments directed to all readers.

2 Conceptual Framework

This chapter gives an overview of XML Schema: Structures at the level of its abstract data model. (Schema Component Details (§3) provides details on this model, and subsequent chapters define a normative representation in XML for the components of the model.) Readers interested primarily in learning to write schema documents may wish to first read [XML Schema: Exposition] and then consult XML Representation of Schemas and Schema Components (§4), using the sections below as a guide to the underlying formal structure of the schema language.

2.1 Overview of XML Schema

An XML Schema defines a set of schema-valid XML documents. At a minimum, it consists of type definitions and element declarations. It identifies a set of well-formed element information items (as defined in [XML-Infoset]), and furthermore may specify augmentations to those items and their descendants. This augmentation makes explicit information which may have been implicit in the original document, such as default values for attributes and elements and the types of element and attribute information items.

The process of schema validation consists of determining whether an element information item is a member of the set defined by an XML Schema, and if so of adding any appropriate augmentations.

2.2 XML Schema Abstract Data Model

This specification builds on [XML] and [XML-Namespaces]. The concepts and definitions used herein regarding XML are framed at the abstract level of information items as defined in [XML-Infoset]. By definition, this use of the infoset provides a priori guarantees of well-formedness (as defined in [XML]) and namespace conformance (as defined in [XML-Namespaces]) for all candidates for schema-validity.

Just as [XML] and [XML-Namespaces] can be described in terms of information items, XML Schemas can be described in terms of an abstract data model. In defining XML Schemas in terms of an abstract data model, this specification rigorously specifies the information which must be available to a conforming XML Schema processor. The abstract model for schemas is conceptual only, and does not mandate any particular implementation or representation of this information. To facilitate interoperation and sharing of schema information, a normative interchange format for schemas is described in XML Representation of Schemas and Schema Components (§4)

Ed. Note: The datatype spec's use of the word "component" makes things somewhat confusing next to this specification's use of the same word. Perhaps the terminology in the datatype spec should be revised?

[Definition:]   Schema component is the generic term for the building blocks that comprise the abstract data model of the schema. [Definition:]   An XML Schema is a set of schema components. There are 12 kinds of component in all, falling into three groups. The primary components are as follows. They may have names, and (except for some element declarations) may be independently accessed:

The secondary components are as follows. Like the primary components, they may have names and be independently accessed:

Finally, the "helper" components provide small parts of other components; they are not independent of their context and cannot be independently accessed:

During validation, [Definition:]  Declaration components are associated by (qualified) name to information items being validated.

On the other hand, [Definition:]  definition components define internal schema components that can be used in other schema components.

[Definition:]  Declarations and definitions may have and be identified by names, which are NCNames as defined by [XML-Namespaces].

[Definition:]  Several kinds of component have a target namespace, which is either null or a namespace URI, also as defined by [XML-Namespaces]. The target namespace serves to identify the namespace within which the association between the component and its name exists. In the case of declarations, this in turn determines the namespace URI of, for example, the element information items it may validate.

NOTE: At the abstract level, there is no requirement that the components of a schema share a target namespace. Any schema for use in schema-validation of documents containing names from more than one namespace will of necessity include components with different target namespaces. This contrasts with the situation at the level of the XML Representation of Schemas and Schema Components (§4), in which each schema document contributes definitions and declarations to a single target namespace.

Schema-validity, defined in detail in Conformance * (§6), is a relation between information items and schema components. For example, an attribute information item may be schema-valid with respect to an attribute declaration, a list of element information items may be schema-valid with respect to a content model, and so on. The following sections briefly introduce the kinds of components in the schema abstract data model, other major features of the abstract model, and how they contribute to the overall definition of schema-validity.

2.2.1 Type Definition Components

The abstract model provides two kinds of type definition component: simple and complex.

[Definition:]  This specification uses the phrase type definition in cases where no distinction need be made between simple and complex types.

Type definitions form a hierarchy with a single root. First we describe characteristics of that hierarchy, then provide an introduction to simple and complex type definitions themselves.

2.2.1.1 Type Definition Hierarchy

[Definition:]  Except for a distinguished ur-type definition, every type definition is, by construction, either a restriction, an extension of some other type definition. Collectively, the graph of these relationships forms a tree known as the Type Definition Hierarchy.

[Definition:]  A type definition whose declarations or facets are in a one-to-one relation with those of another type definition, with each in turn restricting the possibilities of the one it corresponds to, is said to be a restriction. The specific restrictions might include narrowed ranges or reduced alternatives. Members of a type, A, whose definition is a restriction of the definition of another type, B, are always members of type B as well.

[Definition:]  A complex type definition which allows element or attribute content in addition to that allowed by another type definition is said to be an extension.

[Definition:]  A distinguished ur-type definition is present in each XML Schema, serving as the root of the type definition hierarchy for that schema. The ur-type definition has the unique characteristic that it can function as a complex or a simple type definition, according to context. Specifically, restrictions of the ur-type definition can themselves be either simple or complex type definitions.

[Definition:]  A type definition used as the basis for an extension or restriction is known as the base type definition of that definition.

Ed. Note: Should use this as a target for other references throughout the text.

2.2.1.2 Simple Type Definition

A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the [children] of an attribute information item or of an element information item with no element children. Informally, it applies to attribute values and text-only content of elements.

Each simple type definition, whether built-in (that is, defined in [XML Schemas: Datatypes]) or user-defined, is a restriction of some particular simple base type definition, which can be the ur-type definition.

For details on the composition and schema-validation contributions of simple type definitions, see Simple Type Definition Details (§3.12) and [XML Schemas: Datatypes]. The latter also defines an extensive inventory of pre-defined simple types. See XML Representation of Simple Type Definition Schema Components (§4.4.11) for the XML representation of simple type definitions, and Simple Type Definition Constraints (§6.3.12) for constraints on simple type definition components as such.

2.2.1.3 Complex Type Definition

A complex type definition is a set of attribute declarations and a content type, applicable to the [attributes] and [children] of an element information item respectively. The content type may require the [children] to be empty, to be a string which is schema-valid with respect to particular simple type or to contain element information items which is schema-valid with respect to a particular model group, with or without character information items as well.

Each is complex type definition is either a:

A complex type which extends another does so by having additional content model particles at the end of the other definition's content model, or by having additional attribute declarations, or both.

NOTE: This specification allows only appending, and not other kinds of extensions. This decision simplifies application processing required to cast instances from derived to base type. Future versions may allow more kinds of extension, requiring more complex transformations to effect casting.

See Complex Type Definition Details (§3.3) for the composition and schema-validation contributions of complex type definition schema components, XML Representation of Complex Type Definition Schema Components (§4.4.3) for the XML representation of complex type definitions and Complex Type Definition Constraints (§6.3.11) for constraints on complex type definition components as such.

2.2.2 Declaration Components

There are three kinds of declaration component: element, attribute, and notation. Each described in a section below. Also included is a discussion of element equivalence classes, which is a feature provided in conjunction with element declarations.

2.2.2.1 Element Declaration

An element declaration is an association of a name with a type definition, either simple or complex, an (optional) default value and a set of identity-constraint definitions. The association is either global or scoped to a containing complex type definition. A global element declaration with name 'A' is broadly comparable to a pair of DTD declarations as follows, where the associated type definition fills in the ellipsis:

<!ELEMENT A . . .>
<!ATTLIST A . . .>

Element declarations contribute to schema-validity as part of model group validation, when their defaults and type components are checked against an element information item with a matching name and namespace, and by triggering identity-constraint definition validation.

See Element Declaration Details (§3.2) for the composition and schema-validation contributions of element declaration schema components, XML Representation of Element Declaration Schema Components (§4.4.2) for the XML representation of element declarations and Element Declaration Constraints (§6.3.2) for constraints on element declaration components as such.

2.2.2.2 Element Equivalence Class

In XML 1.0, the name and content of an element must correspond exactly to the element type referenced in the corresponding content model.

[Definition:]  Through the new mechanism of element equivalence classes, XML Schemas provides a more powerful model supporting substitution of one named element for another. Any global element declaration can serve as the defining element, or exemplar, for an element equivalence class. Other global element declarations, regardless of target namespace, can be designated as members of the class defined by the exemplar. In a suitably enabled content model, a reference to the exemplar validates not just the exemplar itself, but elements corresponding to any member of the equivalence class as well.

All such members must have type definitions which are either the same as the exemplar's type definition or restrictions or extensions of it. Therefore, although the names of elements can vary widely as new namespaces and members of the equivalence class are defined, the content of member elements is strictly limited according to the type definition of the equivalence class exemplar.

Note that element equivalence classes are not represented as separate components. They are specified in the property values for element declarations (see Element Declaration (§2.2.2.1)).

2.2.2.3 Attribute Declaration

An attribute declaration is an association between a name and a simple type definition, together with occurrence information and (optionally) a default value. The association is local to its containing complex type definition. Attribute declarations contribute to schema-validity as part of complex type definition validation, when their occurrence, defaults and type components are checked against an attribute information item with a matching name and namespace.

See Attribute Declaration Details (§3.1) for the composition and schema validation contributions of attribute declaration schema components, XML Representation of Attribute Declaration Schema Components (§4.4.1) for the XML representation of attribute declarations and Attribute Declaration Constraints (§6.3.1) for constraints on attribute declaration components as such.

2.2.2.4 Notation Declaration

A notation declaration is an association between a name and an identifier for a notation. For an attribute information item to be schema-valid with respect to a NOTATION simple type definition, its value must have been declared with a notation declaration.

See Notation Declaration Details (§3.10) for the composition and schema validation contributions of notation declaration schema components, XML Representation of Notation Declaration Schema Components (§4.4.9) for the XML representation of notation declarations and Notation Constraints (§6.3.8) for constraints on notation declaration components as such.

2.2.3 Model Group Components

The model group, particle, and wildcard components contribute to the portion of a complex type definition that controls an element information item's content type.

2.2.3.1 Model Group

A model group is a constraint in the form of a grammar fragment that applies to lists of element information items. It consists of a list of particles, i.e. element declarations, wildcards and model groups. There are three varieties of model group:

  • Sequence (the element information items match the particles in sequential order)
  • Conjunction (the element information items match the particles, in any order)
  • Disjunction (the element information items match one of the particles)

See Model Group Details (§3.6) for the composition and schema-validation contributions of model group schema components, Complex Type Definition Details (§3.3) for the use of model groups as content models, XML Representation of Model Group Schema Components (§4.4.6) for the XML representation of model groups and Model Group Constraints (§6.3.7) for constraints on model group components as such.

2.2.3.2 Particle

A particle is a term in the grammar for element content, consisting of either an element declaration, a wildcard or a model group, together with occurrence constraints. Particles contribute to schema-validity as part of complex type validation, when they allow anywhere from zero to many element information items or sequences thereof, depending on their contents and occurrence constraints.

[Definition:]  A particle can be used in a complex type definition to express a validity constraint on the [children] of an element information item; such a particle is called a content model.

NOTE: XML Schema: Structures content models are similar to but more expressive than [XML] content models; unlike [XML], XML Schema: Structures applies content models to the validation of both mixed and element-only content.

See Particle Details (§3.7) for the composition and schema-validation contributions of particle schema components, XML Representation of Model Group Schema Components (§4.4.6) for the XML representation of particles and Particle Constraints (§6.3.10) for constraints on particle components as such.

2.2.3.3 Wildcard

A wildcard is a special kind of particle which matches element information items dependent on their namespace URI, independently of their local names.

See Wildcard Details (§3.8) for the composition and schema-validation contributions of wildcard schema components, XML Representation of Wildcard Schema Components (§4.4.7) for the XML representation of wildcards and Wildcard Constraints (§6.3.5) for constraints on wildcard components as such.

2.2.4 Identity-constraint Definition Components

A identity-constraint definition is an association between a name and one of several varieties of identity-constraint related to uniqueness and reference. All the varieties use [XPath] expressions to pick out sets of information items relative to particular target element information items which are unique, or a key, or a valid reference, within a specified scope. An element information item is only schema-valid with respect to an element declaration with identity-constraint definitions if those definitions are all satisfied for all the descendants of that element information item which they pick out.

See Identity-constraint Definition Details (§3.9) for the composition and schema-validation contributions of identity-constraint definition schema components, XML Representation of Identity-constraint Definition Schema Components (§4.4.8) for the XML representation of identity-constraint definitions and Identity-constraint Definition Constraints (§6.3.3) for constraints on identity-constraint definition components as such.

2.2.5 Group Definition Components

There are two kinds of convenience definitions available for use in reusing pieces of complex type definitions: model group definitions and attribute group definitions.

2.2.5.1 Model Group Definition

A model group definition is an association between a name and a model group, for use in reusing the same model group in several complex type definitions.

See Model Group Definition Details (§3.5) for the composition and schema validation contributions of model group definition schema components, XML Representation of Model Group Definition Schema Components (§4.4.5) for the XML representation of model group definitions and Model Group Definition Constraints (§6.3.6) for constraints on model group definition components as such.

2.2.5.2 Attribute Group Definition

An attribute group definition is an association between a name and a set of attribute declarations, for use in reusing the same set in several complex type definitions.

See Attribute Group Definition Details (§3.4) for the composition and schema-validation contributions of attribute group definition schema components, XML Representation of Attribute Group Definition Schema Components (§4.4.4) for the XML representation of attribute group definitions and Attribute Group Definition Constraints (§6.3.4) for constraints on attribute group definition components as such.

2.2.6 Annotation Components

An annotation is information for human and/or mechanical consumers. The interpretation of such information is not defined in this specification.

See Annotation Details (§3.11) for the composition and schema-validation contributions of annotation schema components, XML Representation of Annotation Schema Components (§4.4.10) for the XML representation of annotations and Annotation Constraints (§6.3.9) for constraints on annotation components as such.

Ed. Note: We need a Chapter 2 intro to the interchange syntax.

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

The preceding section focussed on schema-validity, that is the constraints on information items which schema components supply. In fact however this specification provides four different kinds of normative statements about schema components, their representations in XML and their contribution to the schema-validation of information items:

[Definition:]  Constraint on Schemas
Constraints on the schema components themselves, i.e. conditions components must satisfy to be components at all. Largely to be found in Conformance * (§6).
[Definition:]  Schema Representation Constraint
Constraints on the representation of schema components in XML. Some but not all of these are expressed in (normative) DTD for Schemas (§B) and (normative) Schema for Schemas (§A). Largely to be found in XML Representation of Schemas and Schema Components (§4).
[Definition:]  Validity Contribution
Constraints expressed by schema components which information items must satisfy to be schema-valid. Largely to be found in Schema Component Details (§3).
[Definition:]  Schema Information Set Contribution
Augmentations to post-schema-validation information sets expressed by schema components, which follow as a consequence of schema-validation. Largely to be found in Schema Component Details (§3).

Schema information set contributions are not new. XML 1.0 validation augments the XML 1.0 information set in similar ways, for example by providing values for attributes not present in instances, and by implicitly exploiting type information for normalisation or access. (As an example of the latter case, consider the effect of NMTOKENS on attribute whitespace, and the semantics of ID and IDREF.) By including schema information set contributions, this specification makes explicit some features that XML 1.0 left implicit.

2.4 Conformance

This specification describes three levels of conformance for schema aware processors. The first is required of all processors. Support for the other two will depend on the application environments for which the processor is intended.

[Definition:]  Minimally conforming processors must completely and correctly implement the Constraints on Schemas, Validity Contributions, and Schema Information Set Contributions contained in this specification.

[Definition:]  Processors which accept schemas in the form of XML documents as described in XML Representation of Schemas and Schema Components (§4) are additionally said to provide conformance to the XML Representation of Schemas. Such processors must, when processing schema documents, completely and correctly implement all Schema Representation Constraints in this specification, and must adhere exactly to the specifications in XML Representation of Schemas and Schema Components (§4) for mapping the contents of such documents to schema components for use in validation.

NOTE: By separating the conformance requirements relating to the concrete syntax of XML schema documents, this specification admits processors which validate using schemas stored in optimised binary representations, dynamically created schemas represented as programming language data structures, or implementations in which particular schemas are compiled into executable code such as C or Java. Such processors can be said to be minimally conforming but not necessarily in conformance to the XML Representation of Schemas.

[Definition:]   Fully conforming processors are network-enabled processors which support both levels of conformance described above, and which must additionally be capable of accessing schema documents from the World Wide Web according to Representation of Schemas on the World Wide Web (§2.7) and XXX. .

Ed. Note: A a reference to the rules for handling schema location, dereference of namespace Uris, etc.

NOTE: Although this specification provides just these three standard levels of conformance, it is anticipated that other conventions can be established in the future. For example, the World Wide Web Consortium is considering conventions for packaging on the Web a variety of resources relating to individual documents and namespaces. Should such developments lead to new conventions for representing schemas, or for accessing them on the Web, new levels of conformance can be established and named at that time. There is no need to modify or republish this recommendation to define such additional levels of conformance.

2.5 Names and Symbol Spaces

As discussed in XML Schema Abstract Data Model (§2.2), most schema components (may) have names. If all such names were assigned from the same "pool", then it would be impossible to have, for example, a simple type definition and an element declaration both with the name "title" in a given target namespace.

This specification therefore introduces the term [Definition:]  symbol space to represent a collection of names, each of which is unique with respect to the others. 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 target namespace for each kind of definition and declaration component identified in XML Schema Abstract Data Model (§2.2), except that within a target namespace, simple type definitions and complex type definitions share a symbol space. Within a given symbol space, names are unique, but the same name may appear in more than one symbol space without conflict. For example, the same name can appear in both a type definition and an element declaration, without conflict or necessary relation between the two.

Attribute declarations and locally scoped element declarations are special with regard to symbol spaces. Every complex type definition defines its own attribute declaration symbol space and local element declaration symbol space, where these symbol spaces are distinct from each other and from any of the other symbol spaces. So, for example, several complex type definitions having the same target namespace can contain an attribute declaration for the unqualified name "priority", or contain a local element declaration for the name "address", without conflict or necessary relation between the two.

2.6 Schema-Related Markup in Documents Being Schema-Validated

The XML representation of schema components uses a vocabulary identified by the namespace URI http://www.w3.org/1999/XMLSchema. XML Schema: Structures also defines several attributes for direct use in XML documents. These attributes are in a different namespace, which has the namespace URI http://www.w3.org/1999/XMLSchema/instance. For brevity, the text and examples in this specification use the prefix xsi: to stand for this latter namespace; in practice, any prefix can be used.

2.6.1 xsi:type

The Simple Type Definition (§2.2.1.2) or Complex Type Definition (§2.2.1.3) used to validate an element is usually determined by reference to the appropriate schema components. However, when permitted by those components, an element can explicitly assert its type using the attribute xsi:type. The value of this attribute is a QName; see QName Interpretation (§4.3) for the means by which the QName is associated with a type definition.

2.6.2 xsi:null

XML Schema: Structures introduces a distinguished null value for XML document elements. An element has the null value if it has no [children] and carries the attribute xsi:null.

Ed. Note: Are other attributes allowed? Must sync with validation rules.

2.6.3 xsi:schemaLocation

The xsi:schemaLocation attribute can be used in a document to provide hints as to the physical location of schema documents to be used for validation.

2.7 Representation of Schemas on the World Wide Web

On the World Wide Web, schemas are conventionally represented as documents of MIME type "text/xml", conforming to the specifications in XML Representation of Schemas and Schema Components (§4).

3 Schema Component Details

The following sections provide full details on the properties and significance of each kind of schema component. For each property, its range, that is the kinds of values it may have, is defined. This can be understood as defining a schema as a labelled directed graph, where every vertex is a schema component or a literal (string, boolean, number) and every labelled edge a property. Any property not identified as optional is required to be present, optional properties which are absent are taken to have null as their value. Any property identified as a having a set, subset or list value may have an empty value unless this is explicitly ruled out: this is not the same as null. Any property value identified as subset of some set may be equal to that set, unless a proper subset is explicitly called for. By 'string' here and below is meant a sequence of ISO 10646 character codes identified as legal XML character codes in [XML].

Ed. Note: Or the UNICODE 3 addendum, where/when?

Throughout the following sections, when we refer to the [value] of some attribute information item, we mean by this a string composed of, in order, the [character code] of each character information item in the [children] of that attribute information item.

Many properties of schema components are identified below as having other schema components as values. For the purposes of exposition, the definitions in this section assume that (unless the property is explicitly identified as optional) all such values are in fact present. When schema components are constructed from XML representations involving reference by name to other components, this assumption may be violated if one or more references cannot be discharged. This specification addresses the matter of missing components in a uniform manner, described in Missing Sub-components (§6.2): no mention of handling missing components will be found in the individual component descriptions below.

NOTE: Schema components are an idealisation of the information a schema-aware processor requires: implementations are not constrained in how they provide it. In particular, no implications about literal embedding versus indirection follow from the use above of language such as "properties . . . having . . . components as values".
NOTE: Readers whose primary interest is in the XML representation of schemas may wish to skip this chapter on the first reading, concentrating on XML Representation of Schemas and Schema Components (§4) and [XML Schema: Exposition].

Ed. Note: Due to time constraints in preparing this draft, the {annotation} properties are not explicitly described for the components below. In all cases, the property is an annotation (see "Annotation Details" below).

3.1 Attribute Declaration Details

Attribute declarations provide for:

The attribute declaration schema component has the following properties:

Schema ComponentAttribute Declaration
[name]
An NCName as defined by [XML-Namespaces].
[target namespace]
Either null or a namespace URI, as defined in [XML-Namespaces].
[simple type definition]
A simple type definition.
[min occurs]
0 or 1
[max occurs]
0 or 1
[value constraint]
Optional. A pair consisting of a string and one of default, fixed.
[annotation]
Optional. An annotation

The {name} property must match the local part of the names of attributes being validated.

A "qualified" attribute name is one that appears with a namespace prefix which is itself declared with a value other than the empty string. A non-null value of the {target namespace} property provides for validation of such attributes qualified with an identical namespace URI. Null values of {target namespace} provide for validation of local (unprefixed) attributes. Each complex type definition provides its own symbol space for the names of its associated local attribute declarations. (E.g. an attribute named title within one type definition need not have the same simple type definition as one declared within another complex type; neither of these need agree with the declaration for a similarly named qualified attribute.)

A {min occurs} of 1 specifies that the corresponding attribute must be present; a value of 0 allows for optional attributes. Similarly, a {max occurs} of 0 indicates an attribute that must not be present; a value of 1 (the normal case) allows the attribute to occur explicitly.

The value of the attribute must conform to the supplied {simple type definition}.

{value constraint} reproduces the functions of XML 1.0 default and #FIXED attribute values. fixed indicates that the attribute value must match the supplied constraint string; default specifies that the attribute is to appear unconditionally in the post-schema-validation information set, with the supplied value used whenever the attribute is not actually present.

NOTE: A more complete and formal presentation of the semantics of {name}, {target namespace}, {min occurs}, {max occurs} and default {value constraint} is provided in conjunction with other aspects of complex type validation (see Element Children and Attributes Valid (§3.3).)

[XML-Infoset] distinguishes namespace declarations such as xmlns or xmlns:xsl from attributes. Accordingly, it is unnecessary and in fact not possible for schemas to contain attribute declarations corresponding to such namespace declarations, see xmlns Not Allowed (§6.3.1). No means is provided to supply a default value for a namespace declaration.

See XML Representation of Attribute Declaration Schema Components (§4.4.1) for the XML representation of attribute declarations and Attribute Declaration Constraints (§6.3.1) for constraints on attribute declaration components as such.

Validation Contribution: Attribute Valid
For an attribute information item to be schema-valid with respect to an attribute declaration, its [value] must
Schema Information Set Contribution: Attribute Type
In the post-schema validation infoset a [schema type] property is added to the attribute information item with the {simple type definition} as its value.

3.2 Element Declaration Details

Element declarations provide for:

The element declaration schema component has the following properties:

Schema ComponentElement Declaration
[name]
An NCName as defined by [XML-Namespaces].
[target namespace]
Either null or a namespace URI, as defined in [XML-Namespaces].
[scope]
Optional. Either global or a complex type definition.
[type definition]
Either a simple type definition or a complex type definition.
[nullable]
A boolean
[value constraint]
Optional. A pair consisting of a string and one of default, fixed.
[identity-constraint definitions]
A set of constraint definitions.
[equivalence class affiliation]
Optional. A global element definition.
[equivalence class exclusions]
A subset of {extension, list, restriction, reproduction}.
[disallowed substitutions]
A subset of {equivClass, extension, list, restriction, reproduction}.
[abstract]
A boolean
[annotation]
Optional. An annotation

The {name} property must match the local part of the names of elements being validated.

A {scope} of global declares elements available for use in content models throughout the schema. Locally scoped elements are available for use only within the complex type identified by the {scope} property. For globally scoped element declarations, a non-null value of the {target namespace} property provides for validation of namespace qualified elements. Null values of {target namespace} validate unqualified elements, including locally scoped elements. This property is also null in the case of non-global declarations within named model groups: their scope will be determined when they are used in the construction of complex type definitions.

An element is schema-valid if it obeys the schema validity constraints of the {type definition}. For such an element, the schema information set contributions from the {type definition} are applied to the corresponding element information item in the post-schema-validation information set. {type definition} must not be an abstract type definition.

If {nullable} is true, then the element is also schema valid if it has no text or element content, and carries the namespace qualified attribute with [local name] null from namespace http://www.w3.org/1999/XMLSchema/instance (see xsi:null (§2.6.2)). Formal details of element validation are described in Element Valid (Explicit) (§3.2).

{value constraint} establishes a default or fixed value for an element. If default is specified, and if the element being validated is empty, then the supplied constraint string becomes [character] [children] of the validated element in the post-schema-validation infoset. If fixed is specified, then the element's content must either be empty, in which case fixed behaves as default, or it must match the supplied constraint string.

{identity-constraint definitions} express constraints establishing uniquenesses and reference relationships among the values of related elements and attributes. See Identity-constraint Definition Details (§3.9).

Element declarations are members of the equivalence class, if any, identified by {equivalence class affiliation}. Membership is transitive; an element declaration is implicitly a member of any class of which its {equivalence class affiliation} is a member.

An empty {equivalence class exclusions} creates an equivalence class admitting other element declarations having the same {type definition} or types derived therefrom. The explicit values of {equivalence class exclusions} exclude from the equivalence class elements having types which are extensions, lists, restrictions or reproductions respectively of {type definition}. If all values are specified, then no equivalence class is possible based on this element declaration.

The supplied values for {disallowed substitutions} determine whether an element declaration appearing in a content model will be prevented from additionally validating elements (a) with an xsi:type (§2.6.1) that identifies an extension, list, restriction and/or reproduction of the type of the declared element, and/or (b) from validating elements which are in the same equivalence class (equivClass) as the declared element. If {disallowed substitutions} is empty, then all derived types and equivalence class members are valid.

Element declarations for which {abstract} is true can appear in content models only when equivalence class substitution is allowed; such declarations may not themselves ever be used to validate element content.

See XML Representation of Element Declaration Schema Components (§4.4.2) for the XML representation of element declarations and Element Declaration Constraints (§6.3.2) for constraints on element declaration components as such.

Validation Contribution: Element Valid (Explicit)
An element information item is schema-valid with respect to an element declaration if
1.1 If {nullable} is false there is no attribute information item among the element information item's [attributes] whose [namespace URI] is identical to http://www.w3.org/1999/XMLSchema/instance and whose [local name] is null;
1.2 If {nullable} is true and there is such an attribute information item and its [value] is true, then
1.2.1 the element information item must have no character or element information item [children];
1.2.2 there is no fixed {value constraint}.

If there is an attribute information item among the element information item's [attributes] whose [namespace URI] is identical to http://www.w3.org/1999/XMLSchema/instance and whose [local name] is type, then
2.1 The [value] of that attribute information item is schema-valid with respect to the built-in QName simple type, as defined by String Valid (§3.12);
2.2 The local name and namespace URI (as defined in QName Interpretation (§4.3)), of the [value] of that attribute information item resolve to a type definition, as defined in QName resolution (§4.3) -- [Definition:]  call this type definition the item type definition;
2.3 The item type definition is validly derived from the {type definition} given the {disallowed substitutions} as defined in Type Derivation OK (Simple) (§6.3.12) (if it is a simple type definition) or as defined in Type Derivation OK (Complex) (§6.3.11) (if it is a complex type definition).
[Definition:]  We refer below to the actual type definition. If the above three clauses obtain, this should be understood as referring to the local type definition, otherwise to the {type definition}.

If the declaration has a {value constraint}, then provided clause 1.2 has not obtained
3.1 If the element information item has no character information item [children] and the actual type definition is a local type definition, the {value constraint} string is schema-valid with respect to the actual type definition as defined by String Valid (§3.12) (if the actual type definition is a simple type definition) or else (the actual type definition is a complex type definition) the string must be a valid default for the actual type definition as defined in Element Default Valid (Immediate) (§6.3.2);
3.2 If the {value constraint} is fixed, the element information item must have no element information item [children], and the string composed of the element information item's character information item [children] in order must be either empty or match the string of the {value constraint};

Otherwise (the element information item has character information item [children] or there is no {value constraint}) if the actual type definition is a simple type definition, then
4.1.1 The element information item's [attributes] must be empty, excepting those whose [namespace URI] is identical to http://www.w3.org/1999/XMLSchema/instance and whose [local name] is one of type, nullable or schemaLocation;
4.1.2 The element information item must have no element information item [children];
4.1.3 the string composed of the [character code] of each of the element information item's character information item [children] in order must be schema-valid with respect to the actual type definition as defined by String Valid (§3.12)
otherwise (the actual type definition is a complex type definition)
4.2.1 The element information item must be schema-valid with respect to the actual type definition as per Element Children and Attributes Valid (§3.3);
4.2.2 The element information item must be schema-valid with respect to each of the {identity-constraint definitions} as per Identity-constraint Satisfied (§3.9).
Issue (nullRequiresEmpty): Is it a precondition for being nullable that the element's contentType allow no content? If not, then more needs to be said in Chapter 6, if so, this needs to be spelled out.

Ed. Note: The above also allows null elements to have attributes, i.e. it's their CONTENT which is null. Was that the designers' intention? See related ednote under xsi:null in chapter 2.

NOTE: The {name} and {target namespace} properties are not mentioned above because they are checked during particle validation, as per Element Sequence Valid (Particle) (§3.7).
Schema Information Set Contribution: Element Default Value
If the {value constraint} is present and the element information item has no character or element information item [children], the post-schema validation infoset has a list of character information items, one per character in the {value constraint} string, appended to its [children].

Ed. Note: Should we add a property to indicate THAT the value was supplied by default?

Schema Information Set Contribution: Element Type
In the post-schema validation infoset a [schema type] property is added to the element information item with the actual type definition as its value.
Schema Information Set Contribution: Element Null
If clause 1.2 of Element Valid (Explicit) (§3.2) above obtains, in the post-schema validation infoset a [null] property is added to the element information item with the value true.

3.3 Complex Type Definition Details

Complex Type Definitions provide for:

A complex type definition schema component has the following properties:

Schema ComponentComplex Type Definition
[name]
Optional. An NCName as defined by [XML-Namespaces].
[target namespace]
Either null or a namespace URI, as defined in [XML-Namespaces].
[base type definition]
Either a simple type definition or a complex type definition.
[derivation method]
One of extension, restriction, reproduction
[final]
A subset of {extension, restriction, reproduction}.
[abstract]
A boolean
[attribute declarations]
A set of attribute declarations.
[attribute wildcard]
Optional. One of any; a pair of not and a namespace URI or null; or a set whose members are either namespace URIs or null.
[content type]
One of empty, a simple type definition or a pair consisting of a content model (I.e a Particle (§2.2.3.2)) and one of mixed, element-only.
[prohibited-substitutions]
A subset of {extension, restriction, reproduction}.
[annotation]
Optional. An annotation

Complex types are identified by their {name} and {target namespace}. Except for anonymous complex types (those with no {name}), complex type definitions must be uniquely identified within an XML Schema. Complex type {name}s and {target namespace}s are provided for reference from instances (see xsi:type (§2.6.1)), and for use in the XML Representation of Schemas and Schema Components (§4) (specifically in element and attribute). See References to schema components across namespaces (§5.2.2) for the use of component identifiers when importing one schema into another.

NOTE: The {name} of a complex type is not ipso facto the [(local) name] of the element information items validated by that definition. The connection between a name and a type definition is described in Element Declaration Details (§3.2).

As described in Type Definition Hierarchy (§2.2.1.1), each complex type is derived from a {base type definition} which is itself either a Simple Type Definition (§2.2.1.2) or a Complex Type Definition (§2.2.1.3). {derivation method} specifies the means of derivation as either extension or restriction (see Type Definition Hierarchy (§2.2.1.1)).

A complex type with an empty specification for {final} can be used as a {base type definition} for other types derived by any of extension, restriction or reproduction; the explicit values extension, restriction and reproduction prevent further derivations by extension, restriction and reproduction respectively. If all values are specified, then the complex type is said to be [Definition:]  final: no further derivations are possible.

A complex type for which {abstract} is true must not appear as the {type definition} of an Element Declaration (§2.2.2.1), and must not be referenced from an xsi:type (§2.6.1) attribute in an instance document; such abstract complex types can be used as {base type definition}s, but they are never used directly to validate element content.

{attribute declarations} are a set of individual Attribute Declaration (§2.2.2.3)s to be used for schema-validating the [attributes] of element information items. See Element Children and Attributes Valid (§3.3) and Attribute Valid (§3.1) for details of attribute validation.

{attribute wildcard}s provide a more flexible specification for validation of attributes not explicitly included in {attribute declarations}. Informally, the specific values of {attribute wildcard} are interpreted as follows:

See Element Children and Attributes Valid (§3.3) and Wildcard allows Namespace URI (§3.8) for formal details of attribute wildcard validation.

{content type} determines the schema-validation of [children] of element information items. Informally:

{prohibited-substitutions} determine whether an element declaration appearing in a content model is prevented from additionally validating elements with an xsi:type (§2.6.1) attribute that identifies an extension, restriction or reproduction of the type of the declared element. If {prohibited-substitutions} is empty, then all such substitutions are valid.

See Element Children and Attributes Valid (§3.3) for a formal specification of element content validation.

See XML Representation of Complex Type Definition Schema Components (§4.4.3) for the XML representation of complex type definitions and Complex Type Definition Constraints (§6.3.11) for constraints on complex type definition components as such.

Validation Contribution: Element Children and Attributes Valid
An element information item is schema valid with respect to a complex type definition if:
1.1 {abstract} is false;
1.2
1.2.1 If the {content type} is empty, the element information item has no character or element information item [children];
1.2.2 If the {content type} is a simple type definition, the element information item has no element information item [children], and the string composed of the [character code] of each of the element information item's character information item [children] in order is schema-valid with respect to that simple type definition as defined by String Valid (§3.12);
1.2.3 If the {content type} is element-only, the element information item has no character information item [children] other than those whose [character code] is defined as a white space in [XML];
1.2.4 If the {content type} is element-only or mixed, the sequence of the element information item's element information item [children], if any, taken in order, is schema-valid with respect to the {content type}'s particle, as defined in Element Sequence Valid (Particle) (§3.7)
1.3 For each attribute information item in the element information item's [children] excepting those whose [namespace URI] is identical to http://www.w3.org/1999/XMLSchema/instance and whose [local name] is one of type, nullable or schemaLocation, if there is among the {attribute declarations} one whose {name} matches the attribute information item's [local name] and whose {target namespace} is identical to the attribute information item's [namespace URI]
1.3.1 the attribute information item is schema-valid with respect to that attribute declaration as defined in Attribute Valid (§3.1);
otherwise (there is no matching attribute declaration)
1.3.2 there is an {attribute wildcard} and the attribute information item's [namespace URI] is schema-valid with respect to it as defined in Wildcard allows Namespace URI (§3.8);

Ed. Note: If there is an unlisted declaration, presumably for a qualified attribute, this implies that type validity is not checked. Is this right?

1.4 Each attribute declaration in the {attribute declarations} with a {min occurs} of 1 matches one of the attribute information items in the element information item's [children] as per clause 3 above.
Schema Information Set Contribution: Attribute Default Value
For each attribute declaration in the {attribute declarations} with a {min occurs} of 0 which has a {value constraint} and does not match one of the attribute information items in the element information item's [children] as per clause 3 of Element Children and Attributes Valid (§3.3) above, the post-schema validation infoset has an attribute information item whose [local name] is that attribute declaration's {name} whose [namespace URI] is the attribute declaration's {target namespace} and whose [children] are a list of character information items, one per character in the declaration's {value constraint} string, added to the [attributes] of the element information item .

There is a complex type definition version of the ur-type definition present in every schema by definition. It has the following properties:

Complex Type Definition of the Ur-Type
Property Value
{name} Not specified.
{target namespace} null.
{base type definition} Itself.
{derivation method} reproduction
{content type} A pair consisting of mixed and a particle with the following properties:
{term} a wildcard with an any {namespace constraint}
{min occurs} 0
{max occurs} *
{attribute declarations} The empty set.
{attribute wildcard} {namespace constraint} is any
{final} The empty set.
{prohibited-substitutions} The empty set.
{abstract} False.

Ed. Note: This should be handled with a generic tableau markup

The mixed content specification together with the unconstrained wildcard content model and attribute specification produce the defining property for the complex ur-type definition, namely that every complex type definition is either an extension of a simple type definition or (eventually) a restriction of the complex ur-type definition: its permissions and requirements are the least restrictive possible.

3.4 Attribute Group Definition Details

A schema can name a group of attribute declarations so that they may be incorporated as a group into complex type definitions.

Attribute group definitions do not participate in schema-validation as such, but the {attribute declarations} and {attribute wildcard} of one or more complex type definitions may be constructed in whole or part by reference to an attribute group. Attribute group definitions are provided primarily for reference from the XML Representation of Schemas and Schema Components (§4) (see complexType and attributeGroup). Thus, attribute group definitions provide a replacement for some uses of XML's parameter entities.

The attribute group definition schema component has the following properties:

Schema ComponentAttribute Group Definition
[name]
An NCName as defined by [XML-Namespaces].
[target namespace]
Either null or a namespace URI, as defined in [XML-Namespaces].
[attribute declarations]
A set of attribute declarations.
[attribute wildcard]
Optional. One of any; a pair of not and a namespace URI or null; or a set whose members are either namespace URIs or null.
[annotation]
Optional. An annotation

Attribute groups are identified by their {name} and {target namespace}; attribute group identities must be unique within an XML Schema. See References to schema components across namespaces (§5.2.2) for the use of component identifiers when importing one schema into another.

{attribute declarations} is a set of attribute declarations specifically identified as members of the attribute group.

{attribute wildcard} provides for an attribute wildcard to be included in an attribute group. See above under Complex Type Definition Details (§3.3) for the interpretation of attribute wildcards during validation.

See Element Children and Attributes Valid (§3.3) and Wildcard allows Namespace URI (§3.8) for formal details of attribute wildcard validation. See XML Representation of Attribute Group Definition Schema Components (§4.4.4) for the XML representation of attribute group definitions, and Attribute Group Definition Constraints (§6.3.4) for constraints on attribute group definition components as such.

3.5 Model Group Definition Details

A model group definition associates a name and optional annotations with a Model Group (§2.2.3.1). By reference to the name, the entire model group can be incorporated by reference into a {term}.

Model group definitions are provided primarily for reference from the XML Representation of Complex Type Definition Schema Components (§4.4.3) (see complexType and group). Thus, model group definitions provide a replacement for some uses of XML's parameter entities.

The model group definition schema component has the following properties:

Schema ComponentModel Group Definition
[name]
An NCName as defined by [XML-Namespaces].
[target namespace]
Either null or a namespace URI, as defined in [XML-Namespaces].
[model group]
A model group.
[annotation]
Optional. An annotation

Model group definitions are identified by their {name} and {target namespace}; model group identities must be unique within an XML Schema. See References to schema components across namespaces (§5.2.2) for the use of component identifiers when importing one schema into another.

Model group definitions per se do not participate in schema-validation, but the {term} of a particle may correspond in whole or in part to a model group from a model group definition.

{model group} is the Model Group (§2.2.3.1) for which the model group definition provides a name.

See XML Representation of Model Group Definition Schema Components (§4.4.5) for the XML representation of model group definitions and Model Group Definition Constraints (§6.3.6) for constraints on model group definition components as such.

3.6 Model Group Details

When the [children] of element information items are not constrained to be empty or by reference to a simple type definition (Simple Type Definition Details (§3.12)), the sequence of element information item [children] content may be specified in more detail with a model group. Because the {term} property of a particle can be a model group, and model groups contain particles, model groups can indirectly contain other model groups; the grammar for content models is therefore recursive.

The model group schema component has the following properties:

Schema ComponentModel Group
[compositor]
One of all, choice or sequence.
[particles]
A list of particles
[annotation]
Optional. An annotation

{compositor}determines whether the element information item [children] validated by the model group must:

{annotation}Description to be supplied in a future draft.

Validation Contribution: Element Sequence Valid
[Definition:]  We define a partition of a sequence as a sequence of sub-sequences, some or all of which may be empty, such that concatenating all the sub-sequences yields the original sequence.

A sequence (possibly empty) of element information items is schema-valid with respect to a model group if
1.1 The {compositor} is sequence and there is a partition of the sequence into n sub-sequences where n is the length of {particles} such that each of the sub-sequences in order is schema-valid with respect to the corresponding particle in the {particles} as defined in Element Sequence Valid (Particle) (§3.7);
or
1.2 The {compositor} is choice and there is a particle among the {particles} such that the sequence is schema-valid with respect to that particle as defined in Element Sequence Valid (Particle) (§3.7);
or
1.3 The {compositor} is all and there is a partition of the sequence into n sub-sequences where n is the length of {particles} such that there is a one-to-one mapping between the sub-sequences and the {particles} where each sub-sequence is schema-valid with respect to the corresponding particle as defined in Element Sequence Valid (Particle) (§3.7);

Nothing in the above should be understood as ruling out groups whose {particles} is empty: although no sequence can be schema-valid with respect to such a group whose {compositor} is choice, the empty sequence is schema valid with respect to empty groups whose {compositor} is sequence or all.
NOTE: The above definition is implicitly non-deterministic, and should not be taken as a recipé for implementations. Note in particular that when {compositor} is all, particles is restricted to a list of local and global element declarations (see Model Group Constraints (§6.3.7)). A much simpler implementation is possible for than would arise from a literal interpretation of the definition above; informally, the content is valid when each declared element occurs exactly once, and each is valid with respect to its corresponding declaration. The elements can occur in arbitrary order.

Ed. Note: The above depends on chapter 6 to rule out 'all' except directly within content type.

See XML Representation of Model Group Schema Components (§4.4.6) for the XML representation of model groups and Model Group Constraints (§6.3.7) for constraints on model group components as such.

3.7 Particle Details

As described in Model Group Details (§3.6), particles contribute to the definition of content models. The particle schema component has the following properties:

Schema ComponentParticle
[min occurs]
A non-negative integer
[max occurs]
Either a non-negative integer or *
[term]
One of a model group, a wildcard, a local element declaration or global element declaration together with the following additional properties:
[value constraint]
Optional. A pair consisting of a string and one of default, fixed.
[nullable]
A boolean
[disallowed substitutions]
A subset of {extension, restriction, equivClass}.
[abstract]
A boolean
[annotation]
Optional. An annotation

The following is an informal overview of the properties of a particle. Formal interpretation of these properties is found in Element Sequence Valid (Particle) (§3.7).

In general, multiple element information item [children], possibly with intervening character [children] if the content type is mixed, can be validated with respect to a single particle. {min occurs} determines the minimum number of such element [children] that can validly occur. The number of such children must be greater than or equal to {min occurs}. If {min occurs} is 0, then occurrence of such children is optional.

The number of such element [children] must be less than or equal to any numeric specification of {max occurs}; if {max occurs} is *, then there is no upper bound on the number of such children.

{nullable}, {disallowed substitutions} and {value constraint}, if specified, merge with the corresponding properties of the supplied element declaration.

Validation Contribution: Element Sequence Valid (Particle)
A sequence (possibly empty) of element information items is schema-valid with respect to a particle if
1.1 The length of the sequence is greater than or equal to the {min occurs};
1.2 The length of the sequence is less than or equal to the {max occurs};
1.3 Either
1.3.1 the {term} is a model group and there is a partition of the sequence into sub-sequences such that each sub-sequence is schema-valid with respect to that model group as defined in Element Sequence Valid (§3.6);
or
1.3.2 the {term} is a wildcard and the [namespace URI] of each element information item in the sequence is schema-valid with respect to the {namespace constraint} of the wildcard.
or
1.3.3.1 the {term} is an element declaration;
1.3.3.2 for each element information item in the sequence either
1.3.3.2.1 the element declaration is local (i.e. its {scope} is not global), its {abstract} is false, the element information item's [namespace URI] is identical to the element declaration's {target namespace}, the element information item's [local name] matches the element declaration's {name} and the element information item is schema-valid with respect to the declaration as defined in Element Valid (Explicit) (§3.2);
or
1.3.3.2.2 the element declaration is global (i.e. its {scope} is global), the particle's {abstract} is false, the element declaration's {abstract} is false, the element information item's [namespace URI] is identical to the element declaration's {target namespace}, the element information item's [local name] matches the element declaration's {name} and the element information item is schema-valid with respect to the element declaration as defined in Element Valid (Explicit) (§3.2), with the values of the particle's {value constraint}, {nullable} and {disallowed substitutions} being merged with the corresponding properties of the element declaration;
or
1.3.3.2.3 the element declaration is global (i.e. its {scope} is global), the particle's {disallowed substitutions} does not contain equivClass, the element declaration's {disallowed substitutions} does not contain equivClass, the [local name] and [namespace URI] of the element information item resolve to an element definition, as defined in QName resolution (§4.3) -- [Definition:]  call this declaration the equivalent declaration, the equivalent declaration together with the particle's {disallowed substitutions} is validly equivalent to the particle's element declaration as defined in Equivalence Class OK (Transitive) (§6.3.2) and the element information item is schema-valid with respect to the equivalent declaration as defined in Element Valid (Explicit) (§3.2), with the values of the particle's {value constraint}, {nullable} and {disallowed substitutions} being merged with the corresponding properties of the equivalent declaration.

See XML Representation of Model Group Schema Components (§4.4.6) for the XML representation of particles and Particle Constraints (§6.3.10) for constraints on particle components as such.

3.8 Wildcard Details

A wildcard provides for validation of element information items dependent on their namespace URI, but independently of their local name. The wildcard schema component has the following properties:

Schema ComponentWildcard
[namespace constraint]
One of any; a pair of not and a namespace URI or null; or a set whose members are either namespace URIs or null.
[annotation]
Optional. An annotation

Ed. Note: missing the processContents property, and a descriptions of the processing options for material allowed by an any, i.e. strict (must validate, find the defs and decls you need or invalid; lax, i.e. validate when you can find the defs and decls, OK if you can't; skip, i.e. don't try, call it valid no matter what.

{namespace constraint} provides for validation of elements that:

Validation Contribution: Element Valid (Wildcard)
[Definition:]  watch this space
Validation Contribution: Wildcard allows Namespace URI
A value which is either a namespace URI or null is schema valid with respect to a wildcard constraint (the value of a {namespace constraint} or a {attribute wildcard}) if
1.1 the constraint is any;
or
1.2 the constraint is a pair of not and a namespace URI, and the value is not identical to the namespace URI;
or
1.3 the constraint is a set, and the value is identical to one of the members of the set.

See XML Representation of Wildcard Schema Components (§4.4.7) for the XML representation of wildcards and Wildcard Constraints (§6.3.5) for constraints on wildcard components as such.

3.9 Identity-constraint Definition Details

Identity-constraint definition components provide for uniqueness and reference constraints with respect to the contents of multiple elements and attributes. The identity-constraint definition schema component has the following properties:

Schema ComponentIdentity-constraint Definition
[name]
An NCName as defined by [XML-Namespaces].
[target namespace]
Either null or a namespace URI, as defined in [XML-Namespaces].
[identity-constraint category]
One of key, keyref or unique.
[selector]
An XPath expression, as defined in [XPath]
[fields]
An a non-empty list of XPath expressions, as defined in [XPath]
[referenced key]
Required if {identity-constraint category} is keyref, forbidden otherwise. A identity-constraint definition with {identity-constraint category} equal to key or unique.
[annotation]
Optional. An annotation

Identity-constraint definitions are identified by their {name} and {target namespace}; Identity-constraint definition identities must be unique within an XML Schema. See References to schema components across namespaces (§5.2.2) for the use of component identifiers when importing one schema into another.

Informally, {identity-constraint category} identifies the Identity-constraint definition as playing one of three roles:

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

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

{selector} specifies an XPath expression [XPath] relative to instances of the element being declared. This must identify a node set of subelements (i.e. elements contained within the declared element) to which the constraint applies.

{fields} specifies XPath expressions 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}s, to cater to multi-field keys, keyrefs, and uniqueness constraints.

NOTE: Provision for multi-field keys etc. goes beyond what is supported by xsl:key.
Issue (restrictConstrXPaths): XPath expressions 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 {fields} should be restricted to certain specified simple forms.

The WG has asked the editor to bring forward a proposal. Here's the starting point, feedback invited:
  • |, /, //, .., @QName, QName, *, ancestor::, []
  • or, and, =
  • the not, name and position functions
  • string and number literals
  • prefixes interpreted per in-scope namespace declarations
Issue (islandValidConstraint): What are the interactions between identity-constraints and opportunistic validation inside wildcards?

A formal description of Identity-constraint definition validation is given below in Identity-constraint Satisfied (§3.9)

Validation Contribution: Identity-constraint Satisfied
An element information item is schema-valid with respect to a identity-constraint if
1.1 The {selector}, with the element information item as the context node, evaluates to a node-set (as defined in [XPath]). [Definition:]  Call this the target node set;
1.2 Each node in the target node set is an element node;
1.3 For each node in the target node set all of the {fields}, with that node as the context node, evaluate to either an empty node-set or a node-set with exactly one member. [Definition:]  Call the sequence of the values (as defined in [XML Schemas: Datatypes]) of those node-sets in order the key-sequence of the node;

[Definition:]  Call the subset of the target node set for which all the {fields} evaluate to a node-set with exactly one member which is an element or attribute node the qualified node set;

2.1.1 The {identity-constraint category} is unique;
2.1.2 No two members of the qualified node set have key-sequences whose members are pairwise equal;
or
2.2.1 The {identity-constraint category} is key;
2.2.2 The target node set and the qualified node set are equal, that is, every member of the target node set is also a member of the qualified node set and vice versa;
2.2.3 No two members of the qualified node set have key-sequences whose members are pairwise equal;
or
2.3.1 The {identity-constraint category} is keyref;
2.3.2 For each member of the qualified node set (call this the keyref member), there must be a member of the node table associated with the {referenced key} in the [identity-constraint table] of the element information item (see Identity-constraint Table (§3.9), which must be understood as logically prior to this clause of this constraint, below) whose key-sequence is equal to the keyref member's key-sequence member for member.
2.3.3

Ed. Note: The fields cardinality of a keyref must be equal to the fields cardinality of its [referenced key], checked in chapter 6.

Ed. Note: This is simpler (and in one respect, the hyper-uniqueness implied by the uniqueness requirement built in to the merger of the tables defined below, stronger) recursive descent implied than the apparently agreed design: is it acceptable for v.1, as I don't see how to do better?

Ed. Note: Check the resolution of the nested domains issue -- is the above correct wrt that?

Schema Information Set Contribution: Identity-constraint Table
[Definition:]  An eligible identity-constraint of an element information item is one such that clauses 2.1.[1-2] or 2.2.[1-3] of Identity-constraint Satisfied (§3.9) obtains with respect to that item and that constraint, or such that any of the element information item [children] of that item have a [identity-constraint table] with an entry for that constraint.

[Definition:]  A node table is a set of pairs each consisting of a key-sequence and an element node.

Whenever an element information item has one or more eligible constraints, a new [identity-constraint table] is added to the post-schema-validation infoset for that element information item, consisting of pairs of identity-constraints and node tables, one for each of the item's eligible constraints, with the node table in each pair defined as follows: There is a member in the node table associated with an eligible constraint of an element information item consisting of a key-sequence (call it k) and a node (call it n) if and only if
1.1
1.1.1 There is a member in one of the node tables associated with the eligible constraint in at least one of the [identity-constraint tables] of the element information item [children] of the element information item whose key-sequence is b and whose node is n;
or
1.1.2 n is in the qualified node set for the eligible constraint of the element information item with key-sequence b.
1.2 There is no member in one of the node tables associated with the eligible constraint in any of the [identity-constraint tables] of the element information item [children] of the element information item whose key-sequence is b and whose node is a node other than n;
1.3 Some node distinct from n is in the qualified node set for the eligible constraint of the element information item with key-sequence b.

Ed. Note: This is considerably less than transparent. The intention is to recursively construct r-c tables at one level by merging the still-unique members of each corresponding table one level down, if any, with the new entries arising from evaluating the r-c at this level, if any, throwing out any which conflict.

See XML Representation of Identity-constraint Definition Schema Components (§4.4.8) for the XML representation of identity-constraint definitions and Identity-constraint Definition Constraints (§6.3.3) for constraints on identity-constraint definition components as such.

3.10 Notation Declaration Details

Ed. Note: Cleanup of the descriptive text below, and descriptions of individual properties to be provided in a future draft.

The notation declaration schema component has the following properties:

Schema ComponentNotation Declaration
[name]
An NCName as defined by [XML-Namespaces].
[target namespace]
Either null or a namespace URI, as defined in [XML-Namespaces].
[system identifier]
Optional if {public identifier} is present. A URI reference.
[public identifier]
Optional if {system identifier} is present. A public identifier, as defined in [XML].
[annotation]
Optional. An annotation

Notation declarations do not participate in schema-validation as such. They are referenced in the course of schema-validating strings as members of the NOTATION simple type.

See XML Representation of Notation Declaration Schema Components (§4.4.9) for the XML representation of notation declarations and Notation Constraints (§6.3.8) for constraints on notation declaration components as such.

3.11 Annotation Details

Ed. Note: Cleanup of the descriptive text below, and descriptions of individual properties to be provided in a future draft.

The annotation schema component has the following properties:

Schema ComponentAnnotation
[application information]
Optional. An element information item.
[user information]
Optional. An element information item.

Annotations do not participate in schema-validation as such. Provided an annotation itself satisfies all relevant Constraints of Schemas it cannot affect the schema-validity of element information items.

See XML Representation of Annotation Schema Components (§4.4.10) for the XML representation of annotations and Annotation Constraints (§6.3.9) for constraints on annotation components as such.

3.12 Simple Type Definition Details

Simple type definitions provide for constraining character information item [children] of element and attribute information items. The simple type definition schema component has the following properties:

Schema ComponentSimple Type Definition
[name]
Optional. An NCName as defined by [XML-Namespaces].
[target namespace]
Either null or a namespace URI, as defined in [XML-Namespaces].
[final]
A subset of {enumeration, list, restriction, reproduction}.
[abstract]
A boolean
[annotation]
Optional. An annotation
[variety]
There are three varieties of simple type definition, each with a distinct set of properties:
atomic
A simple type definition whose members are those of a built-in primitive simple type, or a subset of those of a built-in primitive simple type identified by specifying values for one or more constraining facets.
[primitive type definition]
A built-in primitive simple type definition (or the ur-type definition).
[base type definition]
A simple type definition, which can be the ur-type definition.
[facets]
A set of constraining facets.
enumeration
A simple type definition for a type whose members are an explicitly enumerated subset of some other simple type.
[base type definition]
A simple type definition.
[strings]
A set of strings from the lexical space of the {base type definition}.
list
A simple type definition for a type whose members are lists of members of some other (non-list) simple type.
[base type definition]
The simple type definition which constrains each element of the list.

Simple types are identified by their {name} and {target namespace}. Except for anonymous simple types (those with no {name}), simple type definitions must be uniquely identified within an XML Schema. Simple type {name}s and {target namespace}s are provided for reference from instances (see xsi:type (§2.6.1)), and for use in the XML Representation of Schemas and Schema Components (§4) (specifically in element and attribute). See References to schema components across namespaces (§5.2.2) for the use of component identifiers when importing one schema into another.

NOTE: The {name} of a simple type is not ipso facto the [(local) name] of the element or attribute information items validated by that definition. The connection between a name and a type definition is described in Element Declaration Details (§3.2) and Attribute Declaration Details (§3.1).

A simple type definition for which {abstract} is true must not appear as the {type definition} of an Attribute Declaration (§2.2.2.3), must not be used as the {base type definition} of an enumeration simple type, must not used as the {base type definition} of a list simple type, and must not be referenced from an xsi:type (§2.6.1) attribute in an instance document.

{variety} determines whether the simple type corresponds to an atomic, enumeration, or list type as defined by [XML Schemas: Datatypes].

A simple type with an empty specification for {final} can be used as a {base type definition} for other types derived by restriction; and/or as the {base type definition} of an enumeration simple type, and/or as the {base type definition} of a list simple type. The explicit values restriction, enumeration and list prevent any or all of those uses respectively.

Ed. Note: Need to describe 'reproduction' value.

As described in Type Definition Hierarchy (§2.2.1.1), every atomic simple type definition is a restriction of some other simple {base type definition}, which is itself either a simple type definition or the ur-type definition. Each atomic type is ultimately a restriction of (or identical to) exactly one built in simple {primitive type definition}.

{facets} for each atomic simple type definition are selected from those defined in [XML Schemas: Datatypes] for the corresponding {primitive type definition}. Therefore, the value space and lexical space (I.e. the content validated by) any atomic simple type is determined by the pair {{primitive type definition}, {facets}}.

Enumeration simple types are restrictions of the specified {base type definition}; enumeration types validate only content that matches one of the specified {strings}.

As specified in [XML Schemas: Datatypes], list simple types validate whitespace separated tokens, each of which conforms to the specified {base type definition}. The base type specified must not itself be a list type, and must be one of the types identified in [XML Schemas: Datatypes] as a suitable base for a list simple type.

Ed. Note: Careful readers will observe that the above specification of list types conflicts with the claim in "Type Derivation" that all simple types are restrictions of other simple types. This anomaly has no effect on the validation of content, but it does affect the cleanliness of the hierarchy exposed by a post-schema validation infoset, which includes simple type definitions derived by list-formation as well as restriction.

Simple type definitions for all the built-in primitive datatypes, namely string, boolean, float, double, decimal, timeInstant, timeDuration, recurringInstant, binary, uri (see the Primitive Datatypes section of [XML Schemas: Datatypes]), as well as for the ur-type definition (as previously described), are present by definition in every schema. All are in the XML Schema {target namespace} (namespace URI http://www.w3.org/1999/XMLSchema), have an atomic {variety} with an empty {facets} and the ur-type definition as their {base type definition} and themselves as {primitive type definition}.

Similarly, simple type definitions for all the built-in derived datatypes (see the Derived Datatypes section of [XML Schemas: Datatypes]) are present by definition in every schema, with properties as specified in [XML Schemas: Datatypes] and as represented in XML in the schema for datatypes therein.

There is no separate ur-Type for simple types. As discussed in Type Definition Hierarchy (§2.2.1.1), the ur-type definition functions as a simple type when used as the base type definition for a simple type.

Validation Contribution: String Valid
A string is schema valid with respect to a simple type definition if
1.1 It satisfies the conditions defined in the sub-section of Primitive Datatypes corresponding to {primitive type definition};
1.2 If there is a pattern facet among {facets}, it satisfies the conditions expressed thereby as defined in the Constraining or Non-fundamental facets section of [XML Schemas: Datatypes]
1.3 The member of the {primitive type definition}'s value space which it corresponds to the string (as defined in Primitive Datatypes) satisfies the conditions expressed by all the other {facets}, if any, as defined in the Constraining or Non-fundamental facets section of [XML Schemas: Datatypes]

See XML Representation of Simple Type Definition Schema Components (§4.4.11) for the XML representation of simple type definitions and Simple Type Definition Constraints (§6.3.12) for constraints on simple type definition components as such.

4 XML Representation of Schemas and Schema Components

The principal purpose of XML Schema: Structures is to define a set of schema components that constrain the contents of instances and augment the information sets thereof. Although no external representation of schemas is required for this purpose, such representations will obviously be widely used. To provide for this in an appropriate and interoperable way, we specify a normative XML representation for schemas which makes provision for every kind of schema component. [Definition:]  These may be gathered together in to a single schema document, i.e. an XML element information item. For the schema document as a whole, and its constituents, the sections below define correspondences between element information items (with declarations in (normative) Schema for Schemas (§A) and (normative) DTD for Schemas (§B)) and schema components. All the element information items in the XML representation of a schema are in the XML Schema namespace, that is their [namespace URI] is http://www.w3.org/1999/XMLSchema. Although a common way of creating schema documents will be using an XML parser, this is not required: any mechanism which constructs conformant infosets as defined in [XML-Infoset] is a possible starting point.

Throughout the following sections, when we specify that a particular property of a schema component corresponds to the [value] of some attribute information item or the [children] of some element information item, the value in question is understood to be based on a string consisting of the list, in order, of the [character code] of each character information item in the [children] of that attribute information item or in the [children] of that element information item respectively, that string then being interpreted as appropriate to the defined type of the property in question.

When we say that a numeric-valued property of a schema component corresponds to the [value] of some attribute information item, the number in question is understood to be the base 10 interpretation of string described above.

4.1 XML Representations of Schemas

A schema is represented in XML by one or more schema documents. A schema document contains representations for a collection of schema components, e.g. type definitions and element declarations, which have a common {target namespace}. A schema document which has one or more import element information items corresponds to a schema with components with more than one {target namespace}, see Schema Composition (§5.2.2).

XML Representation Summaryschema Element Information Item

<schema
  blockDefault = #all or (possibly empty) subset of {equivClass, extension, list, restriction, reproduction} : ''
  finalDefault = #all or (possibly empty) subset of {extension, restriction, reproduction} : ''
  id = ID
  targetNamespace = uri-reference
  version = string>
  Content: ((include | import | annotation)* , ((simpleType | complexType | element | group | attributeGroup | notation) , annotation*)+)
</schema>

There is no single schema component corresponding to a schema element information item, and so no local correspondence of attributes to properties is specified above. The blockDefault, finalDefault and targetNamespace attributes illustrated above are appealed to in the sub-sections below, as they provide global information applicable to many representation/component correspondences. The other attributes (id and version) are for user convenience, and this specification defines no semantics for them.

The definition of the schema abstract data model in XML Schema Abstract Data Model (§2.2) makes clear that most components have a {target namespace}. Most components corresponding to representations within a given schema element information item will have a {target namespace} which corresponds to the targetNamespace attribute.

Since the empty string is a legal (relative) URI reference, supplying an empty string for targetNamespace is not the same as not specifying it at all. The appropriate form of schema document corresponding to a schema whose components have no {target namespace} is one which has no targetNamespace attribute specified at all.

NOTE: The XML namespaces recommendation discusses only instance document syntax for elements and attributes; it therefore provides no direct framework for managing the names of type definitions, attribute group definitions, and so on. Nevertheless, we apply the target namespace facility uniformly to all schema components, i.e. not only declarations but also definitions have a {target namespace}.
Example
<xs:schema
    xmlns:xs="http://www.w3.org/1999/XMLSchema
    targetNamespace="http://purl.org/metadata/dublin_core"
    version="M.n">

  ...

</xs:schema>
A modest beginning to a schema.

Although the schema above might be 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.

Aside from annotation, which is not named and corresponds to a "helper" schema component, and include and import, which do not correspond directly to any schema component at all, each of the element information items which may appear in the content of schema corresponds to a primary or secondary schema component, and in all cases these are named. The sub-sections of XML Representation of Schema Components (§4.4) present each such item in turn, setting out the components to which it may correspond.

4.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 (§5.3) and Schema Validity * (§6.1).

4.3 References to Schema Components

Reference to schema components from a schema document is managed in a uniform way, whether the component corresponds to an element information item from the same schema document or is imported (References to schema components across namespaces (§5.2.2)) from an external schema (which may, but need not, correspond to an explicit schema document). The form of all such references is a QName. In each of the XML representation expositions in the following sections, an attribute is shown as having type QName if and only if it is interpreted as referencing a schema component.

Example
<xs:schema xmlns:xs="http://www.w3.org/1999/XMLSchema"
            xmlns:xhtml="http://www.w3.org/1999/html"
            xmlns="http://www.foo.com"
            targetNamespace="http://www.foo.com">
  . . .

  <xs:element name="elem1" type="Address"/>

  <xs:element name="elem2" type="xhtml:blockquote"/>

  <xs:attribute name="attr1"
                type="xsl:quantity"/>
  . . .
</xs:schema>

The first of these is most probably a local reference, i.e. a reference to a type definition corresponding to a complexType element information item located elsewhere in the schema document, the other two refer to type definitions from schemas for other namespaces and assume that their namespaces have been declared for import. See References to schema components across namespaces (§5.2.2) for a discussion of importing.
Schema Representation Constraint: QName Interpretation
Where the type of an attribute information item in a schema document is identified below as QName, its value is uniformly interpreted as consisting of a [Definition:]  local name consisting of the character information items after the colon, if any, otherwise all the character information items, in the value, and of a [Definition:]  namespace URI, derived from its value and the containing element information item's [in-scope namespaces] as follows:

In the absence of the non-core properties [in-scope namespaces] and/or [namespace URI] from the infoset for the schema document in question, processors must reconstruct equivalent information as necessary, using the [declared namespaces] of the containing element information item and its ancestors in the first case and using the namespace declaration in question's [children] in the second.

Ed. Note: If the XML Base proposal is adopted before we go to REC, we will need to account for any changes it makes to the Infoset in this area.

Schema Representation Constraint: QName resolution
A string known to be a QName resolves to a schema component of a specified kind if:
1.1 that component is contained in the schema which corresponds to the schema document within which the QName appears (see Schema Composition (§5.2.2) for a definition of what a schema contains);
1.2 its {local name} matches the local name of the string;
1.3 its {namespace URI} is identical to the namespace URI of the string.

4.3.1 References to Schema Components from Elsewhere

The names of schema components such as type definitions and element declarations are not of type ID: 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 from outside the context of schema documents.

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

Short-form fragment identifiers may also be used in some cases, that is when a DTD or XML Schema is available for the schema in question, and the provision of an id attribute for the representations of all primary and secondary schema components, which is of type ID, has been exploited.

It is a matter for applications to specify whether they interpret document-level references of either of the above varieties as being to the relevant element information item (i.e. without special recognition of the relation of schema documents to schema components) or as being to the corresponding schema component.

4.4 XML Representation of Schema Components

For each kind of schema component there is a corresponding normative XML representation. The sections below describe the correspondences between the properties of each kind of schema component on the one hand and the properties of information items in that XML representation on the other, together with constraints on that representation above and beyond those implicit in the (normative) Schema for Schemas (§A) and (normative) DTD for Schemas (§B).

The language used is as if the correspondences were mappings from XML representation to schema component, but the mapping in the other direction, and therefor the correspondence in the abstract, can always be constructed therefrom.

4.4.1 XML Representation of Attribute Declaration Schema Components

The XML representation for an attribute declaration schema component is an attribute element information item. It specifies a simple type definition for an attribute either by reference or explicitly, and may provide occurrence and default information. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summaryattribute Element Information Item

<attribute
  default = string
  fixed = string
  id = ID
  maxOccurs = 0 | 1 : 1
  minOccurs = 0 | 1 : 0
  name = NCName
  type = QName>
  Content: (annotation? , simpleType?)
</attribute>

If minOccurs=maxOccurs=0 the item corresponds to no component at all, otherwise
Attribute Declaration Schema Component
PropertyRepresentation
{name}The value of the name [attribute]
{target namespace}The value of the targetNamespace [attribute] of the parent schema element information item, or null if there is none.
{simple type definition}The simple type definition corresponding to the simpleType element information item in the [children], if present, otherwise the simple type definition resolved to by the value of the type [attribute], if present, otherwise the ur-type definition.
{min occurs}The value of the minOccurs [attribute], or 0 if it is absent.
{max occurs}The value of the maxOccurs [attribute], or 1 if it is absent.
{value constraint}If there is a default or a fixed [attribute], then a pair consisting of the value of that [attribute] and either default or fixed, as appropriate, otherwise null.
{annotation}The annotation corresponding to the annotation element information item in the [children], if present, otherwise null.
Example
<attribute name="myAttribute"/>

<attribute name="yetAnotherAttribute" type="integer" minOccurs="1"/>

<attribute name="anotherAttribute" default="42">
 <simpleType basetype="integer">
  <minExclusive value="0"/>
 </simpleType>
</attribute>

<attribute name="stillAnotherAttribute" type="string" fixed="Hello world!"/>
Four attributes are declared: one with no explicit constraints at all; two more each declared by reference to the built-in simple datatype integer, one required to be present instances and one with a default and a subrange qualification; and a fourth with a fixed value.

The type attribute is used when the attribute can use a built-in or pre-declared simple type definition. Otherwise an anonymous simpleType is used inline.

The default when no simple type definition is referenced or provided is the ur-type definition, which imposes no constraints at all.

Schema Representation Constraint: Attribute Declaration Representation OK
In addition to the conditions imposed on attribute element information items by the DTD and schema for schemas, the following must also hold:
1.1 default and fixed must not both be present;
1.2 type and simpleType must not both be present;
1.3 The corresponding attribute declaration must satisfy the conditions set out in Attribute Declaration Constraints (§6.3.1).

4.4.2 XML Representation of Element Declaration Schema Components

The XML representation for an element declaration schema component is an element element information item. It specifies a type definition for an element either by reference or explicitly, and may provide occurrence and default information. The correspondences between the properties of the information item and properties of the component(s) it corresponds to are as follows:

XML Representation Summaryelement Element Information Item

<element
  abstract = boolean : false
  block = #all or (possibly empty) subset of {equivClass, extension, list, restriction, reproduction} : ''
  default = string
  equivClass = QName
  final = #all or (possibly empty) subset of {extension, restriction, reproduction} : ''
  fixed = string
  id = ID
  maxOccurs = string
  minOccurs = non-negative-integer : 1
  name = NCName
  nullable = boolean : false
  ref = QName
  type = QName>
  Content: (annotation? , (simpleType | complexType)? , (unique | key | keyref)*)
</element>

If the element element information item has schema as its parent, the corresponding schema component is as follows:

Element Declaration Schema Component
PropertyRepresentation
{name}The value of the name [attribute]
{target namespace}The value of the targetNamespace [attribute] of the parent schema element information item, or null if there is none.
{scope}global
{type definition}The type definition corresponding to the simpleType or complexType element information item in the [children], if either is present, otherwise the type definition resolved to by the value of the type [attribute], otherwise the {type definition} of the element declaration resolved to by the value of the equivClass [attribute], if present, otherwise the ur-type definition.
{nullable}The value of the nullable [attribute], if present, otherwise false.
{value constraint}If there is a default or a fixed [attribute], then a pair consisting of the value of that [attribute] and either default or fixed, as appropriate, otherwise null.
{identity-constraint definitions}A set consisting of the identity-constraint-definitions corresponding to all the key, unique and keyref element information items in the [children], if any, otherwise the empty set
{equivalence class affiliation}the element declaration resolved to by the value of the equivClass [attribute], if present, otherwise null
{disallowed substitutions}A set corresponding to the normalised value of the block [attribute], if present, otherwise on the value of the blockDefault [attribute] of the parent schema element information item, if present, otherwise on the empty string, as follows:
the empty string
the empty set;
#all
{equivClass, extension, list, restriction, reproduction};
otherwise
a set with members drawn from the set above, each being present or absent depending on whether the string contains an equivalently named whitespace-delimited substring.
{equivalence class exclusions}As for {disallowed substitutions} above, but with the relevant set being {extension, restriction, reproduction}
{abstract}The value of the abstract [attribute], if present, otherwise false
{annotation}The annotation corresponding to the annotation element information item in the [children], if present, otherwise null

otherwise if the element element information item has complexType or group as an ancestor and the ref [attribute] is present, the corresponding schema component is as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all):

Particle Schema Component
PropertyRepresentation
{min occurs}The value of the minOccurs [attribute], if present, otherwise 1
{max occurs}*, if the maxOccurs [attribute] equals *, otherwise the numeric value of the maxOccurs [attribute], if present, otherwise the value of the minOccurs [attribute], if present, otherwise 1.
{term}The (global) element declaration resolved to by the value of the ref [attribute]
{value constraint}As above
{nullable}As above
{disallowed substitutions}As above
{abstract}As above
{annotation}As above

otherwise (the element element information item has complexType or group as an ancestor and the ref [attribute] is absent), the corresponding schema components are as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all):

Particle Schema Component
PropertyRepresentation
{min occurs}The value of the minOccurs [attribute], if present, otherwise 1
{max occurs}*, if the maxOccurs [attribute] equals *, otherwise the numeric value of the maxOccurs [attribute], if present, otherwise the value of the minOccurs [attribute], if present, otherwise 1.
{term}The (locally-scoped) element declaration given below:
Element Declaration Schema Component
PropertyRepresentation
{name}The value of the name [attribute]
{target namespace}null
{scope}If the element element information item has complexType as an ancestor, the complex definition corresponding to that item, otherwise (the element element information item is within a top-level group definition), null.
{type definition}As above
{nullable}As above
{value constraint}As above
{identity-constraint definitions}As above
{equivalence class affiliation}As above
{equivalence class exclusions}As above
{disallowed substitutions}As above
{abstract}As above
{annotation}As above

element corresponds to an element declaration, and allows the type definition of that declaration to be specified either by reference or by explicit inclusion.

elements within schema produce global element declarations; elements within group or complexType produce either particles which contain global element declarations (if there's a ref attribute) or local declarations (otherwise).

Locally-scoped declarations always schema-validate element information items with a null [namespace URI], regardless of the {target namespace} of the complex type definition they are contained within.

As noted above the names for global are in a separate symbol space from the symbol spaces for the names of type definitions, so there can (but need not be) a simple or complex type definition type with the same name as a top-level element. As with attribute names, the names of locally-scoped element declarations reside in symbol spaces local to the type definition which contains them. Note however that type definition names are always top-level names within a schema, even when they appear in locally-scoped element declarations.

Note that the above allows for two levels of defaulting for unspecified type definitions. An element with no referenced or included type definition will correspond to an element declaration which has the same type definition as the exemplar of its equivalence class if it identifies one, otherwise the ur-type definition.

See below at XML Representation of Identity-constraint Definition Schema Components (§4.4.8) for key, unique and keyref.

Example
<xs:element name="myelement" type="mySimpleType"/>

<xs:element name="et0" type="myComplexType"/>

<xs:element name="et1">
 <xs:complexType>
  <xs:element ref="et0"/>
  . . .
  <xs:attribute ...>. . .</xs:attribute>
 </xs:complexType>
</xs:element>

<xs:element name="et2">
 <xs:complexType content="empty">
  <xs:attribute ...>. . .</xs:attribute>
 </xs:complexType>
</xs:element>
The first two examples above declare elements by reference to a simple and a complex type definition respectively. The third and fourth use embedded anonymous complex type definitions, the first of which in turn refers to one of the top-level element declarations in its content model.
<xs:element name="contextOne">
 <xs:complexType>
  <xs:element name="myLocalelement" type="myFirstType"/>
  <xs:element ref="globalelement"/>
 </xs:complexType>
</xs:element>

<xs:element name="contextTwo">
 <xs:complexType>
  <xs:element name="myLocalelement" type="mySecondType"/>
  <xs:element ref="globalelement"/>
 </xs:complexType>
</xs:element>
Instances of myLocalelement within contextOne will be constrained by myFirstType, while those within contextTwo will be constrained by mySecondType.
NOTE: The possibility that differing attribute declarations and/or content models would apply to elements with the same name in different contexts is an extension beyond the expressive power of a DTD in XML 1.0.
Example
  <xs:complexType name="facet" base="annotated" derivedBy="extension">
    <xs:attribute name="value" minOccurs="1"/>
  </xs:complexType>

  <xs:element name="facet" type="facet" abstract="true"/>

  <xs:element name="encoding" equivClass="facet">
   <xs:complexType base="facet" derivedBy="restriction">
    <xs:attribute name="value" type="encodings"/>
   </xs:complexType>
  </xs:element>

  <xs:element name="period" equivClass="facet">
   <xs:complexType base="facet" derivedBy="restriction">
    <xs:attribute name="value" type="timeDuration"/>
   </xs:complexType>
  </xs:element>

  <xs:complexType name="datatype">
    <xs:element ref="facet" minOccurs="0" maxOccurs="*"/>
    <xs:attribute name="name" type="NCName" minOccurs="0">
    . . .
  </xs:complexType>
An example from the schema for datatypes from [XML Schemas: Datatypes]. The facet type is defined and the facet element is declared to use it. The facet element is abstract -- it's only defined to stand as the exemplar for a class. Two further elements are declared, each a member of the facet equivalence class. Finally a type is defined which refers to facet, thereby allowing either period or encoding (or any other member of the class).
Schema Representation Constraint: Element Declaration Representation OK
In addition to the conditions imposed on element element information items by the DTD and schema for schemas, the following must also hold:
1.1 default and fixed must not both be present;
1.2 If the element's parent is schema, then
1.2.1.1 name must be present;
1.2.1.2 minOccurs, maxOccurs and ref must be absent;
otherwise
1.2.2.1 One of ref or name must be present, but not both;
1.2.2.2 equivClass and final must be absent;
1.2.2.3 If ref is present, then all of complexType, simpleType, type, key, unique and keyref must be absent;
1.3 type and either simpleType or complexType are mutually exclusive;
1.4 The corresponding particle and/or element declarations must satisfy the conditions set out in Element Declaration Constraints (§6.3.2) and Particle Constraints (§6.3.10).

4.4.3 XML Representation of Complex Type Definition Schema Components

The XML representation for a complex type definition schema component is a complexType element information item. It provides validation information for the [attributes] and [children] of an element information item in the form of attribute declarations and a content type. The correspondences between the properties of the information item and properties of the component(s) it corresponds to are as follows:

XML Representation SummarycomplexType Element Information Item

<complexType
  abstract = boolean : false
  base = QName
  block = #all or (possibly empty) subset of {extension, restriction, reproduction}
  content = elementOnly | empty | mixed | textOnly
  derivedBy = extension | restriction | reproduction
  final = #all or (possibly empty) subset of {extension, restriction, reproduction}
  id = ID
  name = NCName>
  Content: (annotation? , (((minBound | minExclusive | minInclusive | maxBound | maxExclusive | maxInclusive | precision | scale | length | minlength | maxlength | encoding | period | enumeration | pattern)* | ((element | group | all | choice | sequence | any))*) , (((attribute | attributeGroup)* , anyAttribute?))))
</complexType>

<attributeGroup
  id = ID
  name = NCName
  ref = QName>
  Content: (annotation? , (attribute | attributeGroup)* , anyAttribute?)
</attributeGroup>

<anyAttribute
  namespace = ##any | ##other | ##local | list of {uri, ##targetNamespace} : ##any
/>

Complex Type Definition Schema Component
PropertyRepresentation
{name}The value of the name [attribute] if present, otherwise null
{target namespace}The value of the targetNamespace [attribute] of the schema ancestor element information item if present, otherwise null
{base type definition}The type definition resolved to by the value of the base [attribute], if present, otherwise the simple ur-type definition if the content [attribute] is textOnly, otherwise the complex ur-type definition
{derivation method}If the derivedBy [attribute] is present, the member of the set {extension, restriction, reproduction} corresponding to its value, otherwise if there are any [children] other than annotation then restriction, otherwise reproduction
{abstract}The value of the abstract [attribute], if present, otherwise false
{attribute declarations}The union of the set of attribute declarations corresponding to the attribute [children] of the item, if any, with the {attribute declarations} of the attribute groups resolved to by the values of the ref [attribute] of the attributeGroup [children], if any. In the latter case, if the {target namespace} of any referenced group is not identical to the {target namespace} of this type definition, the attribute declarations are not the attribute declarations from the corresponding {attribute declarations} as such, but distinct attribute declarations sharing all properties with them except for {target namespace}, which has the value of {target namespace}s from their original containing group.
{attribute wildcard}
  1. If there are no attributeGroup [children] corresponding to attribute groups with non-null {attribute wildcard}s, a value depending on the string value of the namespace [attribute] of the anyAttribute if there is one as follows:
    ##any
    any
    ##other
    a pair of not and the value of the targetNamespace [attribute] of the schema ancestor element information item if present, otherwise null
    otherwise
    a set whose members are namespace URIs corresponding to the whitespace-delimited substrings of the string, except
    • if one such substring is ##targetNamespace, the corresponding member is the value of the targetNamespace [attribute] of the schema ancestor element information item if present, otherwise null
    • if one such substring is ##local, the corresponding member is null
    otherwise null.
  2. Otherwise the intensional intersection of a value as defined in (1) above and all the non-null {attribute wildcard}s of the attribute groups corresponding to the attributeGroup [children], as defined in Attribute Wildcard Intersection (§6.3.4).
{content type}
  1. If the content [attribute] is empty, then empty;
  2. otherwise if the base [attribute] is present and either the type definition resolved to by the value of the base [attribute] is a simple type definition, or it is a complex type definition whose own {content type} is a simple type definition, then a simple type definition which restricts that simple type definition with the facets corresponding to the minBound, minExclusive, minInclusive, maxBound, maxExclusive, maxInclusive, precision, scale, length, minlength, maxlength, encoding, period, enumeration and pattern [children], if any, as defined in Simple Type Restriction (Facets) (§4.4.11).
  3. otherwise if the content [attribute] is elementOnly or mixed, a pair of that value and a particle as follows:

    [Definition:]  Let the explicit particle be as follows:
    1. If there is exactly one all, choice or sequence among the [children] and no any, group or element [children], then the particle corresponding to that all, choice or sequence;
    2. otherwise if the content [attribute] is elementOnly then a particle whose properties are as follows:
      {min occurs}
      1
      {max occurs}
      1
      {term}
      A model group whose {compositor} is sequence and whose {particles} is the sequence of particles corresponding to all the all, choice, sequence, any, group or element items among the [children], in order.
    3. otherwise if the content [attribute] is mixed then a particle whose properties are as follows:
      {min occurs}
      0
      {max occurs}
      *
      {term}
      A model group whose {compositor} is choice and whose {particles} are as above for the elementOnly case.

    The actual value then depends on the derivedBy [attribute] as follows:
    1. If it is restriction or reproduction, then the explicit particle itself;
    2. If it is extension, then if the type definition resolved to by the value of the base [attribute] has a {content type} of empty, the explicit particle itself, otherwise a particle whose properties are as follows:
      {min occurs}
      1
      {max occurs}
      1
      {term}
      A model group whose {compositor} is sequence and whose {particles} are the particle of the the {content type} of the type definition resolved to by the value of the base [attribute] followed by the explicit particle.
    3. If it is absent, then the explicit particle itself (this can only happen if the base is the ur-type).
  4. otherwise (the content [attribute] is textonly but there is no base [attribute]) the simple ur-type definition
{prohibited-substitutions}A set corresponding to the normalised value of the block [attribute], if present, otherwise on the value of the blockDefault [attribute] of the parent schema element information item, if present, otherwise on the empty string, as follows:
the empty string
the empty set;
#all
{extension, restriction, reproduction};
otherwise
a set with members drawn from the set above, each being present or absent depending on whether the string contains an equivalently named whitespace-delimited substring.
NOTE: Although the blockDefault [attribute] of schema may include the values equivClass and list, these values are ignored in the determination of {prohibited-substitutions} for type definitions (it is used in the determination of {disallowed substitutions} for element declarations)
{final}As for {prohibited-substitutions} above
{annotation}The annotation corresponding to the annotation element information item in the [children], if present, otherwise null

Ed. Note: base requires derivedBy; attrs unique; facets requires base

[Unrestructured material elided]

4.4.4 XML Representation of Attribute Group Definition Schema Components

The XML representation for an attribute group definition schema component is an attributeGroup element information item. It provides for naming a group of attribute declarations and an attribute wildcard for use in complex type definitions and other attribute group definitions. The correspondences between the properties of the information item and properties of the component it corresponds to are as follows:

XML Representation SummaryattributeGroup Element Information Item

<attributeGroup
  id = ID
  name = NCName
  ref = QName>
  Content: (annotation? , (attribute | attributeGroup)* , anyAttribute?)
</attributeGroup>

When an attributeGroup appears as a daughter of schema, it corresponds to an attribute group definition as below. When it appears as a daughter of complexType or attributeGroup, it does not correspond to any component as such.

Attribute Group Definition Schema Component
PropertyRepresentation
{name}The value of the name [attribute]
{target namespace}The value of the targetNamespace [attribute] of the parent schema element information item.
{attribute declarations}The union of the set of attribute declarations corresponding to the attribute [children] of the item, if any, with the {attribute declarations} of the attribute groups resolved to by the values of the ref [attribute] of the attributeGroup [children], if any. In the latter case, if the {target namespace} of any referenced group is not identical to the {target namespace} of this group definition, the attribute declarations are not the attribute declarations from the corresponding {attribute declarations} as such, but distinct attribute declarations sharing all properties with them except for {target namespace}, which has the value of {target namespace}s from their original containing group.
{attribute wildcard}As for {attribute wildcard} as described in XML Representation of Complex Type Definition Schema Components (§4.4.3)
{annotation}The annotation corresponding to the annotation element information item in the [children], if present, otherwise null

[Unrestructured material elided]

4.4.5 XML Representation of Model Group Definition Schema Components

This reconstructs another common use of parameter entities.

XML Representation Summarygroup Element Information Item

<group
  id = ID
  maxOccurs = string
  minOccurs = non-negative-integer : 1
  name = NCName
  ref = QName>
  Content: (annotation? , ((element | group | all | choice | sequence | any))*)
</group>

If there is a name [attribute] (in which case the item will have schema as parent), then the item corresponds to the a model group definition component with properties as follows:

Model Group Definition Schema Component
PropertyRepresentation
{name}The value of the name [attribute]
{target namespace}The value of the targetNamespace [attribute] of the parent schema element information item.
{model group}a sequence of particles corresponding to all the all, choice, sequence, any, group or element items among the [children], in order
{annotation}The annotation corresponding to the annotation element information item in the [children], if present, otherwise null

Otherwise, the item will have a ref [attribute], in which case it corresponds to a particle component with properties as follows:

Particle Schema Component
PropertyRepresentation
{min occurs}The value of the minOccurs [attribute], if present, otherwise 1
{max occurs}*, if the maxOccurs [attribute] equals *, otherwise the numeric value of the maxOccurs [attribute], if present, otherwise the value of the minOccurs [attribute], if present, otherwise 1.
{term}the value of the {model group} of the model group definition resolved to by the value of the ref [attribute]

[Unrestructured material elided]

4.4.6 XML Representation of Model Group Schema Components

XML Representation Summaryall Element Information Item

<all
  id = ID
  maxOccurs = string
  minOccurs = non-negative-integer : 1>
  Content: (annotation? , ((element | group | all | choice | sequence | any))*)
</all>

<choice
  id = ID
  maxOccurs = string
  minOccurs = non-negative-integer : 1>
  Content: (annotation? , ((element | group | all | choice | sequence | any))*)
</choice>

<sequence
  id = ID
  maxOccurs = string
  minOccurs = non-negative-integer : 1>
  Content: (annotation? , ((element | group | all | choice | sequence | any))*)
</sequence>

Each of the above items corresponds to a particle containing a model group, with properties as follows:
Particle Schema Component
PropertyRepresentation
{min occurs}The value of the minOccurs [attribute], if present, otherwise 1
{max occurs}*, if the maxOccurs [attribute] equals *, otherwise the numeric value of the maxOccurs [attribute], if present, otherwise the value of the minOccurs [attribute], if present, otherwise 1.
{term}A model group as given below
Model Group Schema Component
PropertyRepresentation
{compositor}On of all, choice, sequence depending on the element information item
{particles}a sequence of particles corresponding to all the all, choice, sequence, any, group or element items among the [children], in order
{annotation}The annotation corresponding to the annotation element information item in the [children], if present, otherwise null

[Unrestructured material elided]

4.4.7 XML Representation of Wildcard Schema Components

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 (localised) 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.

XML Representation Summaryany Element Information Item

<any
  maxOccurs = string
  minOccurs = non-negative-integer : 1
  namespace = ##any | ##other | ##local | list of {uri, ##targetNamespace} : ##any
  processContents = lax | skip | strict : strict
/>

Wildcard Schema Component
PropertyRepresentation
{namespace constraint}[In the obvious way from the namespace [attribute] -- ##other turns in to not ##targetNamespace]
{annotation}The annotation corresponding to the annotation element information item in the [children], if present, otherwise null

Ed. Note: The above not complete yet -- processContents needs to be added to the wildcard component, and the correspondences above filled in.

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

[Unrestructured material elided]

4.4.8 XML Representation of Identity-constraint Definition Schema Components

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.

XML Representation Summaryunique Element Information Item

<unique
  id = ID
  name = NCName>
  Content: (annotation? , selector , field+)
</unique>

<key
  id = ID
  name = NCName>
  Content: (annotation? , selector , field+)
</key>

<keyref
  id = ID
  name = NCName
  refer = QName>
  Content: (annotation? , selector , field+)
</keyref>

<selector>
  Content: XPathExprApprox : An XPath expression
</selector>

<field>
  Content: XPathExprApprox : An XPath expression
</field>

Identity-constraint Definition Schema Component
PropertyRepresentation
{name}The value of the name [attribute]
{target namespace}The value of the targetNamespace [attribute] of the parent schema element information item.
{identity-constraint category}[per the element involved]
{selector}[from the selector]
{fields}[from the fields]
{referenced key}[only for keyref, resolved from refer [attribute]]
{annotation}The annotation corresponding to the annotation element information item in the [children], if present, otherwise null

Ed. Note: Not complete, above property correspondences need to be filled in.

The XPathExprApprox simple type referenced above is defined in (normative) Schema for Schemas (§A). It is a permissive approximation to the syntax of XPath expressions as defined in [XPath], and is not an accurate reconstruction of that syntax. Its use by reference from other schema documents is deprecated: In due course a schema for XPath will be published which includes a simple type definition appropriate for widespread use.

[Unrestructured material elided]

4.4.9 XML Representation of Notation Declaration Schema Components

A notation may be declared by specifying a name and an identifier for the notation.

XML Representation Summarynotation Element Information Item

<notation
  id = ID
  name = NCName
  public = A public identifier, per ISO 8879
  system = uri-reference>
  Content: (annotation?)
</notation>

Notation Declaration Schema Component
PropertyRepresentation
{name}The value of the name [attribute]
{target namespace}The value of the targetNamespace [attribute] of the parent schema element information item.
{system identifier}[from the system [attribute]]
{public identifier}[from the public [attribute]]
{annotation}The annotation corresponding to the annotation element information item in the [children], if present, otherwise null

Ed. Note: Not complete, above property correspondences need to be filled in.

Example
<notation name="jpeg"
          public="image/jpeg" system="viewer.exe" />

<element name="picture">
 <type base="binary" derivedBy="extension">
  <attribute name="pictype" type="NOTATION"/>
 </type>
</element>

<picture pictype="jpeg">...</picture>

4.4.10 XML Representation of Annotation Schema Components

Annotation of schemas and schema components, with material for human or computer consumption, is provided for by allowing application information and human information at the beginning of most major schema elements, and anywhere at the top level of schemas.

XML Representation Summaryannotation Element Information Item

<annotation>
  Content: (appinfo | documentation)*
</annotation>

Annotation Schema Component
PropertyRepresentation
{application information}[from the appinfo [children]]
{user information}[from the documentation [children]

Ed. Note: Not complete, above property correspondences need to be filled in.

{user information} is intended for human consumption, {application information} for automatic processing. In both cases, provision is made for an optional URI reference to supplement the local information. Schema validation does not involve dereferencing these URIs, when present. In the case of {user information}, indication may be given as to the identity of the (human) language used in the contents, using the xml:lang attribute.

4.4.11 XML Representation of Simple Type Definition Schema Components

See [XML Schemas: Datatypes]

[Unrestructured material elided]

Schema Representation Constraint: Simple Type Restriction (Facets)
A simple type definition restricts another simple type definition with a set of facets if: watch this space.

5 Schema Access and Composition

This chapter defines the mechanisms by which we establish the necessary precondition for establishing schema-validity, namely access to one or more schemas. This chapter also describes in detail related mechanisms for using in one schema, definitions and declarations from another.

Chapter 6 provides a formal definition of schema-validation. Here we set out in detail the 3-layer architecture implied by the preceding chapters which prepares for that formal definition and relates it to XML documents and WWW-situated processes. This layering is provided to maximise the range of environments in which this specification can be applied, and to minimise the need for modifications to this specification as new standards and conventions for Web interoperability are developed. The layers are:

  1. The schema-validation core, relating schema components and instance information items;
  2. Schema representation: the connections between XML representations and schema components, including the relationships between namespaces and schema components;
  3. XML Schema web-interoperability guidelines: instance->schema and schema->schema connections for the WWW.

Layer 1 specifies the manner in which a schema composed of schema components can be applied to validate an instance element information item. Layer 2, which is primarily defined in Chapter 4, specifies the use of schema elements in XML documents as the standard XML representation for schema information in a broad range of computer systems and execution environments. To support interoperation over the World Wide Web in particular, layer 3 provides a set of conventions for schema reference on the Web.

We note that improved or alternative conventions for Web interoperability can be standardised in the future without reopening this recommendation. For example, the W3C is currently considering initiatives to standardise the packaging of resources relating to particular documents and/or namespaces: this would be an addition to the mechanisms described here for layer 3. This architecture also facilitates innovation at layer 2: for example, it would be possible in the future to define an additional standard for the representation of schema components which allowed e.g. type definitions to be specified piece by piece, rather than all at once.

5.1 Layer 1: Summary of the schema-validation core

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 complex 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 schema (note not a schema document) 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 schema.

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 optimise or pre-compile) the entire schema prior to the start of a validation episode, or to gather the schema lazily as individual components are required. In all cases it is required that:

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 complex type definition against the background of a schema.

Ed. Note: We need to add more to this now that we've allowed partial processing under <any/>

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 complex type definition and schema 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 schema 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 schema replacing the one initially employed.

5.2 Layer 2: Schema definitions in XML

This is described in XML Representation of Schemas and Schema Components (§4), which defines an XML representation for type definitions and element declarations and so on, specifying their target namespace and collecting them into schema documents.

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

5.2.1 Assembling a schema for a single namespace from multiple schema definition documents

XML Representation Summaryinclude Element Information Item

<include
  schemaLocation = uri-reference
/>

[Unrestructured material elided]

5.2.2 References to schema components across namespaces

As described in XML Schema Abstract Data Model (§2.2), every global schema component is associated with a target namespace (or, explicitly, with none). In this section we set out the exact mechanism and syntax in the XML form of schema definition by which a reference to a foreign component is made, that is, a component with a different target namespace from that of the referring component.

We require not only a means of addressing such foreign components but also a signal to schema-aware processors that a schema document contains such preferences and differentiates two subtly different cases:

XML Representation Summaryimport Element Information Item

<import
  namespace = uri-reference
  schemaLocation = uri-reference
/>

[Unrestructured material elided]

Schema Representation Constraint: Schema Composition
The schema which corresponds to a schema document (that is, a schema element information item) contains all the primary and secondary schema components which correspond to the immediate element information item [children] of that schema document, together with any primary or secondary components which are:
1.1 contained in a schema identified by an include element information item from among the [children] of that schema document;
or
1.2 contained in a schema identified by an import element information item from among the [children] of that schema document;

[Unrestructured material elided]

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

5.3.1 Standards for representation and retrieval of schema definitions on the Web

For interoperability, schema definitions like all other Web resources are identified by URI and retrieved using the standard mechanisms of the Web (e.g. http, https, etc.) Schema definitions on the Web must be part of documents with the mime type text/xml, and are represented in the standard XML schema definition form described by layer two (I.e. as <schema> elements).

NOTE: there will often be times when a schema definition will be a complete XML 1.0 document with a root element of <schema>. There will be other occasions in which <schema> elements will be contained in other documents, perhaps referenced using fragment and/or Xpointer notation.

5.3.2 How schema definitions are located on the Web

As described in Layer 1: Summary of the schema-validation core (§5.1), processors are responsible for providing the schema components (definitions and declarations) needed for validation. This section introduces a set of normative conventions to facilitate interoperability for instance documents and schemas retrieved and validated from the Web.

NOTE: As discussed above in Layer 2: Schema definitions in XML (§5.2), other non-Web mechanisms for delivering schemas for validation may exist, but are outside the scope of this recommendation.

The validation mechanisms of Layer 1: Summary of the schema-validation core (§5.1) specify that schema-valid applies to an element information item to be validated, and the type to be used to validate it. Documents on the Web can be validated in their entirety, from the document root element, or else individual elements can be selectively validated.

Processors on the Web are free to attempt validation against arbitrary complete component sets (as defined in Layer 1: Summary of the schema-validation core (§5.1)) and against any type. However, it is useful to have a common convention for determining a complete component set, and an initial type. For this purpose, we require that for general-purpose schema-aware processors (i.e. those not specialised to one or a fixed set of pre-determined schemas), unless directed otherwise by a user the element information item to be validated is either the document element of an information set, or the local root of a new namespace-governed region within an information set.

To determine the type declaration to be used for the validation in these cases, the processor is required to retrieve a schema document with a "targetNamespace" identical to the namespace URI, if any, of the element information item to be validated. Again, unless directed otherwise, the processor must locate within that schema a global element declaration with an NCName matching that of the element information item to be validated. The processor must ensure that both the element declaration, and the type declaration used in that element declaration, are included in the complete component set for the validation. The type thus identified is the type used for validation of the element information item. The composition of the complete component set for validation is governed by Layer 2: Schema definitions in XML (§5.2) above.

The means used to locate appropriate schema document(s) are processor and application dependent, subject to a following requirements:

  • Schemas are represented on the Web in the form specified by Chapter 3.
  • The author of a document uses namespace declarations to indicate the intended interpretation of names appearing therein; there may not be a schema retrievable via the namespace URI. Processors should not attempt to dereference namespace URIs unless explicitly directed to do so.
    NOTE: Experience suggests that it is not in general safe or desirable from a performance point of view to dereference NS URIs as a matter of course. User community and/or consumer/provider agreements may establish conventions which make this a sensible strategy: This recommendation allows but does not require this. Users are always free to supply namespace URIs as schema location information when dereferencing is desired: see below.
  • On the other hand, in case a document author (human or not) created a document with a particular schema in view, and warrents that some or all of the document is schema-valid per that schema, we provide the "schemaLocation" attribute (in the XML Schema namespace) to record this fact with pairs of URI references (one for the namespace URI, and one for the schema definition).

    Again, unless directed otherwise general-purpose schema-aware processors must attempt to dereference each schema URI in the value of "schemaLocation" to obtain a schema, whose target namespace must be identical to the namespace it appears in conjunction with, if any. Failure to dereference the URI, failure to locate a valid document of mime type text/xml, failure to find a <schema> or mismatch of the targetNamespace URI is an error.
  • "schemaLocation" attributes can occur on any element participating in a validation, and all such attributes must be processed as if they had occurred at the validation root. According to the rules of Layer 1: Summary of the schema-validation core (§5.1), the complete component set can be lazily assembled, but is otherwise stable throughout a validation. Although schema location attributes can occur on any element, and can be processed incrementally as discovered, their effect is essentially global to the validation. Definitions and declarations remain in effect beyond the scope of the element on which the binding is declared.
NOTE: The issue of the value space for QNames, in particular in the case of prefixes with no declaration, needs to be carefully elucidated in the Datatype draft.

Multiple schema bindings can be declared using a single attribute. For example consider a stylesheet:

 <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"
NOTE: the namespace URIs used in "schemaLocation" can, but need not be identical to those actually qualifying the element within whose start tag it is found or its other attributes. For example, all schema location information can be declared on the document element of a document, if desired, regardless of where the namespaces are actually used.

Ed. Note: Need to worry about the 'no namespace' case -- what do I put in "schemaLocation" if I don't declare _any_ namespaces?

Ed. Note: We've left ourselves with no way in a component which _does_ have a target namespace to refer to a component with none.

6 Conformance *

Ed. Note: This section is incomplete

Issue (error-behavior): This draft includes extensive discussion of conformance and validity checking, but the distinction between invalidity and schema errors is not clearly drawn, nor is the significance of either defined. In future, we must clarify rules for both.

6.1 Schema Validity *

[Unrestructured material elided]

[Unrestructured material elided]

6.2 Missing Sub-components

Ed. Note: Something about uniform treatment of missing sub-components needed.

6.3 Detailed Validity Constraints on Schema Components *

6.3.1 Attribute Declaration Constraints

All attribute declarations (see Attribute Declaration Details (§3.1)) must satisfy the following constraints.

Constraint on Schemas: Attribute Declaration Properties Correct
1 The values of the properties of an attribute declaration must be as described in the property tableau in Attribute Declaration Details (§3.1), modulo the impact of Missing Sub-components (§6.2);
2 {min occurs} must not be 1 if {max occurs} is 0;
3 if there is a {value constraint}, its string must be schema-valid with respect to the {simple type definition}.
Constraint on Schemas: xmlns Not Allowed
The {name} of an attribute declaration must not match xmlns.
NOTE: The {name} of an attribute is an NCName, which implicitly prohibits namespace declarations of the form xmlns:*

6.3.2 Element Declaration Constraints

Constraint on Schemas: Element Declaration Properties Correct
All element declarations (see Element Declaration Details (§3.2)) must satisfy the following constraint:
1 The values of the properties of an element declaration must be as described in the property tableau in Element Declaration Details (§3.2), modulo the impact of Missing Sub-components (§6.2);
2 If there is a {value constraint}, its string must be schema-valid with respect to the {type definition} as defined in Element Default Valid (Immediate) (§6.3.2);
3 If there is an {equivalence class affiliation}, the {type definition} of the element declaration must be validly derived from the {type definition} of the {equivalence class affiliation} given the value of the {equivalence class exclusions} of the {equivalence class affiliation}, as defined in Type Derivation OK (Complex) (§6.3.11) (if the {type definition} is complex) or Type Derivation OK (Simple) (§6.3.12) (if the {type definition} is simple).

The following constraint notes define relations appealed to elsewhere in this specification.

Constraint on Schemas: Element Default Valid (Immediate)
A string is a valid default with respect to a type definition if
1.1 The type definition is a simple type definition, and the string is schema-valid with respect to that definition as defined by String Valid (§3.12)
or
1.2 The type definition is a complex type definition whose {content type} is a simple type definition, and the string is schema-valid with respect to that simple type definition as defined by String Valid (§3.12)
or
1.3 The type definition is a complex type definition whose {content type} is mixed, and the {content type}'s particle is emptiable as defined by Particle Emptiable (§6.3.10).
Constraint on Schemas: Equivalence Class OK (Transitive)
An element declaration together with an blocking constraint (a subset of {}, the value of a {disallowed substitutions}) is validly equivalent to another element declaration if: watch this space

6.3.3 Identity-constraint Definition Constraints

6.3.4 Attribute Group Definition Constraints

Constraint on Schemas: Unique Attribute Declaration (Group)
Two distinct members of an attribute group's {attribute declarations} may not contain both {name}s which match and {target namespace}s which are identical.
Constraint on Schemas: Attribute Wildcard Intersection
An attribute wildcard value is the intensional intersection of two or more other such values if [based on the obvious interpretation of any as the universal set, not as set complement].

6.3.5 Wildcard Constraints

6.3.6 Model Group Definition Constraints

6.3.7 Model Group Constraints

6.3.8 Notation Constraints

6.3.9 Annotation Constraints

6.3.10 Particle Constraints

Constraint on Schemas:
If {max occurs} is not *, that is, it has a numeric value, then
1.1 {min occurs} must not be greater than {max occurs};
1.2 {max occurs} must greater than or equal to 1;
Constraint on Schemas: Particle Valid
[Definition:]  watch this space [Definition:]  watch this space
Constraint on Schemas: Particle Emptiable
[Definition:]  watch this space

6.3.11 Complex Type Definition Constraints

Constraint on Schemas: Derivation Valid (Extension)
If the {derivation method} is extension: [Definition:]  If this constraint holds of a complex type definition, we say it is a valid extension of its {base type definition}.
Constraint on Schemas: Derivation Valid (Restriction, Complex)
If the {derivation method} is restriction: [Definition:]  If this constraint holds of a complex type definition, we say it is a valid restriction of its {base type definition}.
NOTE: Any complex type definition constructed from an XML representation as specified in XML Representation of Complex Type Definition Schema Components (§4.4.3) is guaranteed to satisfy whichever of the above two constraints is appropriate given the nature of its {base type definition}.
Constraint on Schemas: Type Derivation OK (Complex)
A complex type definition is validly derived from a type definition given a subset of {??fix this??} if:
1 The are the same type definition
or watch this space.

6.3.12 Simple Type Definition Constraints

Constraint on Schemas: Derivation Valid (Restriction, Simple)
[Definition:]  watch this space
Constraint on Schemas: Type Derivation OK (Simple)
A simple type definition is validly derived from a simple type definition given a subset of {??fix this??} if:
1 The are the same type definition
or watch this space.

6.3.13 The Schema *

[Unrestructured material elided]

6.3.14 References to Schema Components *

[Unrestructured material elided]

6.3.15 Types, Elements and Attributes *

6.3.15.1 Datatypes *

[Unrestructured material elided]

6.3.15.2 Type Definition *

[Unrestructured material elided]

6.3.15.3 Attribute Declaration *

[Unrestructured material elided]

6.3.15.4 Element Content Model *

[Unrestructured material elided]

6.3.15.5 Mixed Content *

[Unrestructured material elided]

6.3.15.6 Element-only Content *

[Unrestructured material elided]

6.3.15.7 Element Declaration *

[Unrestructured material elided]

6.3.16 Type Refinement *

[Unrestructured material elided]

6.3.17 Import Restrictions *

[Unrestructured material elided]

6.3.18 Schema Inclusion *

[Unrestructured material elided]

6.3.19 Schema Validity *

[Unrestructured material elided]

6.4 Responsibilities of Schema-aware processors *

[Unrestructured material elided]


A (normative) Schema for Schemas

The XML Schema definition for XML Schema: Structures itself is presented here as normative part of the specification, and as an illustrative example of the XML Schema in defining itself with the very constructs that it defines. The names of XML Schema language types, elements, attributes and groups defined here are evocative of their purpose, but are occasionally verbose.

There is some annotation in comments, but a fuller annotation will require the use of embedded documentation facilities or a hyperlinked external annotation for which tools are not yet readily available.

Since an XML Schema: Structures is an XML document, it has optional XML and doctype declarations that are provided here for completeness. The root schema element defines a new schema. Since this is a schema for XML Schema: Structures, the targetNamespace references the XML Schema namespace itself.

<?xml version='1.0'?>
<!-- XML Schema schema for XML Schemas: Part 1: Structures -->
<!-- Note this schema is NOT the normative structures schema - - the
     prose copy in the structures REC is the normative version (which
     shouldn't differ from this one except for this comment and entity
     expansions, but just in case -->
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSCHEMA 19991216//EN" "structures.dtd" >
<schema xmlns="&XMLSchemaNS;" targetNamespace="&XMLSchemaNS;" blockDefault="#all" version="$Id: structures.html,v 1.3 2017/10/02 10:23:19 denis Exp $">

  <!-- The datatype element and all of its members are defined
       in XML Schema: Part 2: Datatypes -->

  <include schemaLocation="&XSP2.URI;.xsd"/>

  <element name="schemaTop" abstract="true" type="annotated">
   <annotation>
    <documentation>This abstract element defines an equivalence class over the
          elements which occur freely at the top level of schemas.
          These are: datatype, type, element, attributeGroup, group, notation
          All of their types are based on the "annotated" type
          by extension.</documentation>
   </annotation>
  </element>

  <!-- schema element -->

  <element name="schema">
    <complexType base="openAttrs" derivedBy="extension" content='elementOnly'>
      <sequence>
       <choice minOccurs="0" maxOccurs="*">
        <element ref="include"/>
        <element ref="import"/>
        <element ref="annotation"/>
       </choice>
      <sequence minOccurs="1" maxOccurs="*">
	 <element ref="schemaTop"/>
	 <element ref="annotation" minOccurs="0" maxOccurs="*"/>
      </sequence>
    </sequence>
    <attribute name="targetNamespace" type="uri-reference"/>
    <attribute name="version" type="string"/>
    <attribute name="finalDefault" type="derivationSet" default=""/>
    <attribute name="blockDefault" type="blockSet" default=""/>
    <attribute name="id" type="ID"/>
   </complexType>

   <key name="element">
    <selector>element</selector>
    <field>@name</field>
   </key>

   <key name="complexType">
    <selector>complexType</selector>
    <field>@name</field>
   </key>
 
   <key name="group">
    <selector>group</selector>
    <field>@name</field>
   </key>
 
   <key name="attributeGroup">
    <selector>attributeGroup</selector>
    <field>@name</field>
   </key>
 
   <key name="notation">
    <selector>notation</selector>
    <field>@name</field>
   </key>
   
   <key name="simpleType">
    <selector>simpleType</selector>
    <field>@name</field>
   </key>

   <key name="keyOrUnique">
    <selector>.//key|.//unique</selector>
    <field>@name</field>
   </key>
   
   <key name="constraint">
    <selector>.//key|.//unique|.//keyref</selector>
    <field>@name</field>
   </key>
   
   <key name="keyref">
    <selector>.//keyref</selector>
    <field>@name</field>
   </key>

  </element>

  <!-- For references to a type -->
  <!-- 'element', 'attribute' and any all use this  -->

  <attributeGroup name="typeRef">
    <attribute name="type" type="QName"/>
  </attributeGroup>

  <!-- For 'element' and 'attribute' -->
  <attributeGroup name="valueConstraint">
   <attribute name="default" type="string"/>
   <attribute name="fixed" type="string"/>
  </attributeGroup>


  <!-- for all particles -->
  <attributeGroup name="occurs">
    <attribute name="minOccurs" type="non-negative-integer" default="1"/>
    <attribute name="maxOccurs" type="string"/> <!-- allows '*', so integer
                                                       won't do -->
  </attributeGroup>

  <!-- for element, group and attributeGroup, which both define and reference -->
  <attributeGroup name="defRef">
   <attribute name="name" type="NCName" minOccurs="0"/>
   <attribute name="ref" type="QName" minOccurs="0"/>
  </attributeGroup>

  <!-- 'element', 'group' and 'any' -->
  <group name="particle">
   <choice>
   <element ref="element"/>
   <element ref="group"/>
   <element ref="all"/>
   <element ref="choice"/>
   <element ref="sequence"/>
   <element ref="any"/>
   </choice>
  </group>
 
  <element name="sic">
   <complexType content="empty"/>
  </element>

  <group name="attrDecls">
   <sequence>
    <choice minOccurs="0" maxOccurs="*">
     <element ref="attribute"/>
     <element ref="attributeGroup"/>
    </choice>
    <element ref="anyAttribute" minOccurs="0"/>
   </sequence>
  </group>

 <element name="anyAttribute">
  <complexType name="anyAttribute" content="empty">
   <attribute name="namespace" type="namespaceList" default="##any"/>
  </complexType>
 </element>

  <!-- types for type -->

  <complexType name="complexType" base="annotated" derivedBy="extension" abstract="true">
   <sequence>
    <choice>
     <element ref="facet" minOccurs="0" maxOccurs="*"/>
         <!-- max 1, min 0, for each facet except pattern, period-->
     <group ref="particle" minOccurs="0" maxOccurs="*"/>
    </choice>
    <group ref="attrDecls"/>
   </sequence>
   <attribute name="name" type="NCName" minOccurs="0">
    <annotation>
     <documentation>Will be restricted to required or forbidden</documentation>
    </annotation>
   </attribute>
   <attribute name="content">
    <simpleType base="NMTOKEN">
     <enumeration value="elementOnly"/>
     <enumeration value="textOnly"/>
     <enumeration value="mixed"/>
     <enumeration value="empty"/>
    </simpleType>
   </attribute>
   <attribute name="base" type="QName"/>
   <attribute name="derivedBy" type="derivationChoice"/>
   <attribute name="abstract" type="boolean" default="false"/>
   <attribute name="final" type="derivationSet"/>
   <attribute name="block" type="derivationSet"/>
  </complexType>
 
  <complexType name="namedType" base="complexType" derivedBy="restriction">
   <annotation>
    <documentation>This was for the top-level type element, daughter of &lt;schema</documentation>
   </annotation>
    <attribute name="name" minOccurs="1">
     <annotation><documentation>Required at the top level</documentation></annotation>
    </attribute>
  </complexType>
 
  <complexType name="anonType" base="complexType" derivedBy="restriction">
   <annotation>
    <documentation>This was for the nested type element, daughter of &lt;element</documentation>
   </annotation>
    <attribute name="name" maxOccurs="0">
     <annotation><documentation>Forbidden when nested</documentation></annotation>
    </attribute>
  </complexType>

  <!-- Top level type element, daughter of schema -->
  <element name="complexType" equivClass="schemaTop" type="complexType"/> 
 
  <simpleType name="derivationChoice" base="NMTOKEN">
   <annotation>
    <documentation>A utility type, not for public use</documentation>
   </annotation>
   <enumeration value="extension"/>
   <enumeration value="restriction"/>
   <enumeration value="reproduction"/>
  </simpleType>

  <simpleType name="blockSet" base="string">
   <annotation>
    <documentation>#all or (possibly empty) subset of {equivClass,
extension, list, restriction, reproduction}</documentation>
    <documentation>A utility type, not for public use</documentation>
    <documentation>Should be a sequence drawn from the values of derivationChoice
          plus 'equivClass' and 'list'
          or #all -- regexp is only an approximation</documentation>
   </annotation>
   <pattern value="#all?|(equivClass|extension|list|restriction|reproduction| )*"/>
  </simpleType>

  <simpleType name="derivationSet" base="string">
   <annotation>
    <documentation>#all or (possibly empty) subset of {extension,
restriction, reproduction}</documentation>
    <documentation>A utility type, not for public use</documentation>
    <documentation>Should be a sequence drawn from the values of derivationChoice,
          or #all -- regexp is only an approximation</documentation>
   </annotation>
   <pattern value="#all?|(extension|restriction|reproduction| )*"/>
  </simpleType>

  <!-- The element element can be used either
        at the toplevel to define an element-type binding globally,
        or within a content model to either reference a globally-defined
        element or type or declare an element-type binding locally.
       The ref form is not allowed at the top level -->

  <complexType name="element" base="annotated" derivedBy="extension">
     <choice minOccurs="0">
      <element ref="simpleType"/>
      <element ref="complexType"/>
     </choice>
     <element ref="identity-constraint" minOccurs="0" maxOccurs="*"/>
     <attributeGroup ref="defRef"/>
     <attributeGroup ref="typeRef"/>
     <attribute name="equivClass" type="QName"/>
     <attributeGroup ref="occurs"/>
     <attributeGroup ref="valueConstraint"/>
     <attribute name="nullable" type="boolean" default="false"/>
     <attribute name="abstract" type="boolean" default="false"/>
     <attribute name="final" type="derivationSet" default=""/>
     <attribute name="block" type="blockSet" default=""/>
    </complexType>

  <complexType name="namedElement" base="element" derivedBy="restriction">
    <attribute name="name" minOccurs="1"/> <!-- required at top level -->
    <attribute name="ref" maxOccurs="0"/> <!-- forbidden at top level -->
  </complexType>

  <element name="element" type="element" equivClass="schemaTop"/>

  <!-- group type for the three kinds of group -->
  <complexType name="explicitGroup" base="annotated" derivedBy="extension">
    <group ref="particle" minOccurs="0" maxOccurs="*"/>
    <attributeGroup ref="occurs"/>
  </complexType>

  <element name="all" type="explicitGroup"/>
  <element name="choice" type="explicitGroup"/>
  <element name="sequence" type="explicitGroup"/>

  <!-- group type for named top-level groups and group references -->
  <complexType name="group" base="explicitGroup" derivedBy="extension" abstract="true">
    <attributeGroup ref="defRef"/>
  </complexType>

  <complexType name="namedGroup" base="group" derivedBy="restriction">
    <attribute name="name" minOccurs="1"/> <!-- required at top level -->
    <attribute name="ref" maxOccurs="0"/> <!-- forbidden at top level -->
  </complexType>
 
  <complexType name="anonGroup" base="group" derivedBy="restriction">
    <!-- required at top level -->
    <attribute name="name" maxOccurs="0"/> <!-- forbidden when nested -->
  </complexType>

  <element name="group" equivClass="schemaTop" type="group"/>

  <!-- The wildcard specifier in content models -->

  <element name="any">
   <complexType content="empty" base="openAttrs" derivedBy="extension">
    <attribute name="namespace" type="namespaceList" default="##any"/>
    <attribute name="processContents" default="strict">
     <simpleType base="NMTOKEN">
      <enumeration value="skip"/>
      <enumeration value="lax"/>
      <enumeration value="strict"/>
     </simpleType>
    </attribute>
    <attributeGroup ref="occurs"/>
   </complexType>
  </element>

  <!-- simple type for the value of the 'namespace' attr of 'any' and
       'anyAttribute' -->
  <!-- Value is
                  ##any      - - any non-conflicting WFXML/attribute at all

                  ##other    - - any non-conflicting WFXML/attribute from
                                  namespace other than targetNS

                  ##local    - - any unqualified non-conflicting WFXML/attribute 

                  one or     - - any non-conflicting WFXML/attribute from
                  more URI        the listed namespaces
                  references
                  (space separated)

                ##targetNamespace may appear in the above list, to refer to the
                   targetNamespace of the enclosing schema -->

  <simpleType name="namespaceList" base="string">
   <annotation>
    <documentation>##any | ##other | ##local | list of {uri, ##targetNamespace}</documentation>
   <documentation>A utility type, not for public use</documentation>
   </annotation>
  </simpleType>

  <!-- the attribute element declares attributes -->

  <element name="attribute">
   <complexType base="annotated" derivedBy="extension">
    <element ref="simpleType" minOccurs="0"/>
    <attribute name="name" type="NCName" minOccurs="1"/>
    <attributeGroup ref="typeRef"/>
    <attribute name="minOccurs" default="0">
     <simpleType base="non-negative-integer">
       <enumeration value="0"/>
       <enumeration value="1"/>
     </simpleType>
    </attribute>
    <attribute name="maxOccurs" default="1">
     <simpleType base="non-negative-integer">
       <enumeration value="0"/>
       <enumeration value="1"/>
     </simpleType>
    </attribute>
    <attributeGroup ref="valueConstraint"/>
   </complexType>
  </element>

  <!-- attributeGroup element -->

  <complexType name="attributeGroup" base="annotated" derivedBy="extension" abstract="true">
     <choice minOccurs="0" maxOccurs="*">
      <element ref="attribute"/>
      <element ref="attributeGroup"/>
     </choice>
     <element ref="anyAttribute" minOccurs="0"/>
     <attributeGroup ref="defRef"/>
    </complexType>

 <complexType name="namedAttributeGroup" base="attributeGroup" derivedBy="restriction">
    <attribute name="name" minOccurs="1"/> <!-- required at top level -->
    <attribute name="ref" maxOccurs="0"/> <!-- forbidden at top level -->
 </complexType>

 <complexType name="anonAttributeGroup" base="attributeGroup" derivedBy="restriction">
    <attribute name="ref" minOccurs="1"/> <!-- required when nested -->
    <attribute name="name" maxOccurs="0"/> <!-- forbidden when nested -->
 </complexType>

 <element name="attributeGroup" type="attributeGroup" equivClass="schemaTop"/>

 <element name="include">
  <complexType content="empty" base="openAttrs" derivedBy="extension">
   <attribute name="schemaLocation" type="uri-reference" minOccurs="1"/>
  </complexType>
 </element>

 <element name="import">
  <complexType content="empty" base="openAttrs" derivedBy="extension">
   <attribute name="namespace" type="uri-reference" minOccurs="1"/>
   <attribute name="schemaLocation" type="uri-reference"/>
  </complexType>
 </element>
 
 <!-- Better reference mechanisms -->
 
 <complexType name="keybase" base="annotated" derivedBy="extension">
  <element ref="selector"/>
  <element ref="field" minOccurs="1" maxOccurs="*"/>
  <attribute name="name" type="NCName" minOccurs="1"/>
 </complexType>

 <element name="selector" type="XPathExprApprox"/>
 <element name="field" type="XPathExprApprox"/>

 <element name="identity-constraint" type="keybase" abstract="true"/>

 <element name="unique" equivClass="identity-constraint"/>
 <element name="key" equivClass="identity-constraint"/>
 <element name="keyref" equivClass="identity-constraint">
  <complexType base="keybase" derivedBy="extension">
   <attribute name="refer" type="QName" minOccurs="1"/>
  </complexType>
 </element>

 <simpleType name="XPathExprApprox" base="string">
  <annotation>
   <documentation>An XPath expression</documentation>
   <documentation>A utility type, not for public use</documentation>
  </annotation>
  <pattern value="(/|//|\.|\.\.|:|::|\||(\c-[.:/|])+)+">
   <annotation>
    <documentation>A VERY permissive definition,
                   probably not even right
    </documentation>
   </annotation>
  </pattern>
 </simpleType>
  <!-- notation element type -->

  <element name="notation" equivClass="schemaTop">
   <complexType base="annotated" derivedBy="extension">
    <attribute name="name" type="NCName" minOccurs="1"/>
    <attribute name="public" type="public" minOccurs="1"/>
    <attribute name="system" type="uri-reference"/>
   </complexType>
  </element>

  <simpleType name="public" base="string">
   <annotation>
   <documentation>A public identifier, per ISO 8879</documentation>
   <documentation>A utility type, not for public use</documentation>
   </annotation>
  </simpleType>

  <!-- notations for use within XML Schema schemas      -->

  <notation name="XMLSchemaStructures" public="structures" system="&XSP1.URI;.xsd"/>
  <notation name="XML" public="REC-xml-19980210" system="http://www.w3.org/TR/1998/REC-xml-19980210"/>
</schema>
NOTE: And that is the end of the schema for XML Schema: Structures.

B (normative) DTD for Schemas

The DTD for XML Schema: Structures is given below. Note there is no implication here the schema must be the root element of a document.

<!-- DTD for XML Schemas: Part 1: Structures -->
<!-- $Id: structures.html,v 1.3 2017/10/02 10:23:19 denis Exp $ -->
<!-- Note this DTD is NOT the normative structures DTD - - the
     prose copy in the structures REC is the normative version (which
     shouldn't differ from this one except for this comment and entity
     expansions, but just in case -->
<!ENTITY % versionEntities SYSTEM "../versionInfo.ent">
%versionEntities; <!-- get path and date entities -->

<!-- The the datatype element and its components
     are defined in XML Schema: Part 2: Datatypes -->
<!-- Note %p is defined in datatypes.dtd -->
<!ENTITY % xs-datatypes PUBLIC 'datatypes'
                     '../datatypes/datatypes.dtd' >
%xs-datatypes;

<!ENTITY % s ''> <!-- if %p is defined (e.g. as foo:) then you must
                      also define %s as the suffix for the appropriate
                      namespace declaration (e.g. :foo) -->
<!ENTITY % nds 'xmlns%s;'>

<!-- Define all the element names, with optional prefix -->
<!ENTITY % schema "%p;schema">
<!ENTITY % complexType "%p;complexType">
<!ENTITY % element "%p;element">
<!ENTITY % unique "%p;unique">
<!ENTITY % key "%p;key">
<!ENTITY % keyref "%p;keyref">
<!ENTITY % selector "%p;selector">
<!ENTITY % field "%p;field">
<!ENTITY % group "%p;group">
<!ENTITY % all "%p;all">
<!ENTITY % choice "%p;choice">
<!ENTITY % sequence "%p;sequence">
<!ENTITY % any "%p;any">
<!ENTITY % anyAttribute "%p;anyAttribute">
<!ENTITY % sic "%p;sic">
<!ENTITY % attribute "%p;attribute">
<!ENTITY % attributeGroup "%p;attributeGroup">
<!ENTITY % include "%p;include">
<!ENTITY % import "%p;import">
<!ENTITY % notation "%p;notation">

<!-- Customisation entities for the ATTLIST of each element type.
     Define one of these if your schema takes advantage of the
     anyAttribute='##other' in the schema for schemas -->

<!ENTITY % schemaAttrs ''>
<!ENTITY % complexTypeAttrs ''>
<!ENTITY % elementAttrs ''>
<!ENTITY % groupAttrs ''>
<!ENTITY % allAttrs ''>
<!ENTITY % choiceAttrs ''>
<!ENTITY % sequenceAttrs ''>
<!ENTITY % anyAttrs ''>
<!ENTITY % anyAttributeAttrs ''>
<!ENTITY % attributeAttrs ''>
<!ENTITY % attributeGroupAttrs ''>
<!ENTITY % uniqueAttrs ''>
<!ENTITY % keyAttrs ''>
<!ENTITY % keyrefAttrs ''>
<!ENTITY % includeAttrs ''>
<!ENTITY % importAttrs ''>
<!ENTITY % notationAttrs ''>

<!ENTITY % complexDerivationChoice "(extension|restriction|reproduction)">
<!ENTITY % complexDerivationSet "CDATA">
      <!-- #all or space-separated list drawn from derivationChoice -->
<!ENTITY % blockSet "CDATA">
      <!-- #all or space-separated list drawn from
                      derivationChoice + 'equivClass' and 'list' -->

<!ENTITY % mgs '%all; | %choice; | %sequence;'>
<!ENTITY % cs '%choice; | %sequence;'>

<!-- the duplication below is to produce an unambiguous content model
     which allows annotation everywhere -->
<!ELEMENT %schema; ((%include; | %import; | %annotation;)*,
                    (%simpleType; | %complexType;
                     | %element;
                     | %attributeGroup; | %group;
                     | %notation; ),
                    (%annotation;
                     | %simpleType; | %complexType;
                     | %element;
                     | %attributeGroup; | %group;
                     | %notation; )* )>
<!ATTLIST %schema;
     targetNamespace    %URIref;               #IMPLIED
     version            CDATA                  #IMPLIED
     %nds;              %URIref;               #FIXED '&XMLSchemaNS;'
     %dtnds;            %URIref;               #FIXED '&XMLSchemaNS;/datatypes'
     finalDefault       %complexDerivationSet; ''
     blockDefault       %blockSet;             ''
     id                 ID                     #IMPLIED
     %schemaAttrs;>
<!-- Note the xmlns declaration is NOT in the Schema for Schemas,
     because at the Infoset level where schemas operate,
     xmlns(:prefix) is NOT an attribute! -->
 
<!-- The id attribute here and below is for use in external references
     from non-schemas using simple fragment identifiers.
     It is NOT used for schema-to-schema reference, internal or
     external. -->

<!-- a type is a named content type specification which allows attribute
     declarations-->
<!-- -->

<!ELEMENT %complexType; ((%annotation;)?,
                 ((%facet;)*|
                  ((%element;| %mgs; | %group; | %any;)*,
                   (%attribute;| %attributeGroup;)*,
                   (%anyAttribute;)?)))>

<!ATTLIST %complexType;
          name      %NCName;                        #IMPLIED
          id        ID                              #IMPLIED
          content   (textOnly|mixed|elementOnly|empty) #IMPLIED
          abstract  %boolean;                       'false'
          final     %complexDerivationSet;          ''
          block     %complexDerivationSet;          ''
          derivedBy %complexDerivationChoice;       #IMPLIED 
          base      %QName;                         #IMPLIED
          %complexTypeAttrs;>

<!-- facets only if derivedBy='restriction' -->
<!-- (element|group|any) only if content=mixed or =elementOnly
     and NO derivedBy at all, i.e. a root type -->
<!-- content defaults to base's if there is a complex base,
     textonly if there's a simple base,
     'mixed' if no base (because that's the urType's content)
             and no content daughters,
     'elementOnly' otherwise --> 
<!-- should we replace content='empty' with content='elementOnly'
     final='#all' plus no content? -->

<!-- If one top-level group, that IS the content model, otherwise
     an implicit group obtains.
     This is
       <sequence minOccurs='1' maxOccurs='1'>
     unless content='mixed', in which case it's
       <choice minOccurs='0' maxOccurs='*'> -->

<!-- If anyAttribute appears in one or more referenced attributeGroups
     and/or explicitly, the intersection of the permissions is used -->

<!-- A text-only type with no attributes differs from a datatype with
     the same base qualified the same way in regard to the impact on
     attributes of anyAttribute -->

<!-- an element is declared by either:
 a name and a type (either nested or referenced via the type attribute)
or:
 a ref to an existing element declaration -->

<!ELEMENT %element; ((%annotation;)?, (%complexType;| %simpleType;)?,
                     (%unique; | %key; | %keyref;)*)>
<!-- type or datatype only if no type|ref attribute -->
<!-- ref not allowed at top level -->
<!ATTLIST %element;
            name        %NCName;               #IMPLIED
            id          ID                     #IMPLIED
            ref         %QName;                #IMPLIED
            type        %QName;                #IMPLIED
            minOccurs   %non-negative-integer; '1'
            maxOccurs   CDATA                  #IMPLIED
            nullable    %boolean;              'false'
            equivClass  %QName;                #IMPLIED
            abstract    %boolean;              'false'
            final       %complexDerivationSet; ''
            block       %blockSet;             ''
            default     CDATA                  #IMPLIED
            fixed       CDATA                  #IMPLIED
            %elementAttrs;>
<!-- type and ref are mutually exclusive.
     name and ref are mutually exculsive, one is required -->
<!-- In the absence of type AND ref, type defaults to type of
     equivClass, if any, else the ur-type, i.e. unconstrained -->
<!-- maxOccurs defaults to 1 or minOccurs, whichever is greater -->
<!-- default and fixed are mutually exclusive -->

<!ELEMENT %group; (%mgs;)?>
<!ATTLIST %group; 
          name        %NCName;               #IMPLIED
          ref         %QName;                #IMPLIED
          minOccurs   %non-negative-integer; '1'
          maxOccurs   CDATA                  #IMPLIED
          id          ID                     #IMPLIED
          %groupAttrs;>

<!ELEMENT %all; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)>
<!ATTLIST %all;
          minOccurs   %non-negative-integer; '1'
          maxOccurs   CDATA                  #IMPLIED
          id          ID                     #IMPLIED
          %allAttrs;>

<!ELEMENT %choice; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)>
<!ATTLIST %choice;
          minOccurs   %non-negative-integer; '1'
          maxOccurs   CDATA                  #IMPLIED
          id          ID                     #IMPLIED
          %choiceAttrs;>

<!ELEMENT %sequence; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)>
<!ATTLIST %sequence;
          minOccurs   %non-negative-integer; '1'
          maxOccurs   CDATA                  #IMPLIED
          id          ID                     #IMPLIED
          %sequenceAttrs;>

<!-- an anonymous grouping in a model, or
     a top-level named group definition, or a reference to same -->

<!-- Note that if order is 'all', group is not allowed inside.
     If order is 'all' THIS group must be alone (or referenced alone) at
     the top level of a content model -->
<!-- If order is 'all', minOccurs==maxOccurs==1 on element/any inside -->
<!-- Should allow minOccurs=0 inside order='all' . . . -->

<!ELEMENT %any; EMPTY>
<!ATTLIST %any;
            namespace       CDATA                  '##any'
            processContents (skip|lax|strict)      'strict'
            minOccurs       %non-negative-integer; '1'
            maxOccurs       CDATA                  #IMPLIED
            %anyAttrs;>

<!-- namespace is interpreted as follows:
                  ##any      - - any non-conflicting WFXML at all

                  ##other    - - any non-conflicting WFXML from namespace other
                                  than targetNamespace

                  ##local    - - any unqualified non-conflicting WFXML/attribute
                  one or     - - any non-conflicting WFXML from
                  more URI        the listed namespaces
                  references

                  ##targetNamespace may appear in the above list, with the
                   obvious meaning -->

<!ELEMENT %anyAttribute; EMPTY>
<!ATTLIST %anyAttribute;
            namespace    CDATA   '##any'
            %anyAttributeAttrs;>
<!-- namespace is interpreted as for 'any' above -->


<!-- for use inside basetype to copy down corresponding content
     model particle from the basetype's content model -->
<!ELEMENT %sic; EMPTY>

<!ELEMENT %attribute; ((%annotation;)?, (%simpleType;)?)>
<!ATTLIST %attribute;
          name      %NCName;      #REQUIRED
          type      %QName;       #IMPLIED
          maxOccurs (0|1)         '1'
          minOccurs (0|1)         '0'
          default   CDATA         #IMPLIED
          fixed     CDATA         #IMPLIED
          %attributeAttrs;>
<!-- default and fixed are mutually exclusive -->
<!-- type attr and datatype content are mutually exclusive -->

<!-- an attributeGroup is a named collection of attribute decls, or a
     reference thereto -->
<!ELEMENT %attributeGroup; ((%annotation;)?,
                       (%attribute; | %attributeGroup;)*,
                       (%anyAttribute;)?) >
<!ATTLIST %attributeGroup;
                 name       %NCName;       #IMPLIED
                 id         ID             #IMPLIED
                 ref        %QName;        #IMPLIED
                 %attributeGroupAttrs;>

<!-- ref iff no content, no name.  ref iff not top level -->

<!-- better reference mechanisms -->
<!ELEMENT %unique; ((%annotation;)?, %selector;, (%field;)+)>
<!ATTLIST %unique; name     %NCName;       #REQUIRED
                   id       ID             #IMPLIED
                   %uniqueAttrs;>

<!ELEMENT %key;    ((%annotation;)?, %selector;, (%field;)+)>
<!ATTLIST %key;    name     %NCName;       #REQUIRED
                   id       ID             #IMPLIED
                   %keyAttrs;>

<!ELEMENT %keyref; ((%annotation;)?, %selector;, (%field;)+)>
<!ATTLIST %keyref;
                   name     %NCName;       #REQUIRED
                   id       ID             #IMPLIED
                   refer    %QName;        #REQUIRED
                   %keyrefAttrs;>

<!ELEMENT %selector; (#PCDATA)>
<!ELEMENT %field; (#PCDATA)>

<!-- Schema combination mechanisms -->
<!ELEMENT %include; EMPTY>
<!ATTLIST %include; schemaLocation %URIref; #REQUIRED
                    %includeAttrs;>

<!ELEMENT %import; EMPTY>
<!ATTLIST %import; namespace      %URIref; #REQUIRED
                   schemaLocation %URIref; #IMPLIED
                   %importAttrs;>

<!ELEMENT %notation; EMPTY>
<!ATTLIST %notation;
                 name        %NCName;    #REQUIRED
                 id          ID          #IMPLIED
                 public      CDATA       #REQUIRED
                 system      %URIref;    #IMPLIED
                 %notationAttrs;>

<!NOTATION XMLSchemaStructures PUBLIC 'structures'
           '&XSP1.URI;.xsd' >
<!NOTATION XML PUBLIC 'REC-xml-1998-0210'
               'http://www.w3.org/TR/1998/REC-xml-19980210' >

C Glossary (normative) *

Ed. Note: The Glossary has barely been started. An XSL macro will be used to collect definitions from throughout the spec and gather them here for easy reference.

abstract syntax
[Definition:]  theabstract syntax of the XML Schema Definition Language is ...
aggregate datatype
[Definition:]  an aggregate datatype is
type
[Definition:]  an type is
type reference
[Definition:]  an type reference is
'all' content model group
[Definition:]  the 'all' content model group is
'any' content
[Definition:]  the 'any' content specification ...
atomic datatype
[Definition:]  an atomic datatype is
attribute
[Definition:]  an attribute is
attribute group
[Definition:]  an attribute group is
'choice' content model group
[Definition:]  the 'choice' content model group is
composition
[Definition:]  composition is
concrete syntax
[Definition:]  the concrete syntax is
constraint
[Definition:]  a constraint is
content
[Definition:]  content is
context
[Definition:]  a context is
datatype
[Definition:]  an datatype is
datatype reference
[Definition:]  an datatype reference is
default value
[Definition:]  a default value is
document
[Definition:]  a document is
element
[Definition:]  an element is
element content
[Definition:]  element content is
element reference
[Definition:]  an element reference is
'empty' content
[Definition:]  the 'empty' content specification ...
export
[Definition:]  to export is
export control
[Definition:]  an export control
external entity
[Definition:]  an external entity is
facet
[Definition:]  a facet is
fixed value
[Definition:]  a fixed value
fragment
[Definition:]  a fragment is
import
[Definition:]  to import is
include
[Definition:]  to include is
information set
[Definition:]  an information set is
instance
[Definition:]  an instance is
markup
[Definition:]  markup is
'mixed' content
[Definition:]  the 'mixed' content specification ...
model
[Definition:]  a model is
model group
[Definition:]  a model group is
model group reference
[Definition:]  a model group reference is
null
[Definition:]  A distinguished empty value for properties of schema components in the abstract schema data model.
RUE
[Definition:]  RUE is short for reference to undefined entity information item as defined in [XML-Infoset]
NCName
[Definition:]  an NCName is a name with no colon, as defined in [XML-Namespaces]. Appears in all the definition and declaration productions of this specification.
QName
[Definition:]  a QName is a name with an optional namespace qualification, as defined in [XML-Namespaces]. When used in connection with the XML representation of schema components in this specification, this refers to the simple type QName as defined in [XML Schemas: Datatypes].
namespace
[Definition:]  a namespace is
notation
[Definition:]  a notation is
object model
[Definition:]  an object model is
occurrence
[Definition:]  occurrence is
parameter entity
[Definition:]  a parameter entity is
preamble
[Definition:]  a preamble is
presence
[Definition:]  presence is
refinement
[Definition:]  refinement is
document root
[Definition:]  the document root is ...
scope
[Definition:]  scope is
'sequence' content model group
[Definition:]  the 'sequence' content model group is
structure
[Definition:]  structure is
symbol space
[Definition:]  a symbol space is
text entity
[Definition:]  a parsed entity is
unparsed entity
[Definition:]  an unparsed entity is
validation
[Definition:]  validation is
vocabulary
[Definition:]  a vocabulary is
well-formedness
[Definition:]  well-formedness is

D References (normative) *

Cambridge Communiqué
The Cambridge Communiqué, Ralph Swick and Henry S. Thompson, editors, 7 October 1999. See http://www.w3.org/TR/schema-arch
DCD
Document Content Description for XML (DCD), Tim Bray et al. W3C, 10 August 1998. See http://www.w3.org/TR/NOTE-dcd
DDML
Document Definition Markup Language. See http://www.w3.org/TR/NOTE-ddml
XML Schema: Exposition
XML Schema: Exposition, David C. Fallside, ed. See http://www.w3.org/TR/2000/WD-xmlschema-0-20000225/
HTML-4
HTML 4.0 Specification, Dave Raggett et al. W3C, 1998. See http://www.w3.org/TR/REC-html40/
ISO-11404
ISO 11404 -- Information Technology -- Programming Languages, their environments and system software interfaces -- Language-independent datatypes, ISO/IEC 11404:1996(E).
RFC-1808
RFC 1808,Relative Uniform Resource Locators. Internet Engineering Task Force. See http://www.ietf.org/rfc/rfc1808.txt
SOX
Schema for Object-oriented XML, Matt Fuchs, et al. W3C, 1998. See http://www.w3.org/Submission/1998/15/
SOX-1.1
Schema for Object-oriented XML, Version 1.1, Matt Fuchs, et al. W3C, 1999. See ???
URI
Uniform Resource Identifiers (URI): Generic Syntax and Semantics. See http://www.ics.uci.edu/~fielding/url/draft-fielding-uri-syntax-01.txt
URL
RFC 1738,Uniform Resource Locators (URL). Internet Engineering Task Force. See http://www.ietf.org/rfc/rfc1738.txt
URN
RFC 2141,URN Syntax. Internet Engineering Task Force. See http://www.ietf.org/rfc/rfc2141.txt
WAI-PAGEAUTH
WAI Accessibility Guidelines: Page Authoring, Gregg Vanderheiden et al. W3C, 14-Apr-1998. See http://www.w3.org/TR/WAI-WEBCONTENT/
WEBARCH-EXTLANG
Web Architecture: Extensible Languages, Tim Berners-Lee and Dan Connolly. W3C, 10 Feb 1998. See http://www.w3.org/TR/NOTE-webarch-extlang
WEBSGML
Proposed TC for WebSGML Adaptations for SGML, C. F. Goldfarb, ed., 14 June 1997. See http://www.sgmlsource.com/8879rev/n1929.htm
XML Schemas: Datatypes
XML Schema Part 2: Datatypes, Paul V. Biron and Ashok Malhotra, eds. See http://www.w3.org/TR/2000/WD-xmlschema-2-20000225/datatypes.html
XML Schema Requirements
XML Schema Requirements , Ashok Malhotra and Murray Maloney, ed., W3C, 15 February 1999. See http://www.w3.org/TR/NOTE-xml-schema-req
XDR
XML-Data Reduced, Frankston, Charles, and Henry S. Thompson, ed. See http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm
XLink
XML Linking Language (XLink), Eve Maler and Steve DeRose, W3C, 3 March 1998. See http://www.w3.org/TR/WD-xlink
XML
Extensible Markup Language (XML) 1.0, Tim Bray, et al. W3C, 10 February 1998. See http://www.w3.org/TR/REC-xml
XSLT
Extensible Stylesheet Language Transformations, James Clark, W3C, 21 April 1999. See http://www.w3.org/TR/1999/WD-xslt-19990421
XML-Data
XML-Data, Andrew Layman, et al. W3C, 05 January 1998. See http://www.w3.org/TR/1998/NOTE-XML-data-0105/
XML-Infoset
XML Information Set (public WD), David Megginson et al., W3C, 1999. See http://www.w3.org/TR/xml-infoset
XML-Namespaces
Namespaces in XML, Tim Bray et al., W3C, 1998. See http://www.w3.org/TR/WD-xml-names/
XPointer
XML Pointer Language (XPointer), Eve Maler and Steve DeRose, W3C, 3 March 1998. See http://www.w3.org/TR/xptr
XPath
XML Path Language, James Clark and Steve DeRose, editors, 16 November 1999. See http://www.w3.org/TR/xpath
XSchema
XSchema Specification, Simon St. Laurent, Ronald Bourret, John Cowan, et al., Version 1.0, Draft, 18 October 1998. See http://www.simonstl.com/xschema/spec/xscspecv4.htm For more general information, consult http://purl.oclc.org/NET/xschema

E Acknowledgements (non-normative)

The following have contributed material to this draft:

The editors acknowledge the members of the XML Schema Working Group, the members of other W3C Working Groups, and industry experts in other forums who have contributed directly or indirectly to the process or content of creating this document. The Working Group is particularly grateful to Lotus Development Corp. and IBM for providing teleconferencing facilities.

The current members of the XML Schema Working Group are:

David Beech, Oracle Corp.; Paul V. Biron, Health Level Seven; Allen Brown, Microsoft; Greg Bumgardner, Rogue Wave Software; Lee Buck, Extensibility; Dean Burson, Lotus Development Corporation; Charles E. Campbell, Informix; Peter Chen, Bootstrap Alliance and LSU; David Cleary, Progress Software; Dan Connolly, W3C (staff contact); Andrew Eisenberg, Progress Software; Rob Ellman, Calico Commerce; David Ezell, Hewlett Packard Company; David Fallside, IBM; Matthew Fuchs, Commerce One; Paul Grosso, ArborText, Inc; Dave Hollander, CommerceNet (co-chair); Mary Holstege, Calico Commerce; Jane Hunter, Distributed Systems Technology Centre (DSTC Pty Ltd); Renato Iannella, Distributed Systems Technology Centre (DSTC Pty Ltd); Rick Jelliffe, Academia Sinica; Dianne Kennedy, Graphic Communications Association; Setrag Khoshafian, Technology Deployment International (TDI); Setrag Khoshafian, Technology Deployment International (TDI); Ara Kullukian, Technology Deployment International (TDI); Andrew Layman, Microsoft; Dmitry Lenkov, Hewlett Packard Company; Eve Maler, Sun Microsystems; Ashok Malhotra, IBM; Murray Maloney, Commerce One; John McCarthy, Lawrence Berkeley National Laboratory; Noah Mendelsohn, Lotus Development Corporation; Don Mullen, Extensibility; Murata Makoto, Xerox; Frank Olken, Lawrence Berkeley National Laboratory; Dave Peterson, Graphic Communications Association; Mark Reinhold, Sun Microsystems; Shriram Revankar, Xerox; Jonathan Robie, Software AG; Lew Shannon, NCR; C. M. Sperberg-McQueen, W3C (co-chair); Henry S. Thompson, University of Edinburgh; Matt Timmermans, Microstar; Jim Trezzo, Oracle Corp.; Steph Tryphonas, Microstar; Mark Tucker, Health Level Seven; Asir S. Vedamuthu, webMethods, Inc; Priscilla Walmsley, XMLSolutions; Norm Walsh, ArborText, Inc; Aki Yoshida, SAP AG

The XML Schema Working Group has benefited in its work from the participation and contributions of a number of people not currently members of the Working Group, including in particular those named below. Affiliations given are those current at the time of their work with the WG.

Paula Angerstein, Vignette Corporation; Gabe Beged-Dov, Rogue Wave Software; Dean Burson, Lotus Development Corporation; George Feinberg, Object Design; Charles Frankston, Microsoft; Ernesto Guerrieri, Inso; Michael Hyman, Microsoft; Janet Koenig, Sun Microsystems; Chris Olds, Wall Data; William Shea, Merrill Lynch; Ralph Swick, W3C; Tony Stewart, Rivcom

F Tabulation of changes


$Log: structures.html,v $
Revision 1.3  2017/10/02 10:23:19  denis
add fixup.js to old specs

Revision 1.2  2000/02/25 17:46:33  connolly
publication fixes by connolly

Revision 1.1  2000/02/25 16:49:14  connolly
ht Feb 24 21:35

Revision 1.46.1.48.2.3  2000/02/25 02:14:44  ht
more link fixes

Revision 1.46.1.48.2.2  2000/02/25 02:07:27  ht
link fixes

Revision 1.46.1.48.2.1  2000/02/25 01:12:09  ht
Merge in pre-publication edits

Revision 1.46.1.48  2000/02/24 23:03:55  ht
fixed examples brutally
spell check
rushed through stubs for all propmaps

Revision 1.46.1.47  2000/02/24 21:42:27  ht
exact->value, work on groups

Revision 1.46.1.46  2000/02/24 12:28:05  ht
noah's most recent additions
work on attributes, make content type a particle, not a group (oops)

Revision 1.46.1.45  2000/02/23 18:08:54  ht
ur-type consistency
more on complex type in c6
stubs for all props in c6
derivationChoice/Set/exactSet fussing

Revision 1.46.1.44  2000/02/23 10:06:31  ht
integrate work from Noah on ur-type cleanup, ed note removal

Revision 1.46.1.43  2000/02/22 23:10:27  ht
try identity-c for reference-c

Revision 1.46.1.42  2000/02/22 17:51:30  ht
Handle some ednotes, remove some stale in-doc issues
turn the rhetoric for chapter 4 around, so elements in repr are on
top, elaborate the reprdef content model accordingly
Finish off (?) <element> and associated src and cos

Revision 1.46.1.41  2000/02/21 17:45:45  ht
add latest from Noah,
more structure in <reprdef> to allow one elt->many components

Revision 1.46.1.40  2000/02/18 19:05:17  ht
minor cleanup for Plenary notice,
start on <element> element,
rename source to base

Revision 1.46.1.39  2000/02/18 12:27:22  ht
work on XML repr of attributes, QName stuff
incorporate Eve's and Noah's edits of yesterday

Revision 1.46.1.38  2000/02/17 10:10:07  ht
integrated changes from eve,
added names to annotations property (oops)

Revision 1.46.1.37  2000/02/16 22:10:45  ht
add annotations to every component,
start seriously on Chapter 4

Revision 1.46.1.36  2000/02/16 13:24:53  ht
integrate (with minor mods) updates from eve,
full (but complex) spec. for keyref validation

Revision 1.46.1.35  2000/02/15 14:12:02  ht
merged in edits to c.1 from eve

Revision 1.46.1.34  2000/02/14 17:59:37  ht
some ref-constr work, cleaned up some ednotes

Revision 1.46.1.33.2.1  2000/02/15 13:44:11  ht
noah's contributions of 14 Feb

Revision 1.46.1.33  2000/02/14 14:51:12  ht
working on particles vs. equiv classes

Revision 1.46.1.32  2000/02/14 12:07:05  bu
cvcs for model group, particle and wildcard

Revision 1.46.1.31  2000/02/14 08:46:52  ht
more from Noah

Revision 1.46.1.30  2000/02/12 18:10:47  ht
noahs next edits integrated, responded to

Revision 1.46.1.29  2000/02/12 16:53:52  ht
got defaults sorted out for element decls

Revision 1.46.1.28  2000/02/11 12:56:00  aqw
Integrate from Noah, add comments, value constraint for complex types, clarify language about LDG

Revision 1.46.1.27  2000/02/11 11:03:06  ht
Noah working on element decl

Revision 1.46.1.26  2000/02/10 15:00:50  aqw
another pass over 3.2, finished I think

Revision 1.46.1.25  2000/02/10 11:11:47  ht
appropriate noah's additions

Revision 1.46.1.23  2000/02/09 16:32:06  aqw
update terminology per some f2f votes, begin working through chapter 3, add null processing to element decl

Revision 1.46.1.22  2000/02/08 23:20:24  ht
fix bogus eg embedding

Revision 1.46.1.21  2000/01/27 19:09:32  aqw
a bit more cleanup of composition chapter, everybody has at least stub
properties, got field and selectors in barely, lots more <stale>
wrapping.

Revision 1.46.1.20  2000/01/27 16:00:13  aqw
began to mark non-restructured sections, some cleanup of composition

Revision 1.46.1.19  2000/01/27 10:57:14  aqw
Michael's and Noah's general editorial suggestions
Try reference-constraint for key, unique, keyref

Revision 1.46.1.18  2000/01/26 23:18:30  aqw
example reprdef, full set of reprdef stubs

Revision 1.46.1.17  2000/01/26 13:12:16  aqw
Another minor reordering in chapter 2
Brief expositions added to each subsection in chapter 2
QName reference validation stuff

Revision 1.46.1.16  2000/01/25 22:29:38  bu
final cross-references added to Chapter 3 stubs, some sics

Revision 1.46.1.15  2000/01/25 17:45:11  aqw
some work on references/QNames

Revision 1.46.1.14  2000/01/25 16:13:50  aqw
restructuring for parallelism, with lots of stubs, now complete?

Revision 1.46.1.13  2000/01/24 18:06:22  aqw
more re-ordering of chapter 3, preliminary cvcs for attr and elt decls

Revision 1.46.1.12  2000/01/22 11:11:06  aqw
detail work on complex type def details

Revision 1.46.1.11  2000/01/20 17:40:01  aqw
working seriously on complex type defn details

Revision 1.46.1.10  2000/01/20 11:25:29  aqw
move simple type to end of each section
start work on complex type defn for real in Chap. 3
introduce <eltref>.

Revision 1.46.1.9  2000/01/19 17:10:18  aqw
remove all remaining scraps == abstract syntax
cosmetic changes in chap.1
begin adding more details in chap.3

Revision 1.46.1.8  2000/01/19 15:52:07  aqw
restructure compdef and reprdef for better control

Revision 1.46.1.7  2000/01/18 17:59:00  aqw
moving towards auto-generated paradigms

Revision 1.46.1.6  2000/01/15 18:13:20  aqw
revised approach to reprdef

Revision 1.46.1.5  2000/01/15 12:56:03  aqw
new chaps 2 and 3 complete in outline
Starting on 4.[attr grp defn] as prototype for XML repr spec

Revision 1.46.1.4  2000/01/12 23:02:17  ht
Moved component type details from Chap 2 to Chap 3

Revision 1.46.1.3  2000/01/12 21:18:22  ht
replaced [prop] with <propdef>, <propref> and <xpropref>

Revision 1.46.1.2  2000/01/12 18:04:37  aqw
Finished drastic pruning and rewrite of Chapter 2
Now propose to move all the formal definitions to the new Chapter 3:
Schema Components, with sections called e.g. Attribute Declarations:
details or some such

Revision 1.46.1.1  2000/01/12 12:44:56  aqw
begin major reorg: component exposition started

Revision 1.46  2000/01/10 11:57:56  aqw
Fold in non-publ-related changes in 19991217 publication version (1.45.1.6)
Experiment with moving major examples out-of-line

Revision 1.45.1.6  1999/12/17 16:14:53  ht
one more link

Revision 1.45.1.5  1999/12/17 15:35:47  ht
reorder prevloc

Revision 1.45.1.4  1999/12/17 14:50:25  ht
link fixes

Revision 1.45.1.3  1999/12/17 14:46:51  ht
additional status prose

Revision 1.45.1.2  1999/12/17 13:33:11  ht
PWD status prose and link fixes

Revision 1.45.1.1  1999/12/17 12:26:37  ht
towards PWD

Revision 1.45.1.6  1999/12/17 16:14:53  ht
one more link

Revision 1.45.1.5  1999/12/17 15:35:47  ht
reorder prevloc

Revision 1.45.1.4  1999/12/17 14:50:25  ht
link fixes

Revision 1.45.1.3  1999/12/17 14:46:51  ht
additional status prose

Revision 1.45.1.2  1999/12/17 13:33:11  ht
PWD status prose and link fixes

Revision 1.45.1.1  1999/12/17 12:26:37  ht
towards PWD

Revision 1.45  1999/12/17 12:06:05  ht
eacute

Revision 1.44  1999/12/17 11:51:45  ht
make all example quotes double
some changes merged from pre-Nov-publ branch (1.15.1...)

Revision 1.43  1999/12/17 10:59:16  ht
minor fix in schema wrt keys

Revision 1.42  1999/12/16 15:48:08  ht
fix some refs, incorporate up-to-date schema and DTD

Revision 1.41  1999/12/16 15:40:05  aqw
describe exact, final and abstract on elements

Revision 1.40  1999/12/16 09:44:11  aqw
minor editorial

Revision 1.39  1999/12/14 16:22:46  aqw
various QName fixes

Revision 1.38  1999/12/10 18:01:42  ht
remove * where status has changed

Revision 1.37  1999/12/10 16:14:10  aqw
renaming attrGroup, elemOnly, integrate DTD and schema

Revision 1.36  1999/12/10 16:08:05  aqw
more on BRM, add an wildcard ambiguity issue

Revision 1.35  1999/12/10 10:07:35  ht
merge in new-design branch

Revision 1.34  1999/12/10 09:38:42  ht
minor orphan changes

Revision 1.33  1999/12/08 20:06:52  aqw
added prose for BRM

Revision 1.32  1999/12/03 15:49:25  ht
fix status text

Revision 1.31  1999/12/03 14:54:16  aqw
ht version confusion

Revision 1.30  1999/12/03 14:48:41  aqw
Outline inclusion of BRM proposal
Implemented QName aspect of composition decision

Revision 1.29.1.6  1999/12/08 20:04:26  aqw
describe impact of exact for equiv classes, remove substitutabiliity section

Revision 1.29.1.5  1999/12/06 23:15:09  ht
add stars, no standalone

Revision 1.29.1.4  1999/12/06 22:50:02  aqw
add equiv classes, up-to-date DTD and schema

Revision 1.29.1.3  1999/12/03 19:37:27  ht
Fill in 3.6.3, controlling derivation, including mod agreed with Allen
wrt type tolerance.

Revision 1.29.1.2  1999/12/03 15:55:38  aqw
cleanup new proposal stuff for preliminary release

Revision 1.29.1.1  1999/12/02 22:55:36  aqw
begin serious work on integrating new type derivation proposal

Revision 1.29  1999/12/02 19:05:00  aqw
resolve ! issue in <any namespace='...'> in favour of ##
remove private exploratory hierarchy rewrite

Revision 1.28  1999/12/02 11:36:27  aqw
merge in DTD and schema for internal point release

Revision 1.27  1999/12/02 11:09:36  aqw
composition tf integrates, validates nearly ok

Revision 1.26  1999/12/01 15:43:23  aqw
integrating composition tf . . .

Revision 1.25  1999/11/22 14:14:59  aqw
integrate tentative type construction compromise

Revision 1.24  1999/11/12 17:00:41  ht
Incorporate minimal null support

Revision 1.23  1999/11/11 11:19:11  ht
add issues per 1999-11-04 telcon vote

Revision 1.22  1999/11/11 11:11:51  ht
include dtd and schema

Revision 1.21.1.1  1999/11/22 14:03:55  aqw
try out type construction compromise

Revision 1.21  1999/11/05 00:48:14  aqw
note about status vis a vis forthcoming issues from minutes

Revision 1.20  1999/11/04 23:46:57  aqw
remove element classes per WG vote

Revision 1.19  1999/11/03 21:39:47  aqw
fix editors list and acks
typoes spotted by DBeech

Revision 1.18  1999/11/03 15:49:26  aqw
Implement chair's instructions wrt WG poll closed 1999-10-30:
 * re-integrate named model groups
 * change details of implicit openness
 * remove entities, not notations

Revision 1.17  1999/11/02 23:37:35  aqw
merge refinement proposal into mainline preparatory to implementing poll results


Revision 1.16  1999/11/02 21:32:25  aqw
remove entity definitions and related material (e.g. notations)

Revision 1.15  1999/10/27 13:28:58  ht
Fix some (all?) syntax paradigms, examples
Include bug-fixed .xsd and .dtd

Revision 1.14  1999/10/27 10:48:01  ht
Incorporate up-to-date schema and DTD, completing concrete syntax changes
Parameterise paths/dates to facilitate release process

Revision 1.13.1.15  1999/10/26 16:23:30  ht
a bit more on validity

Revision 1.13.1.14  1999/10/25 14:37:31  ht
Begin to try to fill in validity section on basis of
schema-valid(EII,type,schemaSet) minimalist approach

Revision 1.13.1.13  1999/10/19 18:42:13  ht
added xsd:type to text, changed status

Revision 1.13.1.12  1999/10/18 19:46:12  aqw
Added concrete syntax, prose and examples to 3.6, new section on the
hierarchy and restrictions

Revision 1.13.1.11  1999/10/18 15:28:16  aqw
Included lots in 3.5 and 3.6, editting it in to shape

Revision 1.13.1.10  1999/10/18 13:55:23  aqw
correct and corresponding DTD and Schema included
text from new design included in 3.5 and 3.6 for editting

Revision 1.13.1.9  1999/10/18 11:39:01  aqw
light pass over section 2, cleaning up 'type' terminology
minor fixups in 3.4

Revision 1.13.1.8  1999/10/17 22:05:19  aqw
first pass through 3.4 complete

Revision 1.13.1.7  1999/10/16 22:12:03  aqw
element classes

Revision 1.13.1.6  1999/10/16 19:02:51  aqw
attribute finished, also attrGroup

Revision 1.13.1.5  1999/10/16 17:53:28  aqw
finished (?) with complex types, on to attributes

Revision 1.13.1.4  1999/10/16 11:52:07  aqw
still working on complex type

Revision 1.13.1.3  1999/10/15 16:38:31  aqw
more work on 'type'

Revision 1.13.1.1  1999/10/15 11:46:18  ht
on the way to matching new refinement proposal

Revision 1.13  1999/10/09 10:49:40  ht
correct headline date

Revision 1.12  1999/10/05 09:56:19  ht
Preliminary implementation of A3 and A7 (ampConnector and richerMixed)
votes.  Moving towards a parallel syntax for elementDecl/Ref and
groupDefn/Ref.

Concrete syntax paradigms, examples, DTD and Schema NOT up-to-date

Revision 1.11  1999/09/27 16:31:07  ht
merge simple back to main branch

Revision 1.10.2.38  1999/09/27 16:29:02  ht
return to xmlschema-current as base

Revision 1.10.2.37  1999/09/24 16:40:22  ht
add comments archive pointer

Revision 1.10.2.36  1999/09/24 16:38:23  ht
link housekeeping, move TF reports bibliography to separate appendix

Revision 1.10.2.35  1999/09/24 13:44:27  ht
final (?) housekeeping before publication

Revision 1.10.2.34  1999/09/23 18:48:51  ht
changes to front matter in preparation for public WD
ponter to Simple TF included

Revision 1.10.2.33  1999/09/23 13:32:15  ht
up-to-date pointer to refinement TF report

Revision 1.10.2.32  1999/09/23 13:00:22  ht
typo in db entity

Revision 1.10.2.31  1999/09/23 12:59:04  ht
per suggestions from Ashok, some rewording of summary of Composition
TF, added issue regarding priority of instance->schema alternatives

Revision 1.10.2.30  1999/09/22 14:02:35  ht
typo in correction to 4.1

Revision 1.10.2.29  1999/09/22 13:58:39  ht
edits implementing Noah's comments

Revision 1.10.2.28  1999/09/22 08:07:07  ht
add verbatim change log at end
----------------------------
revision 1.10.2.27
date: 1999/09/21 16:26:11;  author: ht;  state: Exp;  lines: +4 -4
added Id: to title for now
----------------------------
revision 1.10.2.26
date: 1999/09/21 16:06:08;  author: ht;  state: Exp;  lines: +42 -244
replaced composition tf report with a summary and a pointer
----------------------------
revision 1.10.2.25
date: 1999/09/21 14:11:50;  author: aqw;  state: Exp;  lines: +495 -111
some dates, up-to-date DTD and Schema for schemas
----------------------------
revision 1.10.2.24
date: 1999/09/21 10:50:37;  author: ht;  state: Exp;  lines: +18 -3
supply missing content model for 'attribute' in concrete syntax
paradigm
----------------------------
revision 1.10.2.23
date: 1999/09/21 10:37:51;  author: aqw;  state: Exp;  lines: +21 -20
define/declare consistency pass
----------------------------
revision 1.10.2.22
date: 1999/09/20 13:08:36;  author: aqw;  state: Exp;  lines: +47 -49
track datatype content model changes,
minor wording
----------------------------
revision 1.10.2.21
date: 1999/09/16 14:55:17;  author: ht;  state: Exp;  lines: +136 -14
header disclaimer, graveyards rescued to discharge references
----------------------------
revision 1.10.2.20
date: 1999/09/16 14:25:01;  author: aqw;  state: Exp;  lines: +274 -1541
rip out all of 3.5, all of 4, install 'Draft Proposal' in 4
----------------------------
revision 1.10.2.19
date: 1999/09/16 12:08:59;  author: aqw;  state: Exp;  lines: +107 -143
Clean up import/include/export, references in particular
Add archetypeRef to content models, minimally
New example of datatype+attr
----------------------------
revision 1.10.2.18
date: 1999/09/15 22:06:29;  author: aqw;  state: Exp;  lines: +26 -3
Two clarifications following discussion with Andrew
1) what it would take to remove the two symbol spaces problem
2) How <archetype> allows either datatypeRef or contentType
----------------------------
revision 1.10.2.17
date: 1999/09/15 20:30:49;  author: aqw;  state: Exp;  lines: +114 -105
change date, incorporate edited dtd
----------------------------
revision 1.10.2.16
date: 1999/09/15 19:52:39;  author: aqw;  state: Exp;  lines: +90 -76
Encorporate/respond to Eve Maler's suggested edits
----------------------------
revision 1.10.2.15
date: 1999/09/13 16:14:12;  author: aqw;  state: Exp;  lines: +306 -335
Finish consistency pass through 3.4
Brutal 'element type' -> element
----------------------------
revision 1.10.2.14
date: 1999/09/09 14:22:29;  author: aqw;  state: Exp;  lines: +53 -56
cleanup pass, down to 3.3
----------------------------
revision 1.10.2.13
date: 1999/09/08 18:23:47;  author: ht;  state: Exp;  lines: +41 -41
more type back to archetype
----------------------------
revision 1.10.2.12
date: 1999/09/08 18:03:06;  author: aqw;  state: Exp;  lines: +214 -216
put archetype back in, imperfectly, I expect
----------------------------
revision 1.10.2.11
date: 1999/09/07 21:50:36;  author: bu;  state: Exp;  lines: +124 -63
fix paradigm contexts, extend example, consolidate example in appendix
----------------------------
revision 1.10.2.10
date: 1999/09/07 16:54:39;  author: aqw;  state: Exp;  lines: +514 -521
syntax paradigms now properly distributed, I think
----------------------------
revision 1.10.2.9
date: 1999/09/07 15:53:06;  author: ht;  state: Exp;  lines: +5 -8
fixed minor validity errors
----------------------------
revision 1.10.2.8
date: 1999/09/07 15:31:58;  author: aqw;  state: Exp;  lines: +288 -285
working on integrating syntax paradigms
----------------------------
revision 1.10.2.7
date: 1999/09/07 09:44:57;  author: aqw;  state: Exp;  lines: +630 -33
added ALL concrete syntax boxes at once
----------------------------
revision 1.10.2.6
date: 1999/09/06 14:55:04;  author: ht;  state: Exp;  lines: +35 -2
added one e: syntax exposition
----------------------------
revision 1.10.2.5
date: 1999/09/02 15:28:27;  author: ht;  state: Exp;  lines: +6 -6
fix URLs for self, a bit
----------------------------
revision 1.10.2.4
date: 1999/09/02 12:53:34;  author: aqw;  state: Exp;  lines: +108 -95
Added not-status-quo marks, changed e.g. String to string
----------------------------
revision 1.10.2.3
date: 1999/09/01 17:02:14;  author: aqw;  state: Exp;  lines: +587 -977
integration of 2.3 from simple
more renaming
----------------------------
revision 1.10.2.2
date: 1999/08/23 15:32:16;  author: aqw;  state: Exp;  lines: +730 -248
Modified simple integration to give preliminary consistency
----------------------------
revision 1.10.2.1
date: 1999/08/22 17:44:40;  author: aqw;  state: Exp;  lines: +317 -260
Textual integration of Simple update of 1999-08-13
----------------------------
revision 1.10
date: 1999/07/20 19:47:27;  author: ht;  state: Exp;  lines: +5 -5
branches:  1.10.2;
fixed dates, dangling reference
----------------------------
revision 1.9
date: 1999/07/19 09:31:26;  author: ht;  state: Exp;  lines: +34 -38
David Beech: updated definition of "Schema" following WG and IG email
discussion.  Changed "Schemata" to "Schemas" except where directly
quoted from Requirements doc.  Clarified in 2.5 that elements and
attributes have separate symbol spaces (public comment).  Fixed
assorted typos.
----------------------------
revision 1.8
date: 1999/06/23 10:00:31;  author: aqw;  state: Exp;  lines: +1 -1
fix Id:
----------------------------
revision 1.7
date: 1999/06/23 09:51:15;  author: aqw;  state: Exp;  lines: +28 -28
Restrict content model of 'all' in schema and dtd, change entities for
point releases
----------------------------
revision 1.6
date: 1999/06/23 09:10:01;  author: aqw;  state: Exp;  lines: +147 -187
pushed &amp; down to lowest level, fixed incoherent validity
definition in 6.2.3.7 to agree with the note which follows.  Wrapped
validation text from 3.4 in appropriately named div4's
----------------------------
revision 1.5
date: 1999/06/21 16:31:59;  author: aqw;  state: Exp;  lines: +569 -551
Really moved validity-oriented definitions to 6.3 (previous revision
was just housekeeping)
----------------------------
revision 1.4
date: 1999/06/21 16:25:21;  author: aqw;  state: Exp;  lines: +45 -36
moved validity-oriented definitions to 6.3
----------------------------
revision 1.3
date: 1999/06/21 12:25:21;  author: aqw;  state: Exp;  lines: +3540 -3650
Low-level: Normalise line ends, quotes
Editorial: Move all constraintnotes to new separate section
----------------------------
revision 1.2
date: 1999/05/27 14:13:54;  author: aqw;  state: Exp;  lines: +2 -2
fix stylesheet and dtd urls to local versions
----------------------------
revision 1.1
date: 1999/05/23 16:51:11;  author: ht;  state: Exp;
branches:  1.1.1;
Initial revision

G Open Issues

A tabulation of open issues flagged above follows:

dummy
nullRequiresEmpty
restrictConstrXPaths
islandValidConstraint
error-behavior