A canonical schema component designator is an absolute schema component designator that is a URI that has been canonicalized according to the rules given in the update to RFC2396 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 where the pointer data is a canonical schema component path.

Many use cases for schema component designators call for them to be compared for equality. A simple string comparison cannot be used 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.

An assembled schema consists of a graph of schema components. 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.

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]:

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

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, rather than to an individual annotation component. This is because we cannot distinguish between individual annotations.

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

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

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

where ns-prefix is bound to [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] of the element information item); other host languages (such as XQuery) will define their own namespace binding rules.

The syntax provides various abbreviations as defined below.

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.

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.

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

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 component, the third condition ensures that the canonical path to element and attribute declarations is likewise the global one (if there is one), the last condition accounts for element and attribute declarations stemming from named model groups and attribute groups, the fifth ensures that the canonical path doesn't follow "backwards" paths, and the final three conditions ensure the canonical path to "inherited" components goes through their component of origin.

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)/element(x:bar).

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

But for this schema fragment, it represents a non-canonical path. The canonical path would be /group(x:barGroup)/element(x:bar).

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

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.

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