XML Schema Part 1: Structures

XML Schema: Structures is part 1 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).

Status of this document

This is a W3C Working Draft for review by members of the W3C and other interested parties in the general public.

It has been reviewed by the XML Schema Working Group and the Working Group has agreed to its publication. Note that not that all sections of the draft represent the current consensus of the WG. Different sections of the specification may well command different levels of consensus in the WG. Public comments on this draft will be instrumental in the WG's deliberations.

This draft incorporates a substantial change to the concrete syntax from the previous public working draft, intended to simplify it and make it easier to use (the full text of the proposal from the working group's task force [Simple TF Proposal], along with a cover note containing a discussion of alternatives considered and outstanding issues [Simple TF Background], are available as background).

Three major components of this document are marked below as out-of-date and/or under construction: major efforts by task forces from within the WG are underway with respect to these, and their reports are linked from this draft. We felt it was important to present this work to the public, in keeping with our obligation to produce drafts for public inspection and comment on a regular basis, despite the "Under Construction" signs posted below. It is our intention henceforth to publish interim working drafts with greater frequency, both to keep interested parties informed of our progress, and to emphasize the "work in progress" nature of these drafts.

Sections which are not the status quo, that is on which the working group has not yet reached consensus, are marked with an asterisk (*) at the end of the section title. But please note that all the facilities described herein are in a preliminary state of design. The Working Group anticipates substantial changes, both in the mechanisms described herein, and in additional functions yet to be described. The present version should not be implemented except as a check on the design and to allow experimentation with alternative designs. 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".

Appendices

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

[Definition:] Instance: An XML element information item which conforms to some schema. See [XML-Infoset] for a discussion of information items: in brief, [Definition:] an element information item is the component of an infoset which corresponds to an element. From it other information items are accessible, including attributes, namespace declaration and content. See Associating Instance Document Constructs with Corresponding Schemas (§4.2.5) and Schema Validity * (§6.1) for the means by which an instance identifies the schema(s) to which it conforms. Note we will often speak loosely about an (XML) instance document, but this is just shorthand for element information item associated with the document element of an XML document. Similarly, we will often speak of elements when we mean element information item.
[Definition:] XML Schema: An XML element information item which, along with its descendants, satisfies all the Constraints on Schemas in this specification. An XML Schema establishes a set of rules for constraining the structure and articulating the information set of XML document instances.

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

Any schema is ipso facto an element information item. It follows that the rules specified herein for validity apply to all of the following kinds of XML element information items:

Elements that are not schemas;
Schemas applicable to documents that are not schemas;
The schema applicable to schemas.

Likewise, rules for schemas in general apply to the particular schema for schemas, which is an instance conforming to 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 * (§A);
[Definition:] Schema-Validity Constraint: Constraints on the form and content of instances, which the instances must satisfy to be schema-valid;
[Definition:] Schema Information Set Contribution: Augmentations to instance information sets which follow as a consequence of schema-validation.

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

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

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

2.3 Schemas, Types and Elements

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

The schema language is itself a set of elements and attributes. We will describe these, and show how they are used. But first, a quick example of an XML document.

Example

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

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

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

If we're going to use the same element in a number of places, we can declare it once and refer to it by name elsewhere:

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

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

Example
<archetype name="PurchaseOrderType">
    <element name="shipTo"    type="Address" />
    <element name="shipDate"  type="date" />
    <element ref="comment" minOccurs='0' />
    <element name="Items"     type="Items" />
    <attribute name="orderDate" type="date" />
</archetype>
The shipDate element daughter of PurchaseOrderType is declared above as having an atomic type, as in the Address example above. The comment daughter is declared by reference to a global element declaration. Similarly, the shipTo and Items daughters are declared as having complex types which must be defined elsewhere in the current schema. The comment daughter and the orderDate attribute are optional, the others are obligatory.

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

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

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

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

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

Example

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

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

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

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

Example
<archetype name='Items'>
 <element name='Item' minOccurs='0' maxOccurs='*'>
  <archetype>
   <element name='productName' type='string' />
   <element name='quantity' type='integer'>
    <minExclusive>0</minExclusive>
   </element>
   <element name='price' type='number' />
   <element ref='comment' minOccurs='0' />
  </archetype>
 </element>
</archetype>
Here not only is the archetype of the Item element given in line, but also the datatype referenced by its quantity daughter (the built-in integer datatype) is also qualified inline by adding a subrange constraint.

Taken together the examples above constitute a complete schema for the initial PurchaseOrder example instance. They are drawn together in a single complete schema in Sample Schema (non-normative) * (§G).

2.4 Schemas and their component parts

The next chapter Schema Definitions and Declarations (§3) 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. A 'Yes' in the 'Name apears in instances?' column indicates that the name will appear in instances -- other names are for schema use only.

XML Schema: Structures Feature	Purpose	Named?	Name appears in instances?
The Schema (§3.1)	A wrapper element containing all the definitions and declarations comprising a schema.	Yes	No
Datatype Definition (§3.4.1)	An atomic 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	No
Archetype Definition (§3.4.2)	A complete set of constraints for elements in instance documents, applying to both contents and attributes.	Yes	No
Element Declaration (§3.4.9)	An association between a name for an element and a type. An element declaration for 'A' is comparable to a DTD declaration `<!ELEMENT A .....>`.	Yes (local or global)	Yes
Attribute Declaration (§3.4.3)	An association between 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)	Yes
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	No
Element Content Model (§3.4.5)	A constraint that applies to the contents of elements in an instance document. Content models do not include attribute declarations.	No	No
Element-Only Content (§3.4.7)	Components for constructing content models which allow only element content. Includes facilities for grouping and sequencing, as well as for declaration of and reference to elements.	No (but see below)	No
Attribute Group Definition * (§3.4.4)	An association between a name and a reusable collection of attribute declarations.	Yes	No
Named Model Group * (§3.4.8)	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	No
Archetype Refinement * (§3.5)	One archetype may be defined as refining one or more other archetypes, acquiring content type and/or attributes therefrom.	Yes	No
Schema Import (§4.2.2)	Extends the current schema with definitions and/or declarations from elsewhere, retaining the association with their origin.	No	No
Schema Inclusion (§4.2.4)	Integrates definitions and/or declarations from elsewhere into the schema being defined, as if they had been defined locally.	No	No

2.5 Names and Symbol Spaces

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

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

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

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, paradigms and in (normative) Schema for Schemas * (§A) and (normative) DTD for Schemas * (§B). Unlike the previous version, in which the intention was to stay quite close to the abstract syntax, in this version we have begun to take convenience and clarity into account.

3 Schema Definitions and Declarations

The principal purpose of XML Schema: Structures is to provide a means for defining schemas that constrain the contents of instances 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 \| elementDecl \| attrGroupDefn \| modelGroupDefn \| notationDecl \| entityDecl`
`[3]`	`preamble`	`::=`	`xmlSchemaRef targetNamespace schemaVersion model export? import? include?`
`[4]`	`xmlSchemaRef`	`::=`	`URI`
`[5]`	`targetNamespace`	`::=`	`URI`
`[6]`	`schemaVersion`	`::=`	`string-value`
`[7]`	`model`	`::=`	`open \| refinable \| closed`

preamble consists of an xmlSchemaRef specifying the URI for XML Schema: Structures; the targetNamespace specifying the URI of the namespace which this schema is about; and a schemaVersion specification for private version documentation purposes and version management.

See Schema Composition and Namespaces * (§4) for discussion of schemas, instances and namespaces.

Ed. Note: The whole matter of instance/schema connections is still under discussion: the WG has not reached consensus in this area. The referenced section does give some indication of where our thinking in this area is going.

<-- Category: top-level --><comment> <-- Content: text --> </comment>

Example

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

<schema targetNS='http://purl.org/metadata/dublin_core'
        version='M.n'
        xmlns='http://www.w3.org/1999/09/24-xmlschema'>

  ...

</schema>

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

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

The schema's model property is discussed in Archetype Refinement * (§3.5). The schema's export, import and include properties are discussed in Schema Composition and Namespaces * (§4).

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

Summary of Definitions and Declarations

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

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

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

 <element name='myElement'>
  ...
 </element>

 <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 component, we establish an association between its name and the specification for that component. Each new component therefore creates a new entry in the symbol space for that kind of component.

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

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

3.2 The Document and its Root

NOTE: We have not so far seen any need to reconstruct the XML 1.0 notion of root. For the connection from document instances to schemas, see Associating Instance Document Constructs with Corresponding Schemas (§4.2.5) and Schema Validity * (§6.1).

3.3 References to Schema Constructs

Uniform means are provided for reference to a broad variety of schema constructs, both within a single schema and to features imported (Schema Import (§4.2.2)) 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. 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`
	`typeRef`	`::=`	`archetypeRef \| datatypeRef`
	`datatypeRef`	`::=`	`datatypeName datatypeQual`
	`datatypeName`	`::=`	`NCName schemaRef?`
	`archetypeRef`	`::=`	`typeName`
	`archetypeName`	`::=`	`NCName schemaRef?`
	`elementRef`	`::=`	`elementName`
	`elementName`	`::=`	`NCName schemaRef?`
	`attrGroupRef`	`::=`	`attrGroupName attrGroupQual`
	`attrGroupName`	`::=`	`NCName schemaRef?`
	`modelGroupRef`	`::=`	`modelGroupName`
	`modelGroupName`	`::=`	`NCName schemaRef?`
	`entityRef`	`::=`	`entityName`
	`entityName`	`::=`	`NCName schemaRef?`
	`notationRef`	`::=`	`notationName`
	`notationName`	`::=`	`NCName schemaRef?`

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

Example
<element type='Address'/>

<element type='BLOCKQUOTE' schemaAbbrev='XHTML'/>

<attribute type='quantity' schemaName='http://www.w3.org/xsl.xsd'/>
The first of these is a local reference, the other two refer to schemas elsewhere. The BLOCKQUOTE example assumes the schemaAbbrev XHTML has been declared for import; the template example similarly assumes that the given (imaginary as of this writing) URL has been declared for import. See Schema Import (§4.2.2) for a discussion of importing.

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

The One Reference Only (§6.2.2) Constraint on Schemas obtains.

The identify definition wrt schema-validity obtains.

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

3.4 Types, Elements and Attributes

Like XML 1.0 DTDs, XML Schema: Structures provides facilities for constraining the contents of elements and the values of attributes, and for augmenting the information set of instances, e.g. with defaulted values and type information. [Definition:] We 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.

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, length 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 specification mechanisms defined by [XML Schemas: Datatypes] in order to express SCs on attribute values and the contents of elements consisting entirely of character data.

The production for datatypeSpec above serves to indicate where this chapter connects with XML Schemas: Datatypes. exportControl is defined in Exporting Schema Constructs (§4.2.1). The concrete syntax displayed below is copied from [XML Schemas: Datatypes]. Most of the elements are for specifying facets: they are all optional and may appear in any order after the basetype element.

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

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 (§3.3), a schemaRef, if included, allows for the referenced definition to be located in some other schema.

<-- Category: datatype --><basetype name = NMTOKEN schemaAbbrev = NMTOKEN schemaName = CDATA />

<-- Category: top-level --><datatype export = "true" | "false" name = NMTOKEN> <-- Content: (basetype , ((minExclusive | minInclusive)? & (maxExclusive | maxInclusive)? & precision? & scale? & enumeration? & length? & lexicalRepresentation? & maxLength?)) --> </datatype>

<-- Category: datatype --><enumeration> <-- Content: literal+ --> </enumeration>

<-- Category: datatype --><length> <-- Content: text --> </length>

<-- Category: datatype --><lexical> <-- Content: text --> </lexical>

<-- Category: datatype --><lexicalRepresentation> <-- Content: lexical+ --> </lexicalRepresentation>

<-- Category: datatype --><literal> <-- Content: text --> </literal>

<-- Category: datatype --><maxExclusive> <-- Content: text --> </maxExclusive>

<-- Category: datatype --><maxInclusive> <-- Content: text --> </maxInclusive>

<-- Category: datatype --><maxLength> <-- Content: text --> </maxLength>

<-- Category: datatype --><minExclusive> <-- Content: text --> </minExclusive>

<-- Category: datatype --><minInclusive> <-- Content: text --> </minInclusive>

<-- Category: datatype --><precision> <-- Content: text --> </precision>

<-- Category: datatype --><scale> <-- Content: text --> </scale>

Example
<datatype name='posInt'>
 <basetype name='integer'/>
 <minExclusive>0</minExclusive>
</datatype>

<attribute name='foo' type='posInt'/>

<attribute name='baz' type='integer'/>

<attribute name='fontSize' type='quantity' schemaName='http://www.w3.org/xsl.xsd'>
 <fixed>12pt</fixed>
</attribute>
The first attribute 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.

NOTE: See previous note on the type definition issue.

The satisfy-dt definition wrt schema-validity obtains.

The Datatype Info (§6.2.3.1) Schema Information Set Contribution obtains.

3.4.2 Archetype Definition

[Definition:] Archetype specifications 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 declaration that shares the same SCs (see Element Declaration (§3.4.9)), and which therefore can be constrained by a common archetype.

Archetypes

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

The first three productions above provide the basic structure of the specification, and the last two provide for reference to the things specified. 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 archetype. The connection between an element name and an archetype is made by an elementDecl, see below.

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

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

<-- Category: archetype --><datatypeQual> <-- Content: ((minExclusive | minInclusive)? & (maxExclusive | maxInclusive)? & precision? & scale? & enumeration? & length? & lexicalRepresentation? & maxLength?) --> </datatypeQual>

<-- Category: archetype --><refines name = NMTOKEN schemaAbbrev = NMTOKEN schemaName = CDATA />

Example
<archetype name='length1' type='number'/>
 <minInclusive>0</minInclusive>
 <attribute name='unit' type='NMTOKEN'/>
</archetype>

<element name='width' type='length1'/>

  <width unit='cm'>2.54</width>

<archetype name='length2'>
 <element name='size' type='number'>
  <minInclusive>0</minInclusive>
 </element>
 <element name='unit' type='NMTOKEN'/>
</archetype>

<element name='depth' type='length2'/>

  <depth>
   <size>2.54</size><unit>cm</unit>
  </depth>
Two approaches to defining an archetype for length: one with character data content constrained by a qualified reference to a built-in datatype, and one attribute, the other using two elements.

The way in which the concrete syntax defined and illustrated above realises the abstract syntax is not straightforward, because it is optimised to make simple cases simple. The datatypeQual option is allowed only if a type attribute is present. Similarly, the schemaName or schemaAbbrev, the default and the fixed attributes are allowed only if a type attribute is present. Finally, if a type attribute is present, it must reference a datatype, and the content attribute must be textOnly (or absent, in which case it defaults to textOnly). This is to handle the main alternation in the abstract syntax for contentType, which allows either (possibly locally qualified) reference to a datatype or a content model.

NOTE: See previous note on the type definition issue.

The AttrGroup Unique (§6.2.3.2) Constraint on Schemas obtains.

The AttrGroup Identified (§6.2.3.2) Constraint on Schemas obtains.

The attr-decl-set definition wrt schema-validity obtains.

The attr-fullname definition wrt schema-validity obtains.

The Attribute Locally Unique (§6.2.3.2) Constraint on Schemas obtains.

The satisfy-as definition wrt schema-validity obtains.

The Archetype Info (§6.2.3.2) Schema Information Set Contribution obtains.

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

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

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

<-- Category: archetype --><attribute content = "textOnly" | "empty" default = CDATA fixed = CDATA maxOccurs = "1" minOccurs = "0" name = NMTOKEN schemaAbbrev = NMTOKEN schemaName = CDATA type = "string"> <-- Content: ((minExclusive | minInclusive)? & (maxExclusive | maxInclusive)? & precision? & scale? & enumeration? & length? & lexicalRepresentation? & maxLength?) --> </attribute>

Example
<attribute name='myAttribute'/>

<attribute name='anotherAttribute' type='integer' default='42'>
 <minExclusive>0</minExclusive>
</attribute>

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

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

The maxOccurs attribute is FIXED at 1 for all attributes. Consistent with this, minOccurs can only be 0 or 1.

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.

The attr-satisfy definition wrt schema-validity obtains.

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

The satisfy-attrs definition wrt schema-validity obtains.

The Attribute Value Default (§6.2.3.3) Schema Information Set Contribution obtains.

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. I.e., if a schema declares an attribute whose name is xmlns with a default or fixed value, does it change the infoset? Or if we allow QNames as such to be declared, xmlns:foo.

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

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

Attribute group definitions provide a construct to replace some uses of parameter entities.

<-- Category: top-level --><attrGroup export = "true" | "false" name = NMTOKEN> <-- Content: (attrGroupRef | attribute)+ --> </attrGroup>

<-- Category: archetype --><attrGroupRef name = NMTOKEN schemaAbbrev = NMTOKEN schemaName = CDATA />

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

<archetype name='myelement' content='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.

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

Ed. Note: There needs to be some discussion of what happens in case of name conflict between attrs as a result of an attr group ref.

3.4.5 Element Content Model

When content of elements is not constrained by reference to a datatype (Datatype Definition (§3.4.1)), 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

[31] contentModel ::= any | empty | mixed | elemOnly

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

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.

The satisfy-cm definition wrt schema-validity obtains.

3.4.6 Mixed Content

A content model for mixed content provides for mixing elements with character data in document instances. The allowed elements are named, but neither their order nor their number of occurrences is constrained.

Mixed content

[32] mixed ::= ( elementRef | archetypeRef | elementDecl )*

The elementRefs and elementDecls determine the elements that may appear as children along with character data. For the interpretation of archetypeRef in this context, see Archetype Refinement * (§3.5).

Example
<archetype content='mixed'>
 <element ref='name1'/>
 <element ref='name2'/>
 <element ref='name3'/>
</archetype>
Allows character data mixed with any number of name1, name2 and name3 elements.

NOTE: The fact that mixed allows for there to be no elementRefs or elementDecls 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.

The Element Unique in Mixed (§6.2.3.5) Constraint on Schemas obtains.

See Element Declaration (§3.4.9) for discussion and examples of the appearance of elementDecl above.

The satisfy-mixed definition wrt schema-validity obtains.

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

`[33]`	`elemOnly`	`::=`	`modelElt`
`[34]`	`modelElt`	`::=`	`occurs ( modelGroup \| modelGroupRef \| elementRef \| archetypeRef \| elementDecl )`
`[35]`	`occurs`	`::=`	`minOccurs maxOccurs`
`[36]`	`modelGroup`	`::=`	`richModelGroup \| simpleModelGroup`
`[37]`	`richModelGroup`	`::=`	`compositor modelElt modelEltSeq`
`[38]`	`compositor`	`::=`	`sequence \| choice`
`[39]`	`modelEltSeq`	`::=`	`modelElt modelEltSeq?`
`[40]`	`simpleModelGroup`	`::=`	`all simpleModelElt simpleModelEltSeq`
`[41]`	`simpleModelElt`	`::=`	`elementRef \| elementDecl \| archetypeRef`
`[42]`	`simpleModelEltSeq`	`::=`	`simpleModelElt simpleModelEltSeq?`

Ed. Note: I'm unclear what the status of collection is after the Montreal votes, for the time being it's out.

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 elementRef or elementDecl) 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 (this is the case for the implicit 'and' compositor, which is associated with the simpleModelGroup production. 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, which are restricted in this case only to unqualified elementRefs and elementDecls, must appear in the element content, but may appear in any order.

The occurs specification governs how many times the instance material allowed by a modelElt may occur at that point in the grammar, but note that the components of a group whose compositor is (implicitly) 'all' are not qualified, and therefor call for exactly one appearance of the element they identify.

See Element Declaration (§3.4.9) for further discussion and examples of the appearance of elementDecl within modelElt above.

For the interpretation of archetypeRef in this context, see Archetype Refinement * (§3.5).

The satisfy-eo definition wrt schema-validity obtains.

The Element Consistency (§6.2.3.6) Constraint on Schemas obtains.

The Unambiguous Content Model (§6.2.3.6) Constraint on Schemas obtains.

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

`[43]`	`modelGroupDefn`	`::=`	`NCName modelGroupSpec`
`[44]`	`modelGroupSpec`	`::=`	`( modelGroup \| modelGroupRef ) exportControl`
`[45]`	`modelGroupRef`	`::=`	`modelGroupName`
`[46]`	`modelGroupName`	`::=`	`NCName schemaRef?`

<-- Category: content --><modelGroupRef maxOccurs = CDATA minOccurs = "1" name = NMTOKEN schemaAbbrev = NMTOKEN schemaName = CDATA />

Example

<modelGroup name='myModelGroup'>
 <element ref='myelement'/>
</modelGroup>

<element name='myelement'>
 <archetype>
  <modelGroupRef name='myModelGroup'/>
  <attribute ...>. . .</attribute>
 </archetype>
</element>

<element name='anotherelement'>
 <archetype>
  <group order='choice'>
   <element ref='yetAnotherelement'/>
   <modelGroupRef name='myModelGroup'/>
  </group>
  <attribute ...>. . .</attribute>
 </archetype>
</element>

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 Declaration

An [Definition:] element declaration associates an element name with a type, either by reference or by incorporation.

Element declaration

`[47]`	`elementDecl`	`::=`	`NCName elementSpec`
`[48]`	`elementSpec`	`::=`	`( typeRef \| archetypeSpec \| datatypeSpec) exportControl global?`
`[49]`	`typeRef`	`::=`	`archetypeRef \| datatypeRef`
`[50]`	`elementRef`	`::=`	`elementName`
`[51]`	`elementName`	`::=`	`NCName schemaRef?`

An element declaration associates a name with a specification. This name will appear in tags in instance documents; the specification provides SCs on the form of elements tagged with the given name. An element declaration whose elementSpec is an archetypeSpec is comparable to an <!ELEMENT ...> declaration in an XML 1.0 DTD.

elementSpec not only allows for element declarations to associate a name with an archetypeSpec (by reference or inclusion), but also allows the reference or specification to be for a datatype, with the implication that no attributes are allowed in instances and the text-only content will be constrained appropriately.

elementRef and elementName provide for top-level element declarations to be referenced by name from content models.

As noted above element names are in a separate symbol space from the symbol spaces for the names of types, so there can (but need not be) an archetype or datatype with the same name as a top-level element.

In the case of ambiguity of type reference, that is when the typeRef option is used and there are both a datatype and an archetype of the referenced name in the relevant schema, the ambiguity is resolved in favour of the archetype.

NOTE: See previous note on the ambiguity issue.

The elt-fullname definition wrt schema-validity obtains.

An elementDecl may appear both at the top level of a schema and within a modelElt. See above (Element-Only Content (§3.4.7) and Mixed Content (§3.4.6)) for where this is allowed. This declares a locally-scoped association between an element name and a type. As with attribute names, locally-scoped element names reside in symbol spaces local to the archetype that defines them. Note however that archetype and datatype names are always top-level names within a schema, even when associated with locally-scoped element names.

NOTE: It is not yet clear whether a type defined implicitly by the appearance of a archetypeSpec or datatypeSpec directly within an elementSpec, or by the use of a typeRef which refers to a datatype, will have an implicit name, or if so what that name would be.

<-- Category: top-level --><element archRef = NMTOKEN default = CDATA export = "true" | "false" fixed = CDATA maxOccurs = CDATA minOccurs = "1" name = NMTOKEN ref = NMTOKEN schemaAbbrev = NMTOKEN schemaName = CDATA type = NMTOKEN> <-- Content: (datatype | archetype)? --> </element>

Example

<element name='myelement' type='myDatatype'/>

<element name='et0' type='myType'/>

<element ref='et1'/>

<element name='et1'>
 <archetype order='all'>
  <element . . . />
  . . .
  <attribute ...>. . .</attribute>
 </archetype>
</element>

<element name='et2'>
 <archetype content='any'/>
</element>

<element name='et3'>
 <archetype content='empty'>
  <attribute ...>. . .</attribute>
 </archetype>
</element>

<element name='et4'>
 <archetype order='choice'>
  <element . . . />
  . . .
  <attribute ...>. . .</attribute>
 </archetype>
</element>

<element name='et5'>
 <archetype order='seq'>
  <element . . . />
  . . .
  <attribute ...>. . .</attribute>
 </archetype>
</element>

<element name='et6'>
 <archetype model='open' content='mixed'/>
</element>

A pretty complete set of alternatives. Note the last one is intended to be equivalent to the idea sometimes called WFXML, for Well-Formed XML: it allows any content at all, whether defined in the current schema or not, and any attributes.

<element name='contextOne'>
 <archetype order='seq'>
  <element name='myLocalelement' type='myFirstType'/>
  <element ref='globalelement'/>
 </archetype>
</element>

<element name='contextTwo'
 <archetype order='seq'>
  <element name='myLocalelement' type='mySecondType'/>
  <element ref='globalelement'/>
 </archetype>
</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

XML Schema Part 1: Structures

W3C Working Draft 24 September 1999

Abstract

Status of this document

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 Schemas, Types and Elements

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 Declaration