XML Schema Part 1: Structures

[This local archive copy is from the official and canonical URL, http://www.w3.org/1999/05/06-xmlschema-1/; please refer to the canonical source document if possible.]

Abstract

XML Schema: Structures is part one of a two part draft of the specification for the XML Schema definition language. This document proposes 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.)

1. Introduction

This structural part (XML Schema: Structures) of the XML Schema definition language is a distillation of eight months of work by the W3C XML Schema Working Group, including four weeks of intensive work by a group of five editors. This Working Draft draws heavily on the work of [DCD], [DDML], [SOX], [XDR] and [XML-Data]. Requirements for XML Schema: Structures can be found in [XML Schema Requirements].

Chapter 2 presents a Conceptual Framework for XML Schema: Structures, including an introduction to schema constraints, types, schema composition, and symbol spaces. The abstract and concrete syntax of XML Schema: Structures are introduced, along with other terminology used throughout the specification.

Chapter 3 Schema Definitions and Declarations reconstructs the core functionality of XML 1.0, plus a number of extensions, in line with our stated requirements [XML Schema Requirements]. This chapter discusses the declaration and use of datatypes, archetypes, element types, content models, attributes, attribute groups, model groups, refinement, entities and notations.

Chapter 4 presents Schema Composition and Namespaces, including the validation of namespace qualified instance documents, import, inclusion and export of declarations and definitions, schema paths, access to schemas, and related rules for schema-based validity.

Chapter 5 is a placeholder for Documenting schemas, which will eventually provide a standardized means for including documentation in the definition of a schema.

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

The normative addenda include a (normative) DTD for Schemas and a (normative) Schema for Schemas, which is an XML Schema schema for XML Schema: Structures, a Glossary (normative) and References (normative). Non-normative appendixes include a Sample Schema (non-normative) and acknowledgments [Grateful Acknowledgments (non-normative)].

1.1 Documentation Conventions

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

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

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

Sample Abstract Syntax Production

left ::= right1 right2

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

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

Issue (dummy): A recorded issue.

Ed. Note: Notes shared among the editorial team.

NOTE: General comments directed to all readers.

1.2 Purpose

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

The purpose of an XML Schema: Structures schema is to define and describe a class of XML documents by using these constructs to constrain and document the meaning, usage and relationships of their constituent parts: datatypes, elements and their content, attributes and their values, entities and their contents and notations. Schema constructs may also provide for the specification of implicit information such as default values. Schemas are intended to document their own meaning, usage, and function through a common documentation vocabulary.

Thus, XML Schema: Structures can be used to define, describe and catalogue XML vocabularies for classes of XML documents.

Any application that consumes well-formed XML can use the XML Schema: Structures formalism to express syntactic, structural and value constraints applicable to its document instances. The XML Schema: Structures formalism will allow a useful level of constraint checking to be described and validated for a wide spectrum of XML applications.

The language defined by this specification does not attempt to provide all the facilities that might be needed by any application. Some applications may require constraint capabilities not expressible in this language, and so may need to perform their own additional validations.

1.3 Relationship To Other Work

The definition of XML Schema: Structures is a part of the W3C XML Activity. It is in various ways related to other ongoing parts of that Activity and other W3C WGs

XML Datatype Language

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

Document Object Model

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

HTML

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

Internationalization Working Group

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

RDF Schema

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

WAI

XML Schema: Structures has a requirement to support accessibility.

XML Information Set

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

XML Schema: Structures defines its own Information Set Contributions.

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

XML Linking WG

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

XML Syntax

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

XSL WG

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

1.4 Terminology

The terminology used to describe XML Schema: Structures is defined in the body of this specification. The terms defined in the following list are used in building those definitions and in describing the actions of XML Schema: Structures processors:

[Definition: ] may: Conforming documents and processors are permitted to but need not behave as described.
[Definition: ] must: Conforming documents and processors are required to behave as described; otherwise they are in error.
[Definition: ] error: A violation of the rules of this specification; results are undefined. Conforming software may detect and report an error and may recover from it.
[Definition: ] fatal error: An error which a conforming processor must detect and report to the application.
[Definition: ] match: (Of strings or names:) Two strings or names being compared must be character for character the same.
[Definition: ] identical: (Of URIs or schemaNames:) identical, according to the rules for identity in [XML-Namespaces].

2. Conceptual Framework

This specification uses a number of terms that are common to many of the fields of endeavor that have influenced the development of XML Schema. Unfortunately, it is often the case that these terms do not have the same definitions in all of those fields. This section attempts to provide definitions of terms as they are used to describe the conceptual framework, and the remainder of the specification.

2.1 Kinds of XML Documents

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

[Definition: ] Instance: An XML document whose structure conforms to some schema. See Associating Instance Document Constructs with Corresponding Schemata for the means by which an instance identifies the schema(s) to which it conforms.
[Definition: ] Schema: A set of rules for constraining the structure and articulating the information set of XML documents.
[Definition: ] Schema Definition: An XML document that defines a schema. See Access to Schemata for the means by which schema definition documents are accessed during processing. The term "Schema Definition" may also be abbreviated to "schema" where no confusion is likely.

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

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

Documents that are not schema definitions;
Schema definitions applicable to documents that are not schema definitions;
The schema definition applicable to schema definitions.

Likewise, rules for schemas do apply to the schema definition for schema definitions, which is an instance of itself.

2.2 On schemas, constraints and contributions

The [XML] specification describes two kinds of constraints on XML documents: well-formedness and validity constraints. Informally, the well-formedness constraints are those imposed by the definition of XML itself (such as the rules for the use of the < and > characters and the rules for proper nesting of elements), while validity constraints are the further constraints on document structure provided by a particular DTD.

Three kinds of normative statements about the impact of XML Schema: Structures components on instances are distinguished in this specification:

[Definition: ] Constraint on Schemas: Constraints on the form and content of schemas themselves, above and beyond those expressed in (normative) Schema for Schemas;
[Definition: ] Schema-Validity Constraint: Constraints on the form of instances which they must satisfy to be schema-valid;
[Definition: ] Schema Information Set Contribution: Augmentations to the information sets of instances which follow as a consequence of schema-validation.

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

XML Schema: Structures not only reconstructs the DTD constraints of XML 1.0 using XML instance syntax, it also adds the ability to define new kinds of constraints. For example, although the author of an XML 1.0 DTD may declare an element type as containing character data, elements, or mixed content, there is no mechanism with which to constrain the contents of elements to only character data of a particular form, such as only integers in a specified range.

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

2.3 On 'types'

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

2.4 Schemas and their component parts

The next chapter Schema Definitions and Declarations sets out the XML Schema: Structures approach to schemas and formal definitions of their component parts. Here we informally summarize the key constructs used in defining schemas. An asterisk (*) in the 'Named?' column indicates that the name will appear in instances -- other names are for schema use only.

XML Schema: Structures Feature	Purpose	Named?
The Schema	A wrapper containing all the definitions and declarations comprising a schema document.	Yes
Datatype Definition	A type (content constraint), such as 'integer', that applies to character data in an instance document, whether it appears as an attribute value or the contents of an element. The mechanisms for defining datatypes are set out elsewhere, in XML Schemas: Datatypes.	Yes
Archetype Definition	A complete set of constraints for elements in instance documents, applying to both contents and attributes.	Yes
Element Type Declaration	An association between a name for an element and an archetype. An element type declaration for 'A' is comparable to a DTD declaration `<!ELEMENT A .....>`.	Yes* (local or global)
Attribute Declaration	An association between a a name for an attribute and a datatype, together with occurrence constraints such as 'required' or 'default'. The association is local to its surrounding archetype.	Yes* (local)
Content type	Either a datatype or a content model. A content type applies to the contents of elements in an instance document (but not their attribute values). It provides a unifying abstraction for the constraints which apply to the contents of elements, but introduces no additional features.	No
Element Content Model	A type (content constraint) that applies to the contents of elements in an instance document. Content models do not include attribute declarations.	No
Element-Only Content	Components for constructing content models which allow only element content. Includes facilities for grouping, sequencing, as well as for declaration of and reference to element types.	No (but see below)
Attribute Group Definition	An association between a name and a reusable collection of attribute declarations.	Yes
Named Model Group	Model groups are part of the content model building block abstraction, but are unnamed and cannot be referenced for reuse. A named model group is an association between a name and a model group, allowing for reuse.	Yes
Archetype Refinement	One archetype may be defined as refining one or more other archetypes, acquiring content type and/or attributes therefrom.	Yes
Schema Import	Extends the current schema with definitions and/or declarations from an external schema, retaining the association with the original schema.	No
Schema Inclusion	Integrates definitions and/or declarations from an external schema into the schema being defined, as if they had been defined locally.	No

2.5 Names and Symbol Spaces

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

If all such names were assigned from the same 'pool', then it would be impossible to have e.g. a datatype named 'integer' and an element type with the name 'integer' in the same schema. [Definition: ] Accordingly we introduce the idea of a symbol space (avoiding 'name space' to avoid confusion with 'Namespaces in XML' [XML-Namespaces]).

There is a single distinct symbol space within a given schema for each of the abstractions named above other than 'Attribute' and 'Element type': within a given symbol space, names are unique, but the same name may appear in more than one symbol space without conflict. In particular note that the same name can refer to both an archetype and an element type, without conflict or necessary relation between the two.

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

2.6 Abstract and Concrete Syntax

XML Schema: Structures is presented here primarily in the form of an [Definition: ] abstract syntax, which provides a formal specification of the information provided for each declaration and definition in the schema language. The abstract syntax is presented using a simplified BNF. Defined terms are to the left. Their components are to the right, with a small amount of meta-syntax: ()s for grouping, | to separate alternatives, ? for optionality, * and + for iteration. Terms in italics are primitives, not expanded here, either because they are defined elsewhere (e.g. URI, defined by [URI]) or because they can only be grounded once a concrete syntax is decided on (e.g. choice).

An abstract syntax production prefixed with a number in brackets (e.g. [3]) is normative; other abstract syntax is either for purposes of explanation, or is a duplicate (for convenience) of a normative definition to be found elsewhere.

The abstract syntax illustrates the expressive power of the language, and the relationships among its component parts. The abstract syntax can be used to evaluate the expressive power of XML Schema: Structures, but not its look and feel. In particular, please note that neither ordering within or between productions or choice of names is significant, and that any particular concrete syntax is not constrained by these.

The [Definition: ] concrete syntax of XML Schema: Structures, the exact element and attribute names used in a schema, are a key feature of its proposed design. The concrete syntax is the form in which the schema language is used by schema authors. Though its elements and attributes are often different from the terms of the abstract syntax bnf, the features and expressive power of the two are congruent. The concrete syntax profoundly affects the convenience and usability of the schema language.

We include a preliminary concrete syntax in this draft, via examples and in (normative) Schema for Schemas and (normative) DTD for Schemas. The emphasis in this version has been to stay quite close to the abstract syntax.

3. Schema Definitions and Declarations

The principal purpose of XML Schema: Structures is to provide a means for defining schemas that constrain the contents of instance documents and augment the information sets thereof.

3.1 The Schema

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

Schema top level

`[1]`	`schema`	`::=`	`preamble dds*`
`[2]`	`dds`	`::=`	`datatypeDefn \| archetypeDefn \| elementTypeDecl \| attrGroupDefn \| modelGroupDefn \| notationDecl \| entityDecl`
`[3]`	`preamble`	`::=`	`xmlSchemaRef schemaIdentity schemaVersion model export? import? include?`
`[4]`	`xmlSchemaRef`	`::=`	`URI`
`[5]`	`schemaIdentity`	`::=`	`URI`
`[6]`	`schemaVersion`	`::=`	`string-value`
`[7]`	`model`	`::=`	`open \| refinable \| closed`

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

Example

<!DOCTYPE schema 
          PUBLIC '-//W3C//DTD XML Schema Version 1.0//EN'
          SYSTEM 'http://www.w3.org/1999/05/06-xmlschema-1/structures.dtd' >

<schema name='file:/usr/schemas/xmlschema/mySchema.xsd' 
        version='M.n' 
        xmlns='http://www.w3.org/1999/05/06-xmlschema-1/structures.xsd'>

  ...

</schema>

Note that the abstract syntax xmlSchemaRef is realised via a default namespace declaration in the concrete syntax.

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

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

Summary of Definitions and Declarations

`datatypeDefn`	`::=`	`NCName datatypeSpec`
`archetypeDefn`	`::=`	`NCName archetypeSpec`
`elementTypeDecl`	`::=`	`NCName elementTypeSpec`
`modelGroupDefn`	`::=`	`NCName modelGroupSpec`
`attrGroupDefn`	`::=`	`NCName attrGroupSpec`
`entityDecl`	`::=`	`NCName entitySpec`
`notationDecl`	`::=`	`NCName notationSpec`

Example
The following illustrates the basic model for declaring all XML Schema: Structures components:
 <datatype name='myDatatype'>
  ...
 </datatype>

 <archetype name='myArchetype'>
  ...
 </archetype>

 <elementType name='myElementType'>
  ...
 </elementType>

 <attrGroup name='myAttrGroup'>
  ...
 </attrGroup>

 <modelGroup name='myModelGroup'>
  ...
 </modelGroup>

 <notation name='myNotation' ... />

 <textEntity name='myTextEntity'>
  ...
 </textEntity>

 <externalEntity name='myExternalEntity' ... />

 <unparsedEntity name='myUnparsedEntity' ... />

</schema>
When creating a new component, we declare that its name is associated with the specification for that component. Each new component definition creates a new entry in the symbol space for that kind of component.

Constraint on Schemas: Unique Definition
The same NCName must not appear in two definitions or declarations of the same type.

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

3.2 The Document and its Root

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

3.3 References to Schema Constructs

Uniform means are provided for reference to a broad variety of schema constructs, both within a single schema and to features imported (Schema Import) from external schemas. The name used to reference any component of XML Schema: Structures from within a schema consists of an NCName and an optional schemaRef, a reference to an external schema definition. In a few cases, some qualification may be added to a reference: this is made clear as the individual reference forms are introduced below.

Example: Component Names and References

`[8]`	`schemaRef`	`::=`	`(schemaAbbrev \| schemaName)`
`[9]`	`schemaAbbrev`	`::=`	`NCName`
`[10]`	`schemaName`	`::=`	`URI`
	`datatypeRef`	`::=`	`datatypeName datatypeQual`
	`datatypeName`	`::=`	`NCName schemaRef?`
	`archetypeRef`	`::=`	`archetypeName`
	`archetypeName`	`::=`	`NCName schemaRef?`
	`elementTypeRef`	`::=`	`elementTypeName`
	`elementTypeName`	`::=`	`NCName schemaRef?`
	`attrGroupRef`	`::=`	`attrGroupName attrGroupQual`
	`attrGroupName`	`::=`	`NCName schemaRef?`
	`modelGroupRef`	`::=`	`modelGroupName`
	`modelGroupName`	`::=`	`NCName schemaRef?`
	`entityRef`	`::=`	`entityName`
	`entityName`	`::=`	`NCName schemaRef?`
	`notationRef`	`::=`	`notationName`
	`notationName`	`::=`	`NCName schemaRef?`

The BNF above illustrates the reference mechanisms used in this specification.

Example
<archetypeRef name='Address'/>

<elementTypeRef name='BLOCKQUOTE' schemaAbbrev='HTML'/>

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

Constraint on Schemas: Consistent Import
A schemaAbbrev or schemaName in a schemaRef must be declared in an Schema Import of the current schema, and the NCName qualified by that schemaRef must be an import (Import Restrictions) of the appropriate type per that declaration.

Constraint on Schemas: One Reference Only
The concrete syntax uses schemaAbbrev and schemaName attributes to realise schemaName. It is an error for both these attributes to appear on the same element in a schema.

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

3.4 Types, Elements and Attributes

Like XML 1.0 DTDs, XML Schema: Structures provides facilities for constraining the contents of elements and the values of attributes, and for augmenting the information set of instances, e.g. with defaulted values and type information. [Definition: ] We refer hereafter to the combination of schema constraints and information set contributions with the abbreviation SC. Compared to DTDs, XML Schema: Structures provides for a richer set of SCs, and improved capabilities for sharing SCs across sets of elements and attributes.

3.4.1 Datatype Definition

We start with [Definition: ] the simple datatypes whose expression in XML documents consists entirely of character data. As in the current draft of XML Schemas: Datatypes, wherever we speak of datatypes in this draft, we shall mean these simple datatypes. The treatment of aggregate datatypes (collections and structures) has not yet been resolved.

Datatypes

`[11]`	`datatypeDefn`	`::=`	`NCName datatypeSpec`
`[12]`	`datatypeSpec`	`::=`	`[defined by XML Schemas: Datatypes] exportControl?`
`[13]`	`datatypeQual`	`::=`	`specialize? valueConstraint?`
`[14]`	`specialize`	`::=`	`facet+`
`[15]`	`facet`	`::=`	`is defined by XML Schemas: Datatypes. It might be a range restriction, min/max constraint, etc.`
`[16]`	`valueConstraint`	`::=`	`default \| fixed`
`[17]`	`datatypeRef`	`::=`	`datatypeName datatypeQual`
`[18]`	`datatypeName`	`::=`	`NCName schemaRef?`
	`schemaRef`	`::=`	`(schemaAbbrev \| schemaName)`
	`schemaAbbrev`	`::=`	`NCName`
	`schemaName`	`::=`	`URI`

XML Schema: Structures incorporates the datatype definition mechanisms specified by [XML Schemas: Datatypes] in order to express SCs on attribute values and the character data contents of elements.

The first production above is for defining datatypes; datatypeSpec serves to indicate where this chapter connects with XML Schemas: Datatypes. exportControl is defined in Exporting Schema Constructs.

The other productions provide for using datatypes once they have been defined, see below under contentType and attrDecl.

We assume that it is appropriate to allow for some local specialization of datatypes at the point of use, and provide for that here (specialize).

As explained in References to Schema Constructs, a schemaRef, if included allows for the referenced definition to be located in some other schema.

Example
<datatype name='myDatatype'>
 <basetype name="..."/>
  [ ... TBD]
</datatype>

<datatypeRef name='myDatatype'/>

<datatypeRef name='integer'/>

<datatypeRef name='quantity' schemaName='http://www.w3.org/xsl.xsd'>
 <fixed>12pt</fixed>
</datatypeRef>
The first example awaits the XML Schemas: Datatypes concrete syntax to be filled in. The first datatypeRef example references the definition above it. The second references a datatype pre-defined by XML Schemas: Datatypes. The third references a datatype in an (imaginary) XSL schema and fixes its value.

Constraint on Schemas: Avoid Built-ins
The NCName must not be the same as the name of any of the built-in datatypes (see [XML Schemas: Datatypes]).

[Definition: ] A string (possibly empty) dt-satisfies a datatypeSpec and an optional datatypeQual if

The string is a valid instance of the datatype defined by that datatypeSpec, as specialized by the datatypeQual's specialize (if present) (see [XML Schemas: Datatypes] for a definition of when a string is a valid instance of a (possibly specialized) datatypeSpec;

and

If there is a datatypeQual and it includes a fixed, the string matches that fixed value.

Schema Information Set Contribution: Datatype Info
When a string dt-satisfies a datatypeSpec and an optional datatypeQual, the containing attribute or element information item will be augmented to indicate the datatypeSpec and the specialize (if any) which it satisfied.

NOTE: Timing constraints were such that this text may not align completely with XML Schemas: Datatypes

3.4.2 Archetype Definition

[Definition: ] Archetype definitions gather together all SCs pertinent to elements in instance documents, their attributes and their contents. They are called archetypes because there may be more than one element type which shares the same SCs (see Element Type Declaration), and which therefore can be constrained by a common archetype.

Archetypes

`[19]`	`archetypeDefn`	`::=`	`NCName archetypeSpec`
`[20]`	`archetypeSpec`	`::=`	`refinement* contentType ( attrDecl \| attrGroupRef )* model exportControl`
`[21]`	`contentType`	`::=`	`datatypeRef \| contentModel \| modelGroupRef`
	`model`	`::=`	`open \| refinable \| closed`
`[22]`	`archetypeRef`	`::=`	`archetypeName`
`[23]`	`archetypeName`	`::=`	`NCName schemaRef?`

The first three productions above provide the basic structure of the definition, the last two provide for reference to the things defined. But note that the name of an archetype is not ipso facto the name of elements whose appearance in instances will be associated with the SCs of that type. The connection between an element type name and an archetype is made by an elementTypeDecl, see below.

Alongside Attribute Declaration for permitted attributes, SCs for contents are defined in an archetype (contentType). For elements which may contain only character data, content type SCs are specified by reference to a Datatype Definition. Note that doing this by way of datatypeRef means that the character data SCs may provide for specialization and even defaulting in a manner similar to attribute values. For other kinds of elements, a Element Content Model is required.

Issue (elt-default): The extension of defaulting to element content is tentative.

Example
<archetype name='myArchetype'>
    <datatypeRef name='myDatatype'/>
    <attrDecl ...>. . .</attrDecl>
</archetype>
A simple archetype with character data content constrained by reference to a datatype defined in the same schema and one attribute.

Constraint on Schemas: AttrGroup Unique
The same attrGroupDefn must not be referenced by two or more attrGroupRefs in the same archetypeSpec.

Constraint on Schemas: AttrGroup Identified
Every attrGroupRef in a archetypeSpec must identify an attrGroupSpec.

[Definition: ] The attribute declaration set of an archetypeSpec consists of all its effective attrDecls together with all the attrDecls contained in the attrGroupSpecs identified by any attrGroupRefs it contains.

[Definition: ] The full name of an attrDecl in an attribute declaration set is its NCName plus its schemaName, i.e. if it appeared directly in the archetypeSpec, the empty string, if it was acquired by refinement or if it came from an attrGroupSpec, then the schemaName from the schemaRef which identified the relevant archetypeSpec or attrGroupSpec respectively, if any, otherwise the empty string.

Constraint on Schemas: Attribute Locally Unique
The same full name must not appear more than once in any archetypeSpec's attribute declaration set.

[Definition: ] An element item a-satisfies an archetypeSpec if the element item's attribute items taken together as a set attrs-satisfy the archetypeSpec's attribute declaration set, and either

The archetypeSpec's contentType is a datatypeRef, the datatypeRef identifies a datatypeSpec, the element item contains only comment, processing instruction and character information items and the string formed by concatenating the characters of each of the character information item children, if any, or else the empty string, dt-satisfies that datatypeSpec as qualified by the datatypeRef's datatypeQual if any;

the contentType is a contentModel, and the sequence of character and element items contained by the element item model-satisfies its effective contentModel.

Issue (sic-elt-default): The above definitions do not provide for handling a default on an archetype's datatypeRef. Preferred solution: empty element items ipso facto satisfy datatypeRefs with defaults and are augmented with the default value. This would have the consequence that you cannot provide the empty string as the explicit value of an element item if it's governed by a datatypeRef with a default.

Schema Information Set Contribution: Archetype Info
When an element item a-satisfies a archetypeSpec, that element information item will be augmented to indicate the archetypeSpec which it satisfied.

Example
Why is the separation of element type and archetype provided for? In certain XML instance documents, the same attribute and content SCs are appropriate for more than one named element. Consider the following instance fragment:
<ShippingAddress id='a32' saleable='yes'>
  <Street>1 Main Street</Street>
  <City>New York</City>
  <Zip NineDigit='FALSE'>12345</Zip>
</ShippingAddress>

<BillingAddress id='a29' saleable='no'>
  <Street>2 Rose Lane</Street>
  <City>Anytown</City>
  <Zip NineDigit='TRUE'>12345-6789</Zip>
</BillingAddress>
This fragment contains two elements, ShippingAddress and BillingAddress, that have similar attributes and content. By defining a single appropriate archetype and declaring two element types which reference it, that commonality can be precisely expressed.

NOTE: This draft does not provide any mechanism for applying any SCs to element items whose namespace does not nominate a schema. This may be addressed in a later draft: in the meantime a workaround is possible as follows: Suppose we wish to use some Dublin Core terms in a schema, but all we know is the URI for the Dublin Core document. Perhaps we want to schema-validate
<mybook><dc:creator xmlns:dc='...'>Rafael
 Sabattini</dc:creator></mybook>
where mybook is already known to be covered by my schema. The workaround is to replace the real Dublin Core URI with a local URL for a tiny schema which simply defines creator, and references the real URI for documentation.

3.4.3 Attribute Declaration

Attribute declarations associate a name (which will appear as an attribute in start tags in instances) with SCs for the presence and value thereof.

Attributes

`[24]`	`attrDecl`	`::=`	`NCName datatypeRef? required exportControl`
	`datatypeRef`	`::=`	`datatypeName datatypeQual`
	`datatypeQual`	`::=`	`specialize? valueConstraint?`
	`valueConstraint`	`::=`	`default \| fixed`
	`datatypeName`	`::=`	`NCName schemaRef?`
	`schemaRef`	`::=`	`(schemaAbbrev \| schemaName)`

NOTE: Note that the datatypeRef productions are repeated here for easy reference.

Attribute declarations provide for:

Requiring instances to have attributes;
Constraining attribute values to express a datatype;

Example
<attrDecl name='myAttribute'/>

<attrDecl name='anotherAttribute'>
 <datatypeRef name='integer'>
  <default>42</default>
 </datatypeRef>
</attrDecl>

<attrDecl name='yetAnotherAttribute' required='true'>
 <datatypeRef name='integer'/>
</attrDecl>

<attrDecl name='stillAnotherAttribute'>
 <datatypeRef name='string'>
  <fixed>Hello world!</fixed>
 </datatypeRef>
</attrDecl>
Four attributes are declared: one with no explicit SCs at all; two defined by reference to a built-in type, one with a default and one required to be present in instances; and one with a fixed value.

When attribute declarations are used in an archetype specification, each archetype provides its own symbol space for attribute names. E.g. an attribute named title within one archetype need not have the same datatypeRef as one declared within another archetype.

[Definition: ] An attribute item attr-satisfies an attrDecl if

The attrDecl contains no datatypeRef and the attribute item's value string dt-satisfies the default datatypeSpec for attributes

the attrDecl's datatypeRef identifies a datatypeSpec and the attribute item's value string dt-satisfies that datatypeSpec as qualified by the datatypeRef's datatypeQual if any

where the attribute item's value consists of only character information items and by its "value string" is meant the string formed by concatenating the characters of each of those character information item children, if any, or else the empty string.

Issue (default-attr-datatype): What is the default attribute datatypeSpec?

[Definition: ] The attribute items of an element item attrs-satisfy an attribute declaration set if

1) for each attribute item either
- 1a) there is an attrDecl in the attribute declaration set whose full name consists of an NCName which matches the attribute item's name and either
  - 1a1) the attribute item has no namespace and the attrDecl's full name has no schemaName
  or
  - 1a2) the attribute item's namespace and the attrDecl's full name's schemaName are identical
  and the attribute item attr-satisfies the declaration
or
- 1b) the archetypeSpec being a-satisfied by the attribute item's parent element item is open

and

2) every attrDecl in the attribute declaration set which is required is used to attr-satisfy an attribute item in the context of (1a) above

Schema Information Set Contribution: Attribute Value Default
For every attrDecl in the attribute declaration set not used to attr-satisfy an attribute item in the context of (1a) above which has a datatypeRef which has a default, an attribute item with the default value is added to the parent element item.

Issue (namespace-declare): We've got a problem with namespace declarations: they're not attributes at the infoset level, so they can appear without compromising validity, EXCEPT if there is a fixed or required declaration, and defaults should have the apparently desired effect.

3.4.4 Attribute Group Definition

XML Schema: Structures can name a group of attributes so that they may be incorporated as a whole into archetype definitions:

Attribute groups

`[25]`	`attrGroupDefn`	`::=`	`NCName attrGroupSpec`
`[26]`	`attrGroupSpec`	`::=`	`attrDecl* exportControl`
`[27]`	`attrGroupRef`	`::=`	`attrGroupName attrGroupQual`
`[28]`	`attrGroupName`	`::=`	`NCName schemaRef?`
`[29]`	`attrGroupQual`	`::=`	`attrDecl`

Attribute group definitions:

provide a construct to replace some uses of parameter entities.
allow for the definition of SCs that relate values of one attribute to others within the group.

Example
<attrGroup name='myAttrGroup'>
    <attrDecl .../>
    ...
</attrGroup>

<archetype name='myElementType'>
    <empty/>
    <attrGroupRef name='myAttrGroup'/>
</archetype>
Define and refer to an attribute group. The effect is as if the attribute declarations in the group were present in the archetype definition.

NOTE: There needs to be a Constraint on Schema which constrains the attrDecls which appear with an attrGroupRef: the name is the same as one of the attrDecls in the group, datatype and defaulting preserves substitutability, etc.

3.4.5 Element Content Model

When content of elements is not constrained by reference to a datatype (Datatype Definition), it can have any, empty, element-only or mixed content. In the latter cases, the form of the content is specified in more detail.

Content model

[30] contentModel ::= any | empty | mixed | eltOnly

A content model constrains the content of an archetype or an element type: it says nothing about attributes.

Example

<any/>   
   
<empty/> 

<mixed>...</mixed>

[Element only content -- see element-only below]

Content models do not have names, but appear as a part of the definition of an archetype, which does have a name. Model groups can be named and used by name, see below.

[Definition: ] A sequence of character and element items (call this CESeq) model-satisfies an effective contentModel if

the sequence is empty and the effective contentModel is empty;
the effective contentModel is any and every element item in CESeq is independently valid, and for every element item in CESeq such that the schema which its namespace item resolves to is not the current schema there is an import whose schemaName is identical to that element item's namespace item's URI and that import must either be allElementTypes or contain an elementTypeRef whose NCName matches that element item's name;
the effective contentModel is mixed and every element item in CESeq mixed-satisfies the effective mixed

the effective contentModel is eltOnly and the only character items in CESeq are whitespace character items and the sub-sequence of CESeq consisting of all the element items therein eo-satisfies the effective eltOnly.

3.4.6 Mixed Content

A content model for mixed content provides for mixing elements with character data in document instances. The allowed element types are named, but neither their order or their number of occurrences are constrainted.

Mixed content

[31] mixed ::= ( elementTypeRef | elementTypeDecl )*

The elementTypeRefs and elementTypeDecls determine the element types which may appear as children along with character data.

Example
<mixed>
 <elementTypeRef name='name1'/>
 <elementTypeRef name='name2'/>
 <elementTypeRef name='name3'/>
</mixed>
Allows character data mixed with any number of name1, name2 and name3 elements.

NOTE: The fact that mixed allows for there to be no elementTypeRefs or elementTypeDecls makes it similar to XML 1.0's Mixed production. Indeed an empty mixed is the only way a schema can allow character data content with no datatype constraint at all.

Constraint on Schemas: Element Type Unique in Mixed
A given NCName must not appear two or more times among the elementTypeDecls and elementTypeRefs with no schemaRefs; a given elementTypeName must not appear two or more times among the elementTypeRefs.

See Element Type Declaration for discussion and examples of the appearance of elementTypeDecl above.

[Definition: ] An element item mixed-satisfies a mixed if

the mixed contains an elementTypeRef which the element item ref-satisfies

the mixed contains an elementTypeDecl whose NCName matches the element item's name, in which case the element item must e-satisfy that elementTypeDecl

the archetypeSpec which effectively contains the mixed is open and the element item is independently valid.

Issue (mixed-change-current-schema): There's an implicit change in current schema in the definition of satisfy-mixed above which should be made explicit.

3.4.7 Element-Only Content

A content model for element-only content specifies only child elements (no immediate character data content other than white space is allowed). The content model consists of a simple grammar governing the allowed types of child elements and the order in which they must appear.

Element-only content

`[32]`	`eltOnly`	`::=`	`modelElt`
`[33]`	`modelElt`	`::=`	`occur ( modelGroup \| modelGroupRef \| elementTypeRef \| elementTypeDecl )`
`[34]`	`occur`	`::=`	`min max?`
`[35]`	`modelGroup`	`::=`	`compositor modelElt modelEltSeq`
`[36]`	`compositor`	`::=`	`sequence \| choice \| all`
`[37]`	`modelEltSeq`	`::=`	`modelElt modelEltSeq?`

The grammar for element-only content is built on model elements and model groups (modelElt and modelGroup above). A model element provides for some number of occurrences in an instance of either a single element (via elementTypeRef or elementTypeDecl) or a group of elements (via modelGroup or modelGroupRef). A model group is two or more model elements plus a compositor.

A compositor for a model group specifies for a given group whether it is a sequence of its model elements, a choice between its model elements or a set of its model elements which must appear in instances. These options reconstruct the XML 1.0 , connector, the XML 1.0 | connector and the SGML & connector respectively. In the first case (sequence) all the model elements must appear in the order given in the group; in the second case (choice), exactly one of the model elements must appear in the element content; and in the third case (all), all the model elements must appear in the element content, but may appear in any order.

The occur specification governs how many times the instance material allowed by a modelElt may occur at that point in the grammar. The absence of a max specification means that no upper bound is placed on the number of occurrences.

See Element Type Declaration for further discussion and examples of the appearance of elementTypeDecl within modelElt above.

Example
<elementTypeRef name='paragraph'/>

<sequence>
 <elementTypeRef name='name1'/>
 <elementTypeRef name='name2' prefix='HTML'/>
</sequence>

<choice minOccur='3' maxOccur='9'>
 <elementTypeRef name='name1'/>
 <elementTypeRef name='name2'/>
</choice>    

<all minOccur='3'>
 <elementTypeRef name='name1'/>
 <elementTypeRef name='name2'/>
</all>

<choice>
 <all>
  <elementTypeRef name='name1'/>
  <elementTypeRef name='name2'/>    
 </all>
 <all>
  <elementTypeRef name='name3'/>
  <elementTypeRef name='name4'/>    
 </all>
</choice>
A minimal model which simply requires a paragraph (the default is minOccur=maxOccur=1; a sequence of two elements (one from another schema); between 3 and 9 elements, each a choice between two; at least three pairs, in any order; one of two pairs, the elements in the chosen pair in any order.

[Definition: ] A sequence of element items eltOnly-satisfies an effective eltOnly if

it is possible to trace out a path through the content model, obeying the compositor and occur specifications and accepting each element item in the sequence with an elementTypeRef or elementTypeDecl in the content model. Accepting an element item from the sequence with an elementTypeRef requires that it ref-satisfy that elementTypeRef; accepting an element item with an elementTypeDecl requires that the elementTypeDecl's NCName matches the element item's name, in which case the element item must e-satisfy that elementTypeDecl.

NOTE: The above definition of eltOnly-satisfy does not explicitly incorporate the modifications required when the containing archetype is open, as set out at the end of Archetype Refinement, but it should be understood as doing so.

Constraint on Schemas: Element Consistency
A given NCName must not appear both among the elementTypeDecls and among the elementTypeRefs with no schemaRefs, or more than once among the elementTypeDecls.

NOTE: Note that the above permits repeated use of the same elementTypeRef, analogous to DTD usage.

Constraint on Schemas: Unambiguous Content Model
For compatibility, it is an error if a content model is such that there exist element item sequences within which some item can match more than one occurrence of an elementTypeRef or elementTypeDecl in the content model.

Issue (still-unambig): Should this compatibility constraint be preserved?

3.4.8 Named Model Group

This reconstructs another common use of parameter entities.

Named model groups

`[38]`	`modelGroupDefn`	`::=`	`NCName modelGroupSpec`
`[39]`	`modelGroupSpec`	`::=`	`( modelGroup \| modelGroupRef ) exportControl`
`[40]`	`modelGroupRef`	`::=`	`modelGroupName`
`[41]`	`modelGroupName`	`::=`	`NCName schemaRef?`

Example

<modelGroup name='myModelGroup'>
 <elementTypeRef name='myElementType'/>
</modelGroup>

<elementType name='myElementType'>
 <modelGroupRef name='myModelGroup'/>
 <attrDecl ...>. . .</attrDecl>
</elementType>

<elementType name='anotherElementType'>
 <choice>
  <elementTypeRef name='yetAnotherElementType'/>
  <modelGroupRef name='myModelGroup'/>
 </choice>
 <attrDecl ...>. . .</attrDecl>
</elementType>

A minimal model group is defined and used by reference, first as the whole content model, then as one alternative in a choice.

3.4.9 Element Type Declaration

An [Definition: ] element type declares the association of an element type name with an archetype, either by reference or by incorporation.

Element type declaration

`[42]`	`elementTypeDecl`	`::=`	`NCName elementTypeSpec`
`[43]`	`elementTypeSpec`	`::=`	`( archetypeRef \| archetypeSpec ) exportControl global?`
`[44]`	`elementTypeRef`	`::=`	`elementTypeName`
<

XML Schema Part 1: Structures

W3C Working Draft 6-May-1999

This version

Latest version:

Editors:

Status of this Document

Abstract

Table of Contents

Appendices

1. Introduction

1.1 Documentation Conventions

1.2 Purpose

1.3 Relationship To Other Work

1.4 Terminology

2. Conceptual Framework

2.1 Kinds of XML Documents

2.2 On schemas, constraints and contributions

2.3 On 'types'

2.4 Schemas and their component parts

2.5 Names and Symbol Spaces

2.6 Abstract and Concrete Syntax

3. Schema Definitions and Declarations

3.1 The Schema

3.2 The Document and its Root

3.3 References to Schema Constructs

3.4 Types, Elements and Attributes

3.4.1 Datatype Definition

3.4.2 Archetype Definition

3.4.3 Attribute Declaration

3.4.4 Attribute Group Definition

3.4.5 Element Content Model

3.4.6 Mixed Content

3.4.7 Element-Only Content

3.4.8 Named Model Group

3.4.9 Element Type Declaration