W3C XML Schema Definition Language (XSD): Component Designators

%versionEntities; expanded name' > expanded names' > ]>

&WD-SCDS;-&iso.doc.date;

W3C Working Draft

&draft.day; &draft.month; &draft.year; &SCDS.base;/ XML http://www.w3.org/TR/xmlschema-ref/ http://www.w3.org/TR/2005/WD-xmlschema-ref-20050329/ http://www.w3.org/TR/2004/WD-xmlschema-ref-20040716/ http://www.w3.org/TR/2004/WD-xmlschema-ref-20040309/ http://www.w3.org/TR/2003/WD-xmlschema-ref-20030109/ Mary Holstege Mark Logic Corporation Asir S. Vedamuthu webMethods (until May 2005)

XML Schema: Component Designators defines a scheme for identifying XML Schema components as specified by XML Schema Part 1: Structures and XML Schema Part 2: Datatypes.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a Working Draft for review by members of the public and by members and other Working Groups of the World Wide Web Consortium. It has been produced by the W3C XML Schema Working Group (WG) as part of the XML Activity. It incorporates all Working Group decisions through 2008-07-25. It has been reviewed by the Working Group and the Working Group has agreed to publication as a Working Draft. The Working Group expects about a month of additional refinement and review before producing a Last Call Working Draft in substantially the same form.

Comments on this document should be made in W3C's public installation of Bugzilla, specifying "XML Schema" as the product. Instructions can be found at http://www.w3.org/XML/2006/01/public-bugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list, www-xml-schema-comments@w3.org (archive). Each Bugzilla entry and email message should contain only one comment.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The following changes were made since the last public Working Draft:

Support for XML Schema 1.1 components has been added.

A proposal for schema component property accessors has been added.

The handling of default namespaces and namespace bindings has been clarified (issues #2661, #2662).

Numeric predicates have been clarified to reflect the intention that they may be dropped when they are redundant, not just because the value happens to be 1 (Issue #3677).

The definition of // has been modified slightly so that, for example, the path //foo can refer to the global element declaration named foo and not just to element declarations subordinate to some type ( Issue #3684).

Examples have been provided showing the use of schema component paths with namespace URIs (related to issue #2659).

The status of relative or incomplete schema component paths has been clarified (related to issue #2659).

Two small errors in the EBNF were fixed (issues #3681, #3682).

References to RFC2396 and RFC2396bis were updated to RFC3986 (issues #2658, #2659).

The wording in the conformance section has been clarified; a section on extensibility has been added ( issue #2660).

The document has been reorganized to take an axis-based approach. In addition, an appendix organized by axis rather than component type has been added (issue #3685).

Non-canonical axes have been added for attribute uses and particles (issue #3678).

Path abbreviations have been clarified (issue #3684).

The name of the element:: axis has been changed to schemaElement:: and the name of the attribute:: axis has been changed to schemaAttribute:: (issue #5330).

Missing content type traversals have been added.

Made many small editorial fixes have been made.

The syntax has been changed to use a style more similar to that of XPath ; individual steps use an axis specifier and a node test rather than just a node test. The path model was changed accordingly, to take into account an axis, and the syntax for some non-default traversals was changed to avoid ambiguities. As another consequence of these changes, the literal '0' was introduced to denote anonymous components.

A fixed namespace prefix was mandated for canonical schema component paths.

General wildcarding of steps was added. To make the syntax more parallel to that of XPath, '*' now means 'element::*', and the syntax for annotations has become 'annotation::*'.

To make the syntax more parallel with respect to both general wildcarding and the axis model, the syntax for facets is now of the form 'facets:minInclusive' and the syntax for model groups is now of the form 'model::choice'.

The '//' abbreviation has been restricted to default axes. The description of this abbreviation has been folded into the section on elided steps.

'~name' has been added as a short form for 'type::name'.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

English

Last Modified: $Date: 2008/09/09 18:00:42 $

Introduction (Non-Normative)

This document defines a system for designating XML Schema components. Part 1 of the W3C XML Schema Definition Language (XSD) recommendation defines these schema components. Section 2.2 lays out the inventory of schema components into three classes:

Primary components: simple and complex type definitions, attribute declarations, and element declarations

Secondary components: attribute and model group definitions, identity-constraint definitions, and notation declarations

"Helper" components: annotations, model groups, particles, wildcards, and attribute uses

In addition there is a master schema component, the schema component representing the schema as a whole. This component will be referred to as the schema description component in this specification.

Finally, there are schema components for the facets defined in Part 2 of the W3C XML Schema Definition Language (XSD) recommendation :

Fundamental Facets: ordered, bounded, cardinality, numeric

Constraining Facets: whiteSpace, minInclusive, maxInclusive, minExclusive, maxExclusive, totalDigits, fractionDigits, length, minLength, maxLength, pattern, enumeration

Version 1.1 of the W3C XML Schema Definition Language (XSD) recommendation adds additional components and makes modifications to existing components, as well as introducing the notion of "property records" to capture more complex structured values.

At first blush, a QName (prefix:localname) may seem sufficient to the task of designating any schema component. This is not the case for various reasons:

A QName is only meaningful in the context of particular namespace bindings so that the QName can be resolved to a particular &expanded-name;, i.e. a {namespace name, local name} pair.

The same &expanded-name; can be used in a particular schema to refer to an element declaration, an attribute declaration, a complex type or simple type definition, a model group definition, an attribute group definition, an identity constraint definition, and a notation declaration.

Locally scoped element and attribute declarations cannot necessarily be uniquely named by an &expanded-name;.

Anonymous type definitions have no &expanded-name;, or they have an &expanded-name; that may vary with the particular schema processor interpreting the schema.

Certain schema components (annotation, particle, wildcard) are invariably subordinate to some other schema component, and have no name of their own.

Certain schema components (attribute use and model group) are subordinate to some other schema component, and any name they might be construed to have is a reference to some other schema component (attribute declaration and model group definition, respectively).

The schema-as-a-whole description schema component has no name at all.

The redefinition schema composition feature creates the situation where there are two variants of the 'same' schema component, both with the same name, one of which is derived from the other. If it is necessary to be able to name the base component, the same name cannot be used for both.

A key technical challenge to obtaining a useful system of naming XML Schema components is to address these issues or decide that certain cases need not be addressed. In particular:

Designators must either include full &expanded-names;, or define namespace bindings.

Designators must distinguish named components in different symbol spaces from one another.

Designators must provide a means of distinguishing locally scoped element and attribute declarations with the same name.

Designators must provide for any designatable unnamed components, such as anonymous type definitions, wildcards, and the schema-as-a-whole description component.

Designators must function in the face of redefinitions.

The schema-as-a-whole description schema component may represent the amalgamation of several distinct schema documents, or none at all. It may be associated with any number of target namespaces, including none at all. It may have been obtained for a particular schema assessment episode by de-referencing URIs given in schemaLocation attributes, or by an association with the target namespace or by some other application-specific means. In short, there are substantial technical challenges to defining a reliable designator for the schema-as-a-whole description, particularly if that designator is expected to serve as a starting point for the other components encompassed by that schema.

This specification divides the problem of constructing schema component designators into two parts: defining a designator for an assembled schema, and defining a designator for a particular schema component or schema components, understood relative to a designated schema. The first task is discussed in , although this specification does not define a specific rule for how to construct a single URI for an assembled schema. The second task is addressed in detail in .

Goals and Use Cases (Non-Normative) Requirements Basic Functionality

Each component should have at least one unambiguous designator that designates that component and no other. However, certain abbreviation and wildcarding constructs may designate collections of components.

It should be possible to designate any schema component within a schema. However, some exceptions will be made for certain of the helper components.

Designators should provide (or assure) a URI for the unique identification of a schema.

If there is more than one designator for a construct, there should be exactly one canonical form of the designator.

Designators should be usable for either the XML Schema 1.0 or the XML Schema 1.1 component model

Properties of the Designator

Designators should be human-readable.

Given a designator, it should be possible to get the &expanded-name; for the designated component, if one exists for that component.

It should be possible to algorithmically and consistently generate the canonical designator for each component algorithmically and consistently, either against an assembled schema or as the schema is assembled.

Designators should be parsable with compositional semantics (or, in other words, they should have expressive notation).

There should be a formal specification of what constitutes a legal designator.

Compatibility

Designators should be URI references.

Designators should work well in a RDDL environment.

Non-goals

It is not a requirement to designate particle components as distinct from terms.

It is not a requirement to tie schema component validity to namespace validity.

It is not a requirement that it be possible to construct designators to refer to arbitrary schema components without any knowledge of schema internals.

It is not a requirement to be able to tell, from a schema component designator for an element declaration, whether instances of that element declaration must appear in document instances with qualified or unqualified names.

It is not a requirement that it be possible to uniquely assign schema component designators (element, attribute, and type designators) to information items in a document instance given only a set of schema component designators.

Use Cases Type references

In general Schema Component Designators can be used to provide references to arbitrary types, whether they are named global types or local or anonymous types. These use cases all benefit from being able to refer to any type declaration.

Describing the type of an expression, where the type might be an anonymous or local type and a QName is therefore inadequate. There are a number of examples where this could be valuable in type-aware languages that operate on schema-validated XML:

Naming the type of something that has been selected.

For use wherever types are named, for example to specify a type in a query expression.

Enabling interfaces like those described in to expose anonymous types.

Identifying types for casting, specifically wrt anonymous and local types.

Identifying types for function signatures.

Element declaration references

These use cases benefit from being able to refer to any element declaration.

Naming an element declaration which is matched by an arbitrary expression. e.g. Given XPath /one/two/foo, naming that it only matches local element 'foo'.

Referring to a local element declaration, with or without knowledge of the names of the scoping types and elements.

Stand-off schema annotation

Schema component designators can be used to refer to specific parts of a schema to provide an out-of-band annotation capability, for commentary, error reporting, or the association of layered semantics with schema components.

Writing error messages. There are two classes of error messages in view: errors in an instance and errors in the schema. For example, if an instance has a quantity which violates the constraints of a particular type, such as a range constraint, it is valuable for the error message to be able to name and refer to the specific type whose constraints were violated, even if that is the anonymous type of a local element declarationwith an anonymous types. An example of a schema error would be that one type is not a valid restriction of another type. This use case benefits from being able to name and refer to type, element, and attribute declarations, as well as element and attribute uses, groups, and possibly facets and particles. It is unclear whether being able to refer separately to particles versus groups is important. Being able to refer separately to attribute and element uses versus attribute and element declarations may be important.

Schema documentation. The transfer syntax for W3C XML Schema allows for documentation to be attached to components in-line. In many cases it may be preferable to keep the documentation separate from the active definitions, to save bandwidth, to provide for alternative documentation for different communities, and so on. Being able to refer to any schema component that can support an annotation (all but annotation itself) supports this use case.

Commentary on schemas, such as best practices documents, reviews and comparisons of particular schemas, and so on.

Associating an additional layer of semantics with schema components, for example, providing information to programming language or application environments to identify code to execute. For example, certain XML data binding frameworks today reference complex types and elements using their own path syntax for the purpose.

Miscellaneous text-based uses within schema-based tools

Having a simple textual way to refer to the abstract components of a schema enables certain kinds of text-based schema-related processing.

A tool that creates interlinked HTML pages describing a schema.

String-based tests of type equivalence. Such tests can be used for comparing serialized PSVIs to provide for interoperable tests of type equivalence and processor comparisons.

String-based comparisons of processors generally, making it possible, for example, to ask and answer the question "Did two validations of the same document on different machines use the same type for a given element?"

input/output

user reports

glue/interfaces among

Other

Simple selection queries, such as "the type that is the base type of X" without knowledge of its name.

Creation or initial drafting of a new schema or schema document by selecting components from existing schema.

RDF assertions about types, etc.

Using XSD simple types as the datatype of RDF literals.

Describing XSD Components within RDF, including the use of XSD simple types as RDF classes.

Formal description requires unique identifier for each declaration and definition component used within the context of the validation episode.

Enumerating dependencies among schema components. For example, where one complex type restricts another, the local elements in one depend on the local elements of the other.

Schema Component Designators

Schema component designators rely on a layered model of schema component reference. Schema component paths designate components in the context of a particular schema assembly and depend on a namespace binding context. Full blown schema designators consist of two parts: a URI without a fragment identifier part, which identifies the schema, and a fragment identifier which encapsulates a schema component path to designate a set of components in the context of that schema. Schema component paths may be used in contexts other than schema component designators, given appropriate specification of the namespace binding context and the target schema.

This section describes schema component designators as a whole. The details of schema component paths are described in .

A schema designator is a single URI for a resource representing an assembled schema.

Many possible conventions for obtaining a single URI to refer to a schema are possible. In the simplest case, where there is one root schema document, the URI of that document suffices. In other cases a schema may have been assembled from multiple schema documents, or from components obtained via other representations, and some representation of that collection or of the assembled results will be required.

We expect that it will be highly desirable for the community to evolve one convention for referring to an assembled schema to ensure consistency of global schema component designators. This specification declines to specify what that one way should be.

Like any resource, the schema denoted by a URI may be represented in a variety of forms, with different media types. When a URI is dereferenced, the form and resolution of any fragment identifier depend (as specified by ) on the media type of the representation obtained. The representation of a resource obtained by dereferencing a schema URI must therefore allow for the fragment identifier syntax defined here in order for schema component designators to successfully resolve to components. Whatever representation of a schema is used, the media type should allow for the fragment identifier syntax defined here. This will be true for any XML representation of the schema, since the XPointer framework is defined for all XML media types. Other media types must explicitly specify a compatible fragment identifier syntax. The representation of the resource either needs to be an XML encoding to fit with the XPointer framework , or its definition needs to explicitly entail a compatible fragment identifier syntax.

The schema component reference core defines reference to a schema component in the context of an assembled XML Schema. defines this relationship between an assemblage of schema components and component paths. Schema assembly is described in Section 4 of XML Schema Part 1: Structures.

For the purposes of component paths, a missing component (see Section 5.3 of XML Schema Part 1: Structures) cannot be used to construct a valid path; nor can a schema component be successfully referenced through a path that references a missing component.

An absolute schema component designator identifies a particular schema component; it consists of two parts: a designator for the assembled schema (a schema designator), and a designator for a particular schema component or schema components relative (a relative schema component designator) to that assembled schema.

Syntactically, the first part is a URI without a fragment identifier, and the second part is an XPointer fragment identifier. An absolute schema component designator therefore is a URI reference. For example: http://example.org/schemas/po.xsd#xscd(/type::purchaseOrderType)

Note that a schema component designator may contain Unicode characters that are not allowed in URIs. Any such characters must be encoded and escaped to obtain a URI suitable for retrieval, if retrieval is required.

A relative schema component designator identifies a particular schema component relative to some current assembled schema; it is expressed as an XPointer scheme xscd() that uses a schema component path as the scheme data. This XPointer scheme may be used in combination with the XPointer xmlns() scheme . It must not beis not designed to be used in combination with other XPointer schemes. The construction and syntax of schema component paths are described in .

Schema Component Designator Syntax EBNF SchemaComponentDesignator AbsoluteSchemaComponentDesignator | RelativeSchemaComponentDesignator AbsoluteSchemaComponentDesignator SchemaDesignator '#' RelativeSchemaComponentDesignator SchemaDesignator URI RelativeSchemaComponentDesignator XmlnsPointerPart* XscdPointerPart XmlnsPointerPart 'xmlns' '(' XmlnsSchemeData ')' XscdPointerPart 'xscd' '(' SchemaComponentPath ')' Canonical Schema Component Designators

A canonical schema component designator is an absolute schema component designator that is a URI that has been normalized according to the rules given in the update to RFC2396 RFC 3986 and where the relative schema component designator consists of an xmlns XPointer pointer part (if required) followed by a canonicalized xscd XPointer pointer part.

A canonicalized xscd XPointer pointer part is an xscd XPointer pointer part whose pointer data is a canonical schema component path.

Equality of Schema Component Designators

Many use cases for schema component designators call for them to be compared for equality. A simple string comparison cannot be used may fail to correctly recognize equivalent designators with this scheme because namespace prefixes may vary. However, comparison is still straightforward.

Two schema component designators are equal if they are absolute and their URIs are equal or if they are relative to the same schema, and their schema component paths are equal.

Schema Component Paths

An assembled schema forms a rooted graph of schema components and property records, where certain schema component and property record properties contain other schema components and property records as their values (or part of their values). The graph arcs are directed and labelled. The graph may have cycles in it. Schema component paths can be regarded as being constructed step-by-step by traversing the schema component properties, starting at the schema-as-a-whole description schema component. Within this graph there may be more than one path to a particular schema component. This section describes the general procedure for traversing the graph and constructing paths how paths are interpreted, and then defines which paths are the canonical ones.

For the purposes of schema component paths, presume the existence of an {identity constraint definitions} property of the schema-as-a-whole description component whose value is the union of all identity constraint components in the assembled schema. Future revisions of the XML Schema specification may define this property. The XML Schema 1.1 specification defines this property.

A schema component path identifies a particular schema component in the context of an assembled schema; it is a series of [step] pieces, each of which corresponds to a particular schema component along the path from the schema-as-a-whole schema component. Each step has a concrete syntactic representation, which is described in .

A [step] identifies a schema component along the path from the schema-as-a-whole schema component. Each [step] has a possibly empty [target namespace], a possibly empty [name], and possible empty [predicate], a [schema component kind], and an [axis]. The values for these properties are defined for specific schema components, below, but in general the [target namespace] will have the same value as the {target namespace} property of the schema component and the [name] will have the value as the {name} property of the schema component. The value of [schema component kind] is a label for the kind of schema component involved and the value of [axis] is a label for the component property leading to the component. The [predicate] is used to select schema components that have no name to distinguish them or where the name does not suffice to distinguish them, such as instances of element declarations within a term.

Schema Component Graph Traversal

An assembled schema consists of a graph of schema components. Schema property records and helper components are included in the graph, but a schema component path never refers to them. Traversal in the graph passes through property records. The following schema component properties have as their values (or a part of their values) other schema components, thus creating the links in the graph which may be traversed to construct a schema component path. A schema component property that has other schema components as its value or as part of its value creates links in the graph which may be traversed through one of the defined axes to construct a schema component path.

Traversal through the schema component graph occurs through any of the properties by taking a member of one of these lists as the basis for the next step:

{type definitions} {attribute declarations} {element declarations} {attribute group definitions} {model group definitions} {notation declarations} {identity constraint definitions} {facets} {fundamental facets} {member type definitions} {attribute uses} {particles} (particle axis) {substitution group affiliations} {assertions} {alternatives} {annotations} (1.1 only)

Traversal through the schema component graph occurs through any of the following properties by taking that schema component as the basis for the next step.

{type definition} {item type definition} {attribute wildcard} {model group} {attribute declaration} {term} {base type definition} {primitive type definition} {substitution group affiliation} {referenced key} {parent} {simple type definition} {wildcard}

Traversal through the schema component graph occurs through any of the following properties by taking one of that property record's properties as the basis for the next step.

{type table} {scope} {context} {content type} {open content}

Traversal through the schema component graph occurs to the following properties, but in a somewhat special way, as referring to a collection of annotations as a group in the 1.0 component model, rather than to an individual annotation component. This is because there are no component properties that can be used to distinguish between individual annotations in the 1.0 component model.

{annotations} {annotation}

Traversal through the schema component graph occurs through the following properties, but in different ways depending on what kind of value it has:

{content type} {scope} {value}

Traversal will proceed through the particle of the {content type} property if a content model is present, or through the {content type} property directly if it is a simple type definition. Traversal will proceed through the {scope} property unless it has the value "global". Traversal will proceed through the {value} property if it is a sequence of assertion components (otherwise not).

A traversal from one component to another takes place across some particular component property. This property is the arc of traversal.

A default arc is a privileged arc of traversal. The default arcs are:

{type definition} {content type} {particle} {simple type definition} {attribute declaration} {attribute uses} {model group} {particles} {term} {element declarations} {facets}

includes a summary of which arcs act as defaults and when.

Schema Component Path Syntax

In general the syntax of a step of the schema component path has the following form:

[schema component kind | axis]::[ns-prefix:][name][[predicate]]

where ns-prefix is bound to the [target namespace] of the component and will be absent (along with the colon) if there is no target namespace. In the context of schema component designators the namespace prefixes will be bound via the xmlns XPointer scheme; in the context of an XML document the namespace prefixes will be bound in the conventional way (using the [in-scope namespaces] property of the element information item); other host languages and some XML applications will define their own namespace binding rules.

Non-default axes may use the axis name instead of the schema component kind, in order to disambiguate the traversal.

The syntax provides various abbreviations as defined below.

Each kind of step accepts a wildcarding construct, which uses the special literal * instead of the name and has the form:

[schema component kind | axis]::*

A wildcarded step has the properties:

[target namespace]
[name]	*
[schema component kind]	See various component steps
[axis]	See various component steps
[predicate]

Such a step refers to the set of all successor components of the given kind. Implementations will have to exercise care to properly handle circularities in the component graph in determining the set of components matched by a path.

A step involving an anonymous component uses the name 0:

[schema component kind]::0

This name cannot have any conflict with any possible named component, as 0 is not a valid name start character.

Steps in the path are separated by a slash:

/

except in the case of the schema-as-a-whole component, which is represented by a bare slash already, so no additional separator is necessary.

Schema-as-a-whole Component

The [step] for the schema-as-a-whole schema component has the properties:

[target namespace]
[name]
[schema component kind]	`schema`
[axis]
[predicate]

/ Attribute Declaration

The [step] for an attribute declaration schema component has the properties:

[target namespace]	Value of {target namespace}
[name]	Value of {name}
[schema component kind]	`attribute`
[axis]	`attribute` `declaration` or `context`
[predicate]

If [axis] is context then context::prefix:name

Otherwise schemaAttribute::prefix:name or @prefix:name

Element Declaration

The [step] for an element declaration schema component has the properties:

[target namespace]	Value of {target namespace}
[name]	Value of {name}
[schema component kind]	`schemaElement`
[axis]	`element` `declaration`, `term`, `substitution` `group` `affiliation`, or `context`
[predicate]	None if the [axis] is `substitution` `group` `affiliation` or `context` or if the {scope} is `global`. Otherwise, the pair `{position, n}` where `n` is the position of the element declaration among other element declarations with the same {target namespace} and {name} property values among the {particles} in the superordinate model group.

If [axis] is substitution group affiliation then substitutionGroup::prefix:name

If [axis] is context then context::prefix:name

Otherwise schemaElement::prefix:name[n] or prefix:name[n] where the [n] will be absent if the {scope} of the element declaration is global and may be absent if there is only one element declaration with the given {target namespace} and {name} property among the {particles} of the superordinate model group. In this case the value of n iswould be 1.

Simple Type Definition

The [step] for a simple type definition schema component has the properties:

[target namespace]	Value of {target namespace}
[name]	Value of {name}
[schema component kind]	`simpleType`
[axis]	`type` `definition`, `base` `type` `definition`, `member` `type` `definition`, `item` `type` `definition`, `primitive` `type` `definition`, `content` `type`, `simple type definition`, `scope`, or `context`
[predicate]	If the [axis] is `member` `type` `definition`, the pair {position, `n`} where `n` is the position of this simple type definition among the current component's {member type definitions}. Otherwise, none.

If [axis] is base type definition then baseType::prefix:name

If [axis] is primitive type definition then primitiveType::prefix:name

If [axis] is member type definition then memberType::prefix:name[n]

If [axis] is item type definition then itemType::prefix:name

If [axis] is scope then scope::prefix:name

If [axis] is context then context::prefix:name

Otherwise type::prefix:name or ~prefix:name

prefix:name will be 0 for anonymous types. The [n] may be absent if there is only one member type among the simple type definitions's {member type definitions}. In this case the value of n is would be 1. Complex Type Definition

The [step] for a complex type definition schema component has the properties:

[target namespace]	Value of {target namespace}
[name]	Value of {name}
[schema component kind]	`complexType`
[axis]	`type` `definition`, `content` `type`, `base` `type` `definition`, `scope`, or `context`
[predicate]

If [axis] is scope then scope::prefix:name

If [axis] is context then context::prefix:name

If [axis] is base type definition then baseType::prefix:name

Otherwise type::prefix:name or ~prefix:name

prefix:name will be 0 for anonymous types. Attribute Group Definition

The [step] for an attribute group definition schema component has the properties:

[target namespace]	Value of {target namespace}
[name]	Value of {name}
[schema component kind]	`attributeGroup`
[axis]	`attribute` `group` `definition` or `scope`
[predicate]

If [axis] is scope then scope::prefix::name

Otherwise attributeGroup::prefix:name

Model Group Definition

The [step] for a model group definition schema component has the properties:

[target namespace]	Value of {target namespace}
[name]	Value of {name}
[schema component kind]	`group`
[axis]	`model` `group` `definition` or `scope`
[predicate]

If [axis] is scope then scope::prefix:name

Otherwise group::prefix:name

Identity-constraint definition

The [step] for an identity-constraint definition schema component has the properties:

[target namespace]	Value of {target namespace}
[name]	Value of {name}
[schema component kind]	`identityConstraint`
[axis]	`identity` `constraint` `definition` or `referenced` `key`
[predicate]

If [axis] is referenced key then key::prefix:name

Otherwise identityConstraint::prefix:name

Notation declaration

The [step] for a notation declaration schema component has the properties:

[target namespace]	Value of {target namespace}
[name]	Value of {name}
[schema component kind]	`notation`
[axis]	`notation` `declaration`
[predicate]

notation::prefix:name Annotations

Annotation components are referenced as a collection. If the [step] derives from an {annotations} property, the collection is the collection of all the annotations given in that property. If the [step] derives from an {annotation} property, the collection is the collection with just that annotation in it.

The [step] for an annotation schema component has the properties:

[target namespace]
[name]	*
[schema component kind]	`annotations`
[axis]	`annotation`
[predicate]

annotation::*

Annotations cannot be individually addressed: they can only be accessed through wildcarding. Annotation components therefore do not have individually distinguishable canonical schema component paths or designators.

Model Group

The [step] for a model group schema component has the properties:

[target namespace]
[name]
[schema component kind]	The value of the {compositor} property, one of `sequence`, `choice`, or `all`
[axis]	`model` `group` or `term`
[predicate]	The pair `{position, n}` where `n` is the position of the model group with respect to other model groups among {particles} with the same {compositor} property value if this model group is one particle of a superordinate model group.

model::sequence[n] or model::choice[n] or model::all[n] where the [n] may be absent if there is only one model group with the same {compositor} property among the {particles} of the superordinate model group. In this case the value of n iswould be 1 (as it always is for the all compositor). Particle

Particle schema components are skipped over in the traversal through the graph, do not contribute a step, and have no reflection in the path syntax.

Wildcard

The [step] for a wildcard schema component has the properties:

[target namespace]
[name]
[schema component kind]	If the wildcard is the {term} of some particle, then `any`, otherwise `anyAttribute`
[axis]	`term` or `attribute wildcard`
[predicate]	If the [schema component kind] is `any`, the pair `{position, n}` where `n` is the position of the wildcard with respect to other wildcards among {particles} of the superordinate model group.

any::*[n] or anyAttribute::* where the [n] may be absent if there is only one wildcard among the {particles} of the superordinate model group. In this case the value of n iswould be 1. Attribute Use

Attribute use schema components are skipped over in the traversal through the graph, do not contribute a step, and have no reflection in the path syntax.

The EBNF above defines a syntax for invoking an accessor after the last step of the path and for using extension axes. This syntax is included for extensibility. A specification that wishes to make use of these extensions must define the detailed syntax and semantics (see ).

Examples of Schema Component Paths (Non-Normative)

The following examples assume the namespace prefixes have been properly bound.

A schema component path referring to the type (either simple or complex) whose local name is title and which is in the namespace denoted by the prefix my:

/type::my:title

A schema component path referring to the globally declared element whose local name is title and which is in the namespace denoted by the prefix my:

/schemaElement::my:title

A schema component path referring to the globally declared attribute whose local name is title and which is in the namespace denoted by the prefix my:

/schemaAttribute::my:title

A schema component path referring to the globally declared attribute group whose local name is title and which is in the namespace denoted by the prefix my:

/attributeGroup::my:title

A schema component path referring to the pattern facet of the globally declared simple type whose local name is title which is in the namespace denoted by my:

/type::my:title/facet::pattern

Given this schema fragment for a schema whose target namespace is denoted by the prefix my:

<xs:complexType name="articleType"> <xs:sequence> <xs:element ref="my:section"/> <xs:element name="appendix" type="my:sectionType"/> </xs:sequence> </xs:complexType> <xs:element name="chapter"> <xs:complexType> <xs:sequence> <xs:element ref="my:title" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:string"/> <xs:anyAttribute namespace="##other" use="optional"/> </xs:complexType> </xs:element>

The following schema component path refers to the first element of the named complex type:

/type::my:articleType/model::sequence/schemaElement::my:section

And the following schema component path refers to the second:

/type::my:articleType/model::sequence/schemaElement::my:appendix

A schema component path referring to the (anonymous) complex type of the globally defined element:

/schemaElement::my:chapter/type::0

A schema component path that refers to the wildcard in the globally defined element:

/schemaElement::my:chapter/type::0/model::sequence/any::*

A schema component path that refers to the attribute of the globally defined element:

/schemaElement::my:chapter/type::0/schemaAttribute::name Path Abbreviations

An intermediate step is a [step] piece that is neither the first step nor the last step in a schema component path. Head steps are a series of steps in a schema component path, beginning with the first step and ending with any step that is not the last step in a schema component path.

The following three types of intermediate step sequences are optional in the schema component path syntax:

An intermediate step that corresponds to a complex type component that was reached via a default axis.

A series of intermediate steps corresponding to model group components, that is, model::sequence, model::choice, model::all, or model::* steps. This series begins and ends with a model group step and contains all the consecutive model group steps to the end of the series.

A combination of the above two intermediate step sequences in that order.

The syntax // or component::* can be used to abbreviate head steps or a sequence of intermediate steps in a schema component path, provided that all those steps corrrespond to default axes , or to abbreviate the first head step for any axis on the schema-as-a-whole component. Only the very first head step from the schema-as-a-whole component may be elided for non-default axes; only steps corresponding to default axes are candidates for elision otherwise.

Paths with elided steps or // separators will designate sets of components: the set of all components that can be reached by such a path. Implementations constructing such sets will need to take care to correctly handle circularity in the component graph.

Examples of Abbreviations and Optional Intermediate Steps (Non-Normative)

The following examples assume that the namespace prefixes r and ipo are appropriately bound.

Here is a path that designates an attribute declaration whose local name is period in the namespace denoted by r in an anonymous complex type:

/r:purchaseReport/type::0/@period

Omitting its optional intermediate step sequence, this path reduces to:

/r:purchaseReport/@period

Here is a path that designates an attribute declaration whose local name is name in the namespace denoted by ipo in a globally defined type:

/type::ipo:USAddress/model::sequence/model::sequence[1]/name

Omitting its optional intermediate step sequence, this path reduces to:

/type::ipo:USAddress/name

This path designates an element declaration whose local name is regions in the namespace denoted by r in an anonymous complex type:

/r:purchaseReport/type::0/model::sequence/r:regions

Omitting its optional intermediate step sequence, this path reduces to:

/r:purchaseReport/r:regions

This path designates global or local element declarations whose local name is quantity in the namespace denoted by r:

//r:quantity

This path designates global or local element declarations whose local name is quantity in the namespace denoted by r, where these declarations are in the subgraph represented by the global complex type component whose local name is Items in the namespace denoted by r:

/~r:Items//r:quantity

This path designates global or local attribute declarations whose local name is partNum in the namespace denoted by r where these declarations are in the subgraph represented by the global complex type component whose local name is Items in the namespace denoted by r:

/~r:Items//@partNum

This extended example works against the following schema fragment for a schema with no target namespace:

<xs:element name="example" type="aType"/> <xs:complexType name="aType"> <xs:sequence> <xs:element name="foo"/> <xs:group ref="aGroup"/> </xs:sequence> </xs:complexType> <xs:group name="aGroup"> <xs:sequence> <xs:element name="bar"> <xs:complexType> <xs:sequence> <xs:element ref="foo"/> <xs:element ref="a"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:group> <xs:element name="foo"/>

Which paths may be elided to //foo?

Unelided path	Elidable to `//foo`?
`/group::aGroup/model::sequence/bar/~0/model::sequence/foo`	No: `bar` is not an elidable step
`/~aType/model::sequence/foo`	Yes
`/~aType/model::sequence/model::sequence/bar/~0/foo`	No: `bar` is not an elidable step
`/root/~aType/model::sequence/foo`	Yes
`/root/~aType/model::sequence/model::sequence/bar/~0/foo`	No: `bar` is not an elidable step

Interpretation of Schema Component Paths

A schema component path selects a sequence of schema components in the context of an assembled schema; it is a series of steps separated by '/' or '//'. Complete schema component paths always start with either '/' or '//'.

A step consists of a schema component axis and a schema component name test and an optional positional predicate. It selects a sequence of schema components that are linked to a source component through an arc that matches the axis, pass the name test, and are selected by the positional predicate, if any. Schema component axes are described in .

In general the syntax of a step of the schema component path has the following form:

axis::nametest[predicate]

The predicate is optional and there are abbreviated forms for some steps.

A schema component name test is a condition on name of the components selected by the schema component path step. A schema component name test either gives a localname, possibly with a namespace prefix, or consists of a just the wildcard character ('*'), or just the character zero ('0').

prefix:localname or localname

A schema component name test of this form is true if the QName formed from the namespace name and local name specified in the the schema component name test is equal to the value of the component-name() accessor of the schema component. For more information on namespace binding for QName interpretation see .

0

A schema component name test of this form is true for anonymous type definitions. An anonymous type definition's component-name() accessor returns "0". This name cannot have any conflict with any possible named component, as 0 is not a valid name start character.

*

A schema component name test of this form is true for all linked components matching the given axis.

A schema component positional predicate is a condition on the relative position of the component in the sequence of matching components from the schema component path step. A schema component position predicate is true if the position of the target component in the sequence of components selected by the axis and name test is equal to the positive integer given in the predicate.

n

A path consisting of just '/' selects the schema-as-a-whole description component.

A path of the form /S1 selects components linked to the schema-as-a-whole description component in accordance with the step S1.

A path of the form S1/S2 is interpreted by gathering the sequence of source components and then selecting any schema component that is linked to one of the source components in accordance with the step S2. The sequence of source components consists of the sequence of components selected by S1 followed by the components selected by the elided-component axis on those components.

A path of the form S1//S2 is also interpreted by gathering the sequence of source components and then selecting any schema component that is linked to one of the source components in accordance with the step S2. In this case the sequence of source components consists of the sequence of components selected by S1 followed by the application of the component axis on members of that sequence.

A path of the form S1 selects all schema components linked to the initial source component in accordance with the step S1.

Implementations will have to exercise care to properly handle circularities in the component graph in determining the set of components matched by a path.

Incomplete Schema Component Paths

Incomplete schema component paths may be constructed starting at some specific source component following the construction rules given here. Such paths will not start with a leading slash. Correct interpretation of such incomplete (relative) paths depends on the initial source component. External specifications sanctioning relative schema component paths must therefore define the initial source component to use to interpret the schema component path. In this specification, "schema component path" always refers to a complete schema component path starting at the root schema-as-a-whole description component, unless explicitly stated otherwise.

To emphasize the incompleteness of such paths, the current component step syntax may be used (.) for the head step. For example, if the initial source component is a complex type, the following paths are equivalent and designate the element declaration with the QName my:section within the sequence model group of that type:

model::sequence/schemaElement::my:section ./model::sequence/schemaElement::my:section Namespaces

Schema component paths use QNames to refer to schema components. Interpretation of these QNames therefore depends on namespace bindings. When schema component paths are used in the context of schema component designators (), the xmlns() XPointer scheme defines those namespace bindings. In the context of an XML document the namespace prefixes will be bound in the conventional way (using the [in-scope namespaces] property of the element information item). Other host languages and some XML applications will define their own namespace binding rules. While the xmlns() scheme does not provide for defining a default namespace, other mechanisms may do so. In such contexts, schema component paths allow and apply the default namespace.

Note also that the form (and elementFormDefault and attributeFormDefault) values apply as well. Since, for example, a local attribute declaration component with the form unqualified will have an empty {target namespace}, the QName for that declaration will have no prefix.

For example, consider the path:

//quantity

This path designates global or local element declarations whose local name is quantity and which are either in no namespace, are local elements whose form is unqualified, or are in the default namespace (assuming there is a such a namespace binding).

For types, form is not relevant.

/~Items//quantity

This path designates global or local element declarations whose local name is quantity, where these declarations are in the subgraph represented by the global complex type component whose local name is Items. As in the previous example, the element declaration may either be in schema with no target namespace, in the default namespace, or a local element declaration with the form unqualified. The complex type Items must be in the default namespace or in a schema with no target namespace.

This path designates global or local attribute declarations whose local name is partNum where these declarations are in the subgraph represented by the global complex type component whose local name is Items. Again, the complex type is either in the default namespace or in a schema with no target namespace, and the attribute declaration must be global attributes in a schema with no target namespace, in the default namespace, or be local declarations with the form unqualified.

/~Items//@partNum Schema Component Path Axes

A schema component path axis contains specific components linked to the current context component through certain kinds of arcs. Unless otherwise indicated, an axis applied to a component that has no arc of the required kind designates no components.

The currentComponent Axis

The currentComponent axis contains the current component.

CurrentComponentAxis'currentComponent' ':: The annotation Axis

The annotation axis contains annotation components linked to the current component through {annotation} or {annotations} arcs, which are the components returned by the annotations() accessor.

AnnotationAxis'annotation' '::' The schemaAttribute Axis

The schemaAttribute axis contains attribute declaration components linked to the current component through {attribute declaration} or {attribute declarations} arcs, which are those components returned by the component-linked() accessor whose component-kind() is equal to "attribute-declaration".

SchemaAttributeAxis'schemaAttribute' '::' The schemaElement Axis

The schemaElement axis contains element declaration components linked to the current component through {element declarations}, {term}, {particle}, {particles}, or {content type}, which are the components returned by the term() accessor whose component-kind() is equal to "element-declaration", together with {element declarations}.

SchemaElementAxis'schemaElement' '::' The type Axis

The type axis contains simple type definition and complex type definition components linked to the current component through {type definition}, {type definitions}, {content type}, or {simple type definition} arcs, which are the components returned by the component-children() accessor whose component-kind() is equal to either "complex-type-definition" or "simple-type-definition".

TypeAxis'type' '::' The attributeGroup Axis

The attributeGroup axis contains attribute group definition components linked to the current component through {attribute group definitions} arcs, which are those components returned by the component-linked() accessor whose component-kind() is equal to "attribute-group-definition".

AttributeGroupAxis'attributeGroup' '::' The group Axis

The group axis contains model group definition components linked to the current component through {model group definitions} arcs, which are those components returned by the component-linked() accessor whose component-kind() is equal to "model-group-definition".

GroupAxis'group' '::' The identityConstraint Axis

The identityConstraint axis contains identity constraint definition components linked to the current component through {identity constraint definitions} arcs, which are those components returned by the component-linked() accessor whose component-kind() is equal to "identity-constraint-definition".

IdentityConstraintAxis'identityConstraint' '::' The assertion Axis

The assertion axis contains assertion components linked to the current component through {assertions}, {value}, or {facets} arcs, which are those components returned by the assertions() accessor.

AssertionAxis'assertion' '::' The alternative Axis

The alternative axis contains type alternative components linked to the current component through {alternatives}, {default type definition}, or {type table} arcs, which are those components returned by the component-linked() accessor whose component-kind() is equal to "type-alternative".

The {default type definition} of the type alternatives table of an element declaration is actually a type alternative component and will be selected by the alternative axis.

AlternativeAxis'alternative' '::' The notation Axis

The notation axis contains notation declaration components linked to the current component through {notation declarations} arcs, which are the components returned by the component-linked() accessor whose component-kind() is equal to "notation-declaration".

NotationAxis'notation' '::' The model Axis

The model axis contains model group components linked to the current component through {model group}, {term}, {particle}, {particles}, or {content type} arcs, which are the components returned by the term() accessor whose component-kind() is equal to "model-group".

ModelAxis'model' '::' The anyAttribute Axis

The anyAttribute axis contains wildcard components linked to the current component through {attribute wildcard} arcs.

AnyAttributeAxis'anyAttribute' '::' The any Axis

The any axis contains wildcard components linked to the current component through {wildcard}, {term}, {particle}, {particles}, {content type}, or {open content} arcs, which is the components returned by the term() accessor whose component-kind() is equal to "wildcard".

AnyAxis'any' '::' The scope Axis

The scope axis contains complex type definition, attribute group definition, or model group definition components linked to the current component through {scope} and {parent} arcs, which are the components returned from the component-scope() accessor.

ScopeAxis'scope' '::' The context Axis

The context axis contains complex type definition, attribute declaration, or element declaration components linked to the current component through {context} arcs.

ContextAxis'context' '::' The substitutionGroup Axis

The substitutionGroup axis contains element declaration components linked to the current component through {substitution group affiliation} and {substitution group affiliations} arcs.

SubstitutionGroupAxis'substitutionGroup' '::' The baseType Axis

The baseType axis contains simple type definition and complex type definition components linked to the current component through {base type definition} arcs.

BaseTypeAxis'baseType' '::' The itemType Axis

The itemType axis contains simple type definition components linked to the current component through {item type definition} arcs.

ItemTypeAxis'itemType' '::' The memberType Axis

The memberType axis contains simple type definition components linked to the current component through {member type definitions} arcs.

MemberTypeAxis'memberType' '::' The primitiveType Axis

The primitiveType axis contains simple type definition components linked to the current component through {primitive type definition} arcs.

PrimitiveTypeAxis'primitiveType' '::' The key Axis

The key axis contains identity constraint definition components linked to the current component through {referenced key} arcs.

KeyAxis'key' '::' The attributeUse Axis

The attributeUse axis contains attribute use components linked to the current component through {attribute uses}.

AttributeUseAxis'attributeUse' ':: The particle Axis

The particle axis contains particle components linked to the current component through {particles}.

ParticleAxis'particle' ':: The component Axis

The component axis contains the transitive closure of schema components that are either linked to the schema-as-a-whole description component or that are linked to current component through default arcs. That is, it contains the transitive closure of the component-children() accessor, as well as component-linked() accessor if the schema-as-a-whole description is the current component.

ComponentAxis'component' '::' The elided-component Axis

The elided-component axis contains complex type definitions linked to the current component through the {type definition} arc and the transitive closure of all model group components linked to the current component. That is, it contains the transitive closure of components returned from the term() accessor whose component-kind() is equal to "model-group", as well as components linked to the current component through the {type definition} arc.

There is no syntax for this axis: it is used to define the semantics of certain paths.

Accessors

A set of accessors is defined on schema components. For consistency, each accessor is defined for every kind of schema component, although several accessors return a constant empty value on some kinds of schema components.

Where accessors return sequences, the order of components accessed on one arc is as defined by the schema component model. Components accessed through default arcs precede components accessed through non-default arcs. Components are otherwise ordered as if arcs were accessed in the following order:

{type definitions}

{type definition}

{base type definition}

{item type definition}

{member type definitions}

{primitive type definition}

{type table}

{alternatives}

{default type definition}

{simple type definition}

{element declarations}

{substitution group affiliations}

{substitution group affiliation}

{attribute declarations}

{attribute declaration}

{model group definitions}

{attribute group definitions}

{scope}

{parent}

{context}

{content type}

{particles}

{particle}

{term}

{model group}

{attribute uses}

{open content}

{wildcard}

{attribute wildcard}

{identity constraint definitions}

{referenced key}

{assertions}

{notation declarations}

{facets}

{fundamental facets}

{annotation}

{annotations}

component-kind Accessor

The component-kind accessor returns a string identifying the kind of the schema component.

Component	Result of component-kind()
Attribute Declaration	"attribute-declaration"
Element Declaration	"element-declaration"
Complex Type Definition	"complex-type-definition"
Attribute Use	"attribute-use"
Attribute Group Definition	"attribute-group-definition"
Model Group Definition	"model-group-definition"
Model Group	"model-group"
Particle	"particle"
Wildcard	"wildcard"
Identity‑Constraint Definition	"identity-constraint-definition"
Type Alternative	"type-alternative"
Assertion	"assertion"
Notation Declaration	"notation-declaration"
Annotation	"annotation"
Schema	"schema"
Simple Type Definition	"simple-type-definition"
Constraining Facet	"facet"
Fundamental Facet	"facet"

component-name Accessor

The component-name accessor returns zero or one xs:QName values giving the name of the component.

Component	Result of component-name()
Attribute Declaration	the xs:QName formed from the {name} and {target namespace} properties
Element Declaration	the xs:QName formed from the {name} and {target namespace} properties
Complex Type Definition	the xs:QName formed from the {name} and {target namespace} properties; "0", if {name} is absent
Attribute Use	empty
Attribute Group Definition	the xs:QName formed from the {name} and {target namespace} properties
Model Group Definition	the xs:QName formed from the {name} and {target namespace} properties
Model Group	the xs:QName formed from an empty namespace name and the value of the component-variety() accessor as the local name
Particle	empty
Wildcard	empty
Identity‑Constraint Definition	the xs:QName formed from the {name} and {target namespace} properties
Assertion	empty
Type Alternative	empty
Notation Declaration	empty
Annotation	empty
Schema	empty
Simple Type Definition	the xs:QName formed from the {name} and {target namespace} properties; "0", if {name} is absent
Constraining Facet	the xs:QName formed with an empty namespace name and the value of the component-variety() accessor as the local name
Fundamental Facet	the xs:QName formed with an empty namespace name and the value of the component-variety() accessor as the local name

component-variety Accessor

The component-variety accessor returns zero or one strings identifying the specific variety of that component kind.

Component	Result of component-variety()
Attribute Declaration	"global" if {scope} is "global" or if the value of the {variety} property of {scope} is "global" (1.1); "local" otherwise
Element Declaration	"global" if {scope} is "global" or if the value of the {variety} property of {scope} is "global" (1.1); "local" otherwise
Complex Type Definition	the value of the {variety} property of the {content type} (1.1). Under the XML Schema 1.0 component model, there is no such property; instead returns "empty" if the {content type} property has the value "empty", "simple" if the {content type} property has a simple type declaration as its value, "element-only" or "mixed" if the {content type} has a pair as a value and that string is a member of the pair
Attribute Use	empty
Attribute Group Definition	empty
Model Group Definition	empty
Model Group	the value of the {compositor} property, one of "sequence", "choice", and "all"
Particle	empty
Wildcard	the value of the {process contents} property, one of "strict", "lax", and "skip"
Identity‑Constraint Definition	the value of the {identity-constraint category} property, one of "key", "keyref", and "unique"
Type Alternative	empty
Assertion	empty
Notation Declaration	empty
Annotation	empty
Schema	empty
Simple Type Definition	the value of the {variety} property, one of "atomic", "union", and "list"
Constraining Facet	the facet variety, e.g. "minLength" for the minLength facet, and so on
Fundamental Facet	the facet variety, e.g. "numeric" for the numeric facet, and so on

component-children Accessor

The component-children accessor returns a sequence of schema components consisting of all the components immediately accessible through default axes, skipping minor components that produce no steps in the schema component path.

Component	Result of component-children()
Attribute Declaration	the value of {type definition}
Element Declaration	the value of {type definition}
Complex Type Definition	the value of {attribute uses} and; if the value of the component-variety() accessor is "empty" then empty, if the value of the component-variety() accessor is "simple" then the value of {simple type definition} (1.1) or the value of {content type} (1.0); otherwise the value of the term() accessor
Attribute Use	the value of {attribute declaration}
Attribute Group Definition	the value {attribute declaration} for each Attribute Use in {attribute uses}
Model Group Definition	the value of {model group}
Model Group	the value of the {term} of each Particle in {particles}
Particle	the value of {term}
Wildcard	empty
Identity‑Constraint Definition	empty
Type Alternative	the value of {type definition}
Assertion	empty
Notation Declaration	empty
Annotation	empty
Schema	the value of {element declarations}
Simple Type Definition	the value of {facets}
Constraining Facet	empty
Fundamental Facet	empty

component-linked Accessor

The component-linked accessor returns a sequence of schema components immediately accessible using any axis, skipping minor components that produce no steps in the schema component path.

Component	Result of component-linked()
Attribute Declaration	the value of the component-children() and annotations() accessors, together with the {scope} (1.0) or the {parent} of {scope} (1.1)
Element Declaration	the value of the component-children() and annotations() accessors, together with the value of {scope} and {substitution group affiliation} (1.0) or the value of {substitution group affiliations}, the value of the {parent} of {scope}, the value of the {alternatives} and {default type definition} of {type table} (1.1), along with the value of {identity constraint definitions}
Complex Type Definition	the value of component-children() and annotations() accessors, together with the value of {base type definition}, {context}, {attribute wildcard}, and {assertions} and the value of {wildcard} of {open content} of {content type}
Attribute Use	the value of the component-children() and annotations() accessors
Attribute Group Definition	the value of the component-children() and annotations() accessors, as well as the value of {attribute wildcard}
Model Group Definition	the value of the component-children() and annotations() accessors
Model Group	the value of the component-children() and annotations() accessors
Particle	the value of the component-children() accessor
Wildcard	the value of the annotations() accessor
Identity‑Constraint Definition	the value of the annotations() accessor, together with the value of {referenced key}
Type Alternative	the value of the component-childrenl() and annotations() accessors
Assertion	the value of the annotations() accessor
Notation Declaration	the value of the annotations() accessor
Annotation	empty
Schema	the value of the component-children() and annotations() accessors, as well as the value of {type definitions}, {attribute declarations}, {attribute group definitions}, {model group definitions}, {notation declarations}, and {identity-constraint definitions}
Simple Type Definition	the value of the component-children() and annotations() accessors, together with the value of {context}, {base type definition}, {fundamental facets}, {primitive type definition}, {item type definition}, and {member type definitions}
Constraining Facet	the value of the annotations() accessor, together with the value of {value} in the case that the facet is the "assertions" facet
Fundamental Facet	empty

term Accessor

The term accessor returns term components linked through the {model group} or {term} arcs, possibly via {particle}, {particles}, or {content type} arcs.

Component	Result of term()
Attribute Declaration	empty
Element Declaration	empty
Complex Type Definition	the value of {term} of {particle} of {content type} (1.1) or the value of {term} of {content type} (1.0), together with the value of {wildcard} of {open content} of {content type}
Attribute Use	empty
Attribute Group Definition	empty
Model Group Definition	value of {model group}
Model Group	empty
Particle	the value of {term}
Wildcard	empty
Identity‑Constraint Definition	empty
Type Alternative	empty
Assertion	empty
Notation Declaration	empty
Annotation	empty
Schema	empty
Simple Type Definition	empty
Constraining Facet	empty
Fundamental Facet	empty

component-scope Accessor

The component-scope accessor returns components linked through the {scope} possibly via {parent} arcs.

Component	Result of component-context()
Attribute Declaration	if component-variety() is "global" then empty; otherwise the value of {parent} of {scope} (1.1) or the value of {scope} (1.0)
Element Declaration	if component-variety() is "global" then empty; otherwise the value of {parent} of {scope} (1.1) or the value of {scope} (1.0)
Complex Type Definition	empty
Attribute Use	empty
Attribute Group Definition	empty
Model Group Definition	empty
Model Group	empty
Particle	empty
Wildcard	empty
Identity‑Constraint Definition	empty
Type Alternative	empty
Assertion	empty
Notation Declaration	empty
Annotation	empty
Schema	empty
Simple Type Definition	empty
Constraining Facet	empty
Fundamental Facet	empty

assertions Accessor

The assertions accessor returns assertions components linked through the {assertions} or {value} arcs. The assertions accessor is always empty for the 1.0 schema component model.

Component	Result of assertions()
Attribute Declaration	empty
Element Declaration	empty
Complex Type Definition	the value of {assertions}
Attribute Use	empty
Attribute Group Definition	empty
Model Group Definition	empty
Model Group	empty
Particle	empty
Wildcard	empty
Identity‑Constraint Definition	empty
Type Alternative	empty
Assertion	empty
Notation Declaration	empty
Annotation	empty
Schema	empty
Simple Type Definition	empty
Constraining Facet	empty
Fundamental Facet	empty unless the facet name is "assertions"; the value of {value} otherwise

annotations Accessor

The annotations accessor returns annotations components linked through the {annotation} or {annotations} arc.

Component	Result of annotations()
Attribute Declaration	the value of {annotation} (1.0) or {annotations} (1.1)
Element Declaration	the value of {annotation} (1.0) or {annotations} (1.1)
Complex Type Definition	the value of {annotations}
Attribute Use	the value of {annotations}
Attribute Group Definition	the value of {annotation} (1.0) or {annotations} (1.1)
Model Group Definition	the value of {annotation} (1.0) or {annotations} (1.1)
Model Group	the value of {annotation} (1.0) or {annotations} (1.1)
Particle	the value of {annotations}
Wildcard	the value of {annotation} (1.0) or {annotations} (1.1)
Identity‑Constraint Definition	the value of {annotation} (1.0) or {annotations} (1.1)
Type Alternative	the value of {annotations}
Assertion	the value of {annotations}
Notation Declaration	the value of {annotation} (1.0) or {annotations} (1.1)
Annotation	empty
Schema	the value of {annotations}
Simple Type Definition	the value of {annotation} (1.0) or {annotations} (1.1)
Constraining Facet	the value of {annotation} (1.0) or {annotations} (1.1)
Fundamental Facet	empty

Canonical Schema Component Paths

The canonical schema component path of a component is a distinguished valid component path that uniquely identifies that particular component, that has as few steps as possible, and that can be deterministically constructed starting from the schema-as-a-whole description component, and that contains no extension axes or accessors.

The remainder of this section consists of a constructive definition of canonical schema component paths: a path produced by this construction will be the canonical one.

The current schema component is a schema component for which there is a valid canonical path through the schema component graph.

The target schema component is a schema component linked to the current schema component via one of the schema component properties defined previously.

The component relationship is the name of the schema component property on the current schema component which references the target schema component.

The ancestor set of the target schema component is the set of schema components on the valid canonical path to the current schema component together with the current schema component.

The base type set of a schema component is the set consisting of the {base type definition} of that schema component and the {base type definition} of every member of the set.

Constructively, this set can be computed by adding the {base type definition} to the set, and iterating on that type component, until you see a component whose {target namespace} property is "http://www.w3.org/2001/XMLSchema" and whose {name} property is "anyType".

The extended base type set of a schema component is the set consisting of the {base type definition} of that schema component if its {derivation} method is "extension" and the {base type definition} of every member of the set whose {derivation} method is "extension".

The base facet set of a schema component is the set consisting of all members of the {facets} property of members of the base type set of that schema component.

Two facets are the same if they are the same kind of component (e.g. both are length facets) and their {value} properties have identical values.

The base attribute use set of a schema component is the set consisting of all members of the {attribute uses} property of members of the base type set of that schema component.

Two attribute uses are the same if the {name} and {target namespace} of their {attribute declaration} properties are equal.

(Note that this is not equality which requires checking the {type definition} as well. However, the rules for component consistency will ensure that checking the {name} and {target namespace} suffices for our purposes here.)

The particle set of a schema component is the set consisting of the {content type} of that schema component with the members of the {particles} property of the {term} of any member of the set.

The base particle set of a schema component is the union of all particle sets of all the members of the extended base type set of that schema component.

Two particles are the same if the implementation reports them as the same. Informally, implementations will report particles that are "inherited" from base types as "the same" as the corresponding particle in the base type. Future revisions of the XML Schema recommendation will specify more precisely the conditions under which particles should be regarded as "the same".

Traversal where the current schema component is the schema-as-a-whole description component to any target schema component is always permitted in the construction of a canonical path. If the current schema component is not the schema-as-a-whole description schema component, then traversal from the current schema component to the target schema component is forbidden in the construction of a canonical path if any of the following conditions is met:

the target schema component is an identity constraint definition

the target schema component is a simple or complex type definition whose {name} property is not absent

the target schema component is an element or attribute declaration whose {scope} property is global

the target schema component has a {scope} property whose value is a schema component and that schema component is not a member of the ancestor set of the target schema component

the component relationship is {scope}, {substitution group affiliation}, {primitive type definition}, or {referenced key}

the component relationship is {base type definition} and target schema component's {name} property is not absent

the target schema component is a facet and there exists some facet in its base facet set of the target schema component that is the same as the facet

the current schema component is a complex type, the target schema component is the {attribute declaration} of an attribute use component and there exists some attribute use in the base attribute use set of the current schema component that is the same as the attribute use whose {attribute declaration} is the target schema component

the target schema component is the {term} of a particle and there exists some particle in the base particle set of the current schema component that is the same as the target schema component

Informally, the first two conditions ensure that the canonical path to an identity constraint or a named type is the one that flows directly from the schema-as-a-whole description component, the third condition ensures that the canonical path to element and attribute declarations is likewise the global one (if there is one), the fourth condition accounts for element and attribute declarations stemming from named model groups and attribute groups, the fifth and sixth ensure that the canonical path doesn't follow "backwards" paths (while accounting for redefined types), and the final three conditions ensure the canonical path to "inherited" components goes through their component of origin.

Because the 1.0 component model provides no reliable ordering of annotations, selection of a specific annotation using a numerical predicate is forbidden in canonical paths against a 1.0 schema. For 1.1 schemas, an individual annotation component is selected using a numerical predicate.

In general, it is not possible to obtain the canonical path for a schema component without access to the schema component graph. In particular, canonicalizing some non-canonical path, or determining whether a schema component path is canonical cannot be performed without such access.

For example, consider the path /type::x:foo/schemaElement::x:bar.

For this schema fragment, this represents a canonical path to the local element bar:

But for the following schema fragment, the same path represents a non-canonical path. The canonical path would instead be /group::x:barGroup/schemaElement::x:bar.

<group name="barGroup"> <sequence> <element name="bar" type="x:barType"/> </sequence> </group> <complexType name="foo"> <sequence> <group ref="x:barGroup"/> </sequence> </complexType> Canonical Syntax

The concrete syntax allows certain abbreviations, such as eliding the positional predicate where it is unnecessary to distinguish components, wildcarded schema component name tests (*), and abbreviated steps (e.g. @name) eliding optional intermediate steps, abbreviations // and *, and using short forms for element and attribute declarations and for type definitions accessed through default axes. Canonical path syntax forbids all these abbreviations. In addition, the canonical path syntax fixes the namespace prefix, if any, to p. Since at most one namespace can be involved in a canonical schema component path, one prefix suffices. Finally, use of the current component, component, and elided-component axes are disallowed in the canonical path syntax, and the use of the particle and attributeUse axes are disallowed except in the last step of the path.

Equality of Schema Component Paths

Two schema component paths are equal if they have the same number of steps, and each step in one path is equal to the corresponding step in the other. Steps are equal if they have the same axis, name test (namespace and local name, or wildcard), and predicate. all of their properties have the same value.

Note: This definition of equality neither relies on the notion of 'the same component' nor defines component equivalence. A schema component may have multiple schema component paths. Although these schema component paths address 'the same component', they are not equal. It is true, however, that two canonical paths to the same component will be equal.

Conformance Schema Component Path Conformance

Schema component paths may be used by other specifications. For such usage, this specification does not define any criteria for conformance and relies on other specifications to specify criteria for conformance of implementations.

Such specifications must define:

How the target schema is identified.

How namespace binding applies to schema component paths, in particular how or whether the default namespace applies.

Whether only canonical schema component paths are permitted.

Whether only complete schema component paths are permitted.

If incomplete schema component paths are permitted, how the initial source component is determined.

Whether any extension axes are defined, together with their syntax and semantics.

Whether any extension accessors are defined, together with their syntax and semantics.

Schema Component Designator Conformance

This specification normatively depends on the XPointer Framework .

Conforming XPointer processors claiming to support the xscd() scheme must conform to the behavior identify schema components as defined in this specification and conform to the XPointer xmlns() scheme specification.

Extensibility

Schema component paths and designators navigate the XML Schema component model and are wholly dependent on that model to define the set of allowable axes and referenced components. Therefore, as the schema component model changes, this specification may add additional axes, mapping rules, and accessors as required to support those changes. The EBNF defines syntax for extension accessors after the last step in a path and for extension axes.

Examples (Non-Normative) Extended Primer Example

This section walks through an example XML Schema Document from the XML Schema Part 0: Primer and enumerates the abbreviated and canonical schema component designators for schema components.

All schema constructs in this section are considered to be in the following schema document and its URI is schema-URI:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">  </xsd:schema>

Since this schema has no target namespace, no namespace binding is required and there is no xmlns() pointer part for any of the schema component designators for this schema.

The canonical schema component designator for this schema-as-a-whole description component is schema-URI#xscd(/).

The canonical schema component designator for this annotation schema component is schema-URI#xscd(/annotation::*).

The following is a global element declaration:

<xsd:element name="purchaseOrder" type="PurchaseOrderType"/>

The abbreviated schema component designator for this element declaration component is schema-URI#xscd(/purchaseOrder) and the canonical is schema-URI#xscd(/schemaElement::purchaseOrder).

The following is another global element declaration,

<xsd:element name="comment" type="xsd:string"/>

The abbreviated schema component designator for this element declaration component is schema-URI#xscd(/comment) and the canonical is schema-URI#xscd(/schemaElement::comment).

This following is a global complex type definition component:

<xsd:complexType name="PurchaseOrderType"> <xsd:sequence> <xsd:element name="shipTo" type="USAddress"/> <xsd:element name="billTo" type="USAddress"/> <xsd:element ref="comment" minOccurs="0"/> <xsd:element name="items" type="Items"/> </xsd:sequence> <xsd:attribute name="orderDate" type="xsd:date"/> </xsd:complexType>

The abbreviated schema component designator for this complex type definition and its element and attribute declaration components are:

schema-URI#xscd(/~purchaseOrderType) schema-URI#xscd(/~purchaseOrderType/shipTo) schema-URI#xscd(/~purchaseOrderType/billTo) schema-URI#xscd(/comment) schema-URI#xscd(/~purchaseOrderType/items) schema-URI#xscd(/~purchaseOrderType/@orderDate)

The canonical schema component designator for this complex type definition and its element and attribute declaration components are:

schema-URI#xscd(/type::purchaseOrderType) schema-URI#xscd(/type::purchaseOrderType/model::sequence/schemaElement::shipTo) schema-URI#xscd(/type::purchaseOrderType/model::sequence/schemaElement::billTo) schema-URI#xscd(/schemaElement::comment) schema-URI#xscd(/type::purchaseOrderType/model::sequence/schemaElement::items) schema-URI#xscd(/type::purchaseOrderType/schemaAttribute::orderDate)

The following is another global complex type definition component:

<xsd:complexType name="USAddress"> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> <xsd:element name="street" type="xsd:string"/> <xsd:element name="city" type="xsd:string"/> <xsd:element name="state" type="xsd:string"/> <xsd:element name="zip" type="xsd:decimal"/> </xsd:sequence> <xsd:attribute name="country" type="xsd:NMTOKEN" fixed="US"/> </xsd:complexType>

The abbreviated schema component designator for this complex type definition and its element and attribute declaration components are:

schema-URI#xscd(/~USAddress) schema-URI#xscd(/~USAddress/name) schema-URI#xscd(/~USAddress/street) schema-URI#xscd(/~USAddress/city) schema-URI#xscd(/~USAddress/state) schema-URI#xscd(/~USAddress/zip) schema-URI#xscd(/~USAddress/@country)

The canonical schema component designator for this complex type definition and its element and attribute declaration components are:

schema-URI#xscd(/type::USAddress) schema-URI#xscd(/type::USAddress/model::sequence/schemaElement::name) schema-URI#xscd(/type::USAddress/model::sequence/schemaElement::street) schema-URI#xscd(/type::USAddress/model::sequence/schemaElement::city) schema-URI#xscd(/type::USAddress/model::sequence/schemaElement::state) schema-URI#xscd(/type::USAddress/model::sequence/schemaElement::zip) schema-URI#xscd(/type::USAddress/schemaAttribute::country)

The following is a global complex type definition with anonymous complex type and simple type definition components:

<xsd:complexType name="Items"> <xsd:sequence> <xsd:element name="item" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="productName" type="xsd:string"/> <xsd:element name="quantity"> <xsd:simpleType> <xsd:restriction base="xsd:positiveInteger"> <xsd:maxExclusive value="100"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="USPrice" type="xsd:decimal"/> <xsd:element ref="comment" minOccurs="0"/> <xsd:element name="shipDate" type="xsd:date" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="partNum" type="SKU" use="required"/> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType>

The abbreviated schema component designator for this complex type definition and its element and attribute declaration, simple type definition, and facet components are:

schema-URI#xscd(/~Items) schema-URI#xscd(/~Items/item) schema-URI#xscd(/~Items/item/~0)) schema-URI#xscd(/~Items/item/productName) schema-URI#xscd(/~Items/item/quantity) schema-URI#xscd(/~Items/item/quantity/~0) schema-URI#xscd(/~Items/item/quantity/~0/facet::maxExclusive) schema-URI#xscd(/~Items/item/USPrice) schema-URI#xscd(/comment) schema-URI#xscd(/~Items/item/shipDate) schema-URI#xscd(/~Items/item/@partNum)

The canonical schema component designator for this complex type definition and its element and attribute declaration, simple type definition, and facet components are (paths broken across lines for readability):

schema-URI#xscd(/type::Items) schema-URI#xscd(/type::Items/model::sequence/schemaElement::item) schema-URI#xscd(/type::Items/model::sequence/schemaElement::item/type::0) schema-URI#xscd(/type::Items/model::sequence/schemaElement::item/type::0/ model::sequence/schemaElement::productName) schema-URI#xscd(/type::Items/model::sequence/schemaElement::item/type::0/ model::sequence/schemaElement::quantity) schema-URI#xscd(/type::Items/model::sequence/schemaElement::item/type::0/ model::sequence/schemaElement::quantity/type::0) schema-URI#xscd(/type::Items/model::sequence/schemaElement::item/type::0/ model::sequence/schemaElement::quantity/type::0/ facet::maxExclusive) schema-URI#xscd(/type::Items/model::sequence/schemaElement::item/type::0/ model::sequence/schemaElement::USPrice) schema-URI#xscd(/schemaElement::comment) schema-URI#xscd(/type::Items/model::sequence/schemaElement::item/type::0/ model::sequence/schemaElement::shipDate) schema-URI#xscd(/type::Items/model::sequence/schemaElement::item/type::0/ schemaAttribute::partNum)

The following is a global simple type definition component:

<xsd:simpleType name="SKU"> <xsd:restriction base="xsd:string"> <xsd:pattern value="\d{3}-[A-Z]{2}"/> </xsd:restriction> </xsd:simpleType>

The canonical schema component designator for this simple type definition and its facet component are:

schema-URI#xscd(/type::SKU) schema-URI#xscd(/type::SKU/facet::pattern) Additional Examples

The schema for the examples in the previous section had no target namespace. If we change the schema so that the target namespace is "http://example.com/schema/po", then the schema component designators need to take namespace bindings into account.

For example, the abbreviated schema component designator for the complex type definition USAddress and its element and attribute declaration components are:

schema-URI#xmlns(p=http://example.com/schema/po)xscd(/~p:USAddress) schema-URI#xmlns(p=http://example.com/schema/po)xscd(/~p:USAddress/p:name) schema-URI#xmlns(p=http://example.com/schema/po)xscd(/~p:USAddress/p:street) schema-URI#xmlns(p=http://example.com/schema/po)xscd(/~p:USAddress/p:city) schema-URI#xmlns(p=http://example.com/schema/po)xscd(/~p:USAddress/p:state) schema-URI#xmlns(p=http://example.com/schema/po)xscd(/~p:USAddress/p:zip) schema-URI#xmlns(p=http://example.com/schema/po)xscd(/~p:USAddress/@country)

Note that since the attributeFormDefault for the schema is unqualified (the default value), no namespace prefix is used with the country attribute.

The canonical schema component designator for this complex type definition and its element and attribute declaration components are (paths broken across lines for readability):

schema-URI#xmlns(p=http://example.com/schema/po)xscd(/type::p:USAddress) schema-URI#xmlns(p=http://example.com/schema/po)xscd(/type::p:USAddress/ model::sequence/schemaElement::p:name) schema-URI#xmlns(p=http://example.com/schema/po)xscd(/type::p:USAddress/ model::sequence/schemaElement::p:street) schema-URI#xmlns(p=http://example.com/schema/po)xscd(/type::p:USAddress/ model::sequence/schemaElement::p:city) schema-URI#xmlns(p=http://example.com/schema/po)xscd(/type::p:USAddress/ model::sequence/schemaElement::p:state) schema-URI#xmlns(p=http://example.com/schema/po)xscd(/type::p:USAddress/ model::sequence/schemaElement::p:zip) schema-URI#xmlns(p=http://example.com/schema/po)xscd(/type::p:USAddress/ schemaAttribute::country)

Schema component paths may also be used in other contexts that provide namespace binding contexts. For example, an XML representation may apply normal namespace binding rules to apply to embedded schema component paths:

/~p:USAddress/p:state State selector http://example.com/state-menu.xml Address ]]>

Another possible means of binding namespaces is to use the namespace URI as the schema designator with the convention that it is the default namespace. This could be useful combined with the use of just the schema component paths in the fragment identifier to obtain terse identifiers for global schema types in single-namespace schemas:

http://www.w3.org/2001/XMLSchema#/~gMonth

This specification does not define such a fragment identifier scheme for namespace documents. Neither does it rule out such a usage.

Examples with component and elided-component Axes (Non-Normative)

The following examples assume that the namespace prefixes r and ipo are appropriately bound.

Here is a path that designates an attribute declaration whose local name is period in the namespace denoted by r in an anonymous complex type:

/r:purchaseReport/type::0/@period

Omitting its optional intermediate step sequenceUsing the elided-component axis to select the attribute declaration directly from the element declaration, this path reduces to:

/r:purchaseReport/@period

Here is a path that designates an attributeelement declaration whose local name is name in the namespace denoted by ipo in a globally defined type:

/type::ipo:USAddress/model::sequence/model::sequence[1]/name

Omitting its optional intermediate step sequence Using the elided-component axis to select the element declaration directly from the complex type definition, this path reduces to:

/type::ipo:USAddress/name

This path designates an element declaration whose local name is regions in the namespace denoted by r in an anonymous complex type:

/r:purchaseReport/type::0/model::sequence/r:regions

Omitting its optional intermediate step sequenceUsing the elided-component axis to select the element declaration r:regions directly from the element declaration r:purchaseReport, this path reduces to:

/r:purchaseReport/r:regions

This path designates global or local element declarations whose local name is quantity in the namespace denoted by r:

//r:quantity

/~r:Items//r:quantity

/~r:Items//@partNum

This extended example works against the following schema fragment for a schema with no target namespace:

Which of the following paths can be shortened to //foo using the component and elided-component axes?

Path	Shortened to `//foo`?
`/group::aGroup/model::sequence/bar/~0/model::sequence/foo`	No
`/~aType/model::sequence/foo`	Yes
`/~aType/model::sequence/model::sequence/bar/~0/foo`	No
`/root/~aType/model::sequence/foo`	Yes
`/root/~aType/model::sequence/model::sequence/bar/~0/foo`	No

The "no" answers are all because bar is not selected by either the component axis or the elided-component axis and must therefore appear in the path.

Schema Component Properties (Non-Normative)

Schema component paths rely on the schema component graph implicit in the assembled collection of schema components and their properties. The following table details which properties are used for defining schema component paths, and whether they are used to define links in the graph (traversed) or just referenced for some other purpose. Traversals marked with a star (*) are the default axis of traversal.

Component or Property Record	Property	Use
Attribute Declaration
	{type definition}	traversed *
	{annotation}	traversed (special)
	{annotations}	traversed (special)
	{name}	referenced
	{target namespace}	referenced
	{scope}	traversed
	{value constraint}	none
Scope Property Record
	{variety}	referenced
	{parent}	traversed
Element Declaration
	{type definition}	traversed *
	{identity-constraint definitions}	traversed
	{annotation}	traversed (special)
	{annotations}	traversed (special)
	{name}	referenced
	{target namespace}	referenced
	{type table}	traversed
	{scope}	traversed
	{value constraint}	none
	{nillable}	none
	{substitution group affiliation}	traversed
	{substitution group affiliations}	traversed
	{substitution group exclusions}	none
	{disallowed substitutions}	none
	{abstract}	none
Type Table Property Record
	{alternatives}	traversed
	{default type definition}	traversed
Complex Type Definition
	{base type definition}	traversed
	{attribute uses}	traversed
	{attribute wildcard}	traversed
	{content type}	traversed *
	{annotations}	traversed (special)
	{name}	referenced
	{target namespace}	referenced
	{context}	traversed
	{derivation method}	none
	{final}	none
	{abstract}	none
	{prohibited substitutions}	none
	{assertions}	traversed
Content Type Property Record
	{variety}	referenced
	{particle}	traversed *
	{simple type definition}	traversed
	{open content}	traversed
Open Content Property Record
	{mode}	none
	{wildcard}	traversed *
Attribute Use
	{attribute declaration}	traversed *
	{value constraint}	none
	{required}	none
	{annotations}	traversed (special)
Attribute Group Definition
	{attribute uses}	traversed *
	{attribute wildcard}	traversed
	{annotation}	traversed (special)
	{annotations}	traversed (special)
	{name}	referenced
	{target namespace}	referenced
Model Group Definition
	{model group}	traversed *
	{annotation}	traversed (special)
	{annotations}	traversed (special)
	{name}	referenced
	{target namespace}	referenced
Model Group
	{particles}	traversed *
	{annotation}	traversed (special)
	{annotations}	traversed (special)
	{compositor}	referenced
Particle
	{term}	traversed *
	{min occurs}	none
	{max occurs}	none
	{annotations}	traversed (special)
Wildcard
	{annotation}	traversed (special)
	{annotations}	traversed (special)
	{namespace constraint}	none
	{process contents}	none
Identity-constraint Definition
	{annotation}	traversed (special)
	{annotations}	traversed (special)
	{name}	referenced
	{target namespace}	referenced
	{identity-constraint category}	none
	{selector}	none
	{fields}	none
	{referenced key}	traversed
Type Alternative
	{annotations}	traversed (special)
	{test}	none
	{type definition}	traversed *
Assertion
	{annotations}	traversed (special)
	{test}	none
Notation Declaration
	{annotation}	traversed (special)
	{annotations}	traversed (special)
	{name}	referenced
	{target namespace}	referenced
	{public identifier}	none
	{system identifier}	none
Annotation
	{application information}	none
	{user information}	none
	{attributes}	none
Schema
	{type definitions}	traversed
	{attribute declarations}	traversed
	{element declarations}	traversed *
	{attribute group definitions}	traversed
	{model group definitions}	traversed
	{notation declarations}	traversed
	{identity constraint definitions}	traversed
	{annotations}	traversed (special)
Simple Type Definition
	{base type definition}	traversed
	{facets}	traversed *
	{fundamental facets}	traversed
	{item type definition}	traversed
	{member type definitions}	traversed
	{context}	traversed
	{annotation}	traversed (special)
	{annotations}	traversed (special)
	{name}	referenced
	{target namespace}	referenced
	{variety}	referenced
	{final}	none
	{primitive type definition}	traversed
Facets
	{annotation}	traversed (special)
	{annotations}	traversed (special)
	{value}	nonetraversed * (assertions only)
	{fixed}	none

Summary of Component Axes (Non-Normative)

The following table details all the axes, the source and target component kinds, a brief syntax summary, and indicates whether the axis is a default one.

Axis	Source Component	Target Component	Syntax	Default?
(root)
(root)	N/A	Schema	/	no
annotations
	Attribute Declaration	Annotation	`annotation::*`	no
	Attribute Group Definition	Annotation	`annotation::*`	no
	Complex Type Definition	Annotation	`annotation::*`	no
	Element Declaration	Annotation	`annotation::*`	no
	Facet	Annotation	`annotation::*`	no
	Model Group Definition	Annotation	`annotation::*`	no
	Notation Declaration	Annotation	`annotation::*`	no
	Schema	Annotation	`annotation::*`	no
	Simple Type Definition	Annotation	`annotation::*`	no
	Wildcard	Annotation	`annotation::*`	no
attribute declarations
	Attribute Use	Attribute Declaration	`schemaAttribute::qname`	yes
	Schema	Attribute Declaration	`schemaAttribute::qname`	no
attribute group definitions
attribute group definitions	Schema	Attribute Group Definition	`attributeGroup::qname`	no
attribute uses
	Complex Type Definition	Attribute Use	N/A	no
	Attribute Group Definition	Attribute Use	N/A	yes
attribute wildcard
	Complex Type Definition	Attribute Wildcard	`anyAttribute::*`	no
	Attribute Group Definition	Attribute Wildcard	`anyAttribute::*`	no
base type definition
	Complex Type Definition	Simple Type Definition	`baseType::qname`	no
	Complex Type Definition	Complex Type Definition	`baseType::qname`	no
	Simple Type Definition	Simple Type Definition	`baseType::qname`	no
content type
content type	Complex Type Definition	Complex Type Definition	`type::qname`	yes
element declarations
element declarations	Schema	Element Declaration	`schemaElement::qname`	yes
facets
facets	Simple Type Definition	Facet	`facet::name`	yes
fundamental facets
fundamental facets	Simple Type Definition	Fundamental Facet	`facet::name`	no
identity constraint definitions
	Element Declaration	Identity-constraint Definition	`identityConstraint::qname`	no
	Schema	Identity-constraint Definition	`identityConstraint::qname`	no
item type definition
item type definition	Simple Type Definition	Simple Type Definition	`itemType::qname`	no
member type definitions
member type definitions	Simple Type Definition	Simple Type Definition	`memberType::qname`[n]	no
model group
model group	Model Group Definition	Model Group	`model::compositor[n]`	yes
model group definitions
model group definitions	Schema	Model Group Definition	`group::qname`	no
notation declarations
notation declarations	Schema	Notation Declaration	`notation::qname`	no
particles
particles	Model Group	Particle	N/A	yes
primitive type definition
primitive type definition	Simple Type Definition	Simple Type Definition	`primitivetype::qname`	no
referenced key
referenced key	Identity-constraint Definition	Identity-constraint Definition	`key::qname`	no
scope
	Attribute Declaration	Simple Type Definition	`scope::qname`	no
		Complex Type Definition	`scope::qname`	no
		Attribute Group Definition	`scope::qname`	no
	Element Declaration	Simple Type Definition	`scope::qname`	no
		Complex Type Definition	`scope::qname`	no
		Model Group Definition	`scope::qname`	no
context
	Complex Type Definition	Element Declaration	`context::qname`	no
	Complex Type Definition	Complex Type Definition	`context::qname`	no
	Simple Type Definition	Element Declaration	`context::qname`	no
		Attribute Declaration	`context::qname`	no
		Complex Type Definition	`context::qname`	no
		Simple Type Definition	`context::qname`	no
substitution group affiliation
substitution group affiliation	Element Declaration	Element Declaration	`substitutionGroup::qname`	no
term
	Particle	Element Declaration	`schemaElement::qname[n]`	yes
		Model Group	`model::compositor[n]`	yes
		Wildcard	`any::*[n]`	yes
type definitions
	Attribute Declaration	Simple Type Definition	`type::qname`	yes
	Attribute Declaration	Complex Type Definition	`type::qname`	yes
	Element Declaration	Simple Type Definition	`type::qname`	yes
	Element Declaration	Complex Type Definition	`type::qname`	yes
	Schema	Simple Type Definition	`type::qname`	no
	Schema	Complex Type Definition	`type::qname`	no
assertions
	Complex Type Definition	Assertion	`assertion::*[n]`	no
	Facet	Assertion	`assertion::*[n]`	no
alternatives
alternatives	Element Declaration	Type Alternative	`alternative::*[n]`	no

Glossary (Non-Normative)

The listing below is for the benefit of readers of a printed version of this document: it collects together all the definitions which appear in the document above.

An XSL macro is used to collect definitions from throughout the spec and gather them here for easy reference. Should talk to Henry for details. References Normative References Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, and L. Masinter. The Internet Society, January 2005. This version is available at http://www.ietf.org/rfc/rfc3986.txt. Tim Berners-Lee et al, RFC 2396: Uniform Resource Identifiers, Internet Engineering Task Force, 1995, available at http://www.ietf.org/rfc/rfc2396.txt with an update available at http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html. XML Schema Part 2: Datatypes Second Edition, Paul V. Biron and Ashok Malhotra, Editors. World Wide Web Consortium, 28 October 2004. This version is available at http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. The latest version is available at http://www.w3.org/TR/xmlschema-2/. Extensible Markup Language (XML) 1.0 (Fourth Edition) Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau, Editores. World Wide Web Consortium, 16 August 2006. This version is available at http://www.w3.org/TR/2006/REC-xml-20060816. The latest version is available at http://www.w3.org/TR/REC-xml/. XPointer xmlns() Scheme, Steven J. DeRose, Ron Daniel Jr., Eve Maler, Jonathan Marsh, Editors. World Wide Web Consortium, 25 March 2003. This version is available at http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/. The latest version is available at http://www.w3.org/TR/xptr-xmlns/. XML Schema Definition Language (XSD) 1.1 Part 1: Structures, Shundi Gao, C. M. Sperberg-McQueen, Henry S. Thompson, Editors. World Wide Web Consortium, 20 June 2008. This version is available at http://www.w3.org/TR/2008/WD-xmlschema11-1-20080620/. The latest version is available at http://www.w3.org/TR/xmlschema11-1/. XPointer Framework Paul Grosso, Eve Maler, Jonathan Marsh, Norman Walsh, Editors. World Wide Web Consortium, 25 March 2003. The current version is available at http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ The latest version is available at http://www.w3.org/TR/xptr-framework/. XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes, David Peterson, Shundi Gao, Ashok Malhotra, C. M. Sperberg-McQueen, and Henry S. Thompson, Editors. World Wide Web Consortium, 20 June 2008. This version is available at http://www.w3.org/TR/2008/WD-xmlschema11-2-20080620/. The latest version is available at http://www.w3.org/TR/xmlschema11-2/. XML Schema Part 1: Structures (Second Edition), Henry S. Thompson, David Beech, Murray Maloney and Noah Mendelsohn, Editors. World Wide Web Consortium, 28 October 2004. This version is available at http://www.w3.org/TR/xmlschema-1/. The latest version is available at http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ Non-normative Informational References XML path language (XPath) Version 1.0, James Clark and Steve DeRose, Editors. World Wide Web Consortium, 16 November 1999. This version is available at http://www.w3.org/TR/1999/REC-xpath-19991116. The latest version is available at http://www.w3.org/TR/xpath. XML Schema Part 0: Primer (Second Edition), David C. Fallside, Editor. World Wide Web Consortium, 28 October 2004. This version is available at http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/. The latest version is available at http://www.w3.org/TR/xmlschema-0/. Document Object Model (DOM) Level 3 Core Specification, Version 1.0, Arnaud Le Hors, et al, Editors. World Wide Web Consortium, 7 April 2004. This version is available at http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/ . The latest version is available at http://www.w3.org/TR/DOM-Level-3-Core/ .

[target namespace]
[name]	The facet name, one of `whiteSpace`, `minInclusive`, `maxInclusive`, `minExclusive`, `maxExclusive`, `totalDigits`, `fractionDigits`, `length`, `minLength`, `maxLength`, `pattern`, `enumeration`, `minScale`, `maxScale` `ordered`, `bounded`, `cardinality`, or `numeric`
[schema component kind]	`facet`
[axis]	`facet` or `fundamental` `facet`
[predicate]