W3C XML Schema Definition Language (XSD): Component Designators

2.1 Requirements

Basic Functionality

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

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

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

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

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

Properties of the Designator

1. Designators should be human-readable.

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

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

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

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

Compatibility

1. Designators should be URI references.

2. Designators should work well in a RDDL environment.

Non-goals

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

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

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

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

2.2 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 [DOM3] 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.

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

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.

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

3.1 Schema Component Designator Syntax

EBNF

3.2 Canonical Schema Component Designators

[Definition: A canonical schema component designator is an absolute schema component designator that is a URI that has been mapped from a LEIRI to an IRI in accordance with the rules given in [LEIRI], mapped from an IRI to a URI in accordance with the rules given in RFC 3987[RFC 3987], and normalized according to the rules of syntax-based normalization given there; and where the relative schema component designator consists of an xmlns XPointer pointer part (if required) followed by a canonicalized xscd XPointer pointer part. ]

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

3.3 Equality of Schema Component Designators

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

[Definition: 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.]

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

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

[Definition: 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}

A Schema Component Properties (Non-Normative) includes a summary of which arcs act as defaults and when.

4.2 Schema Component Path Syntax

/type::my:title

/schemaElement::my:title

/schemaAttribute::my:title

/attributeGroup::my:title

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

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

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

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

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

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

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

4.3 Interpretation of Schema Component Paths

[Definition: 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 '//'. ]

[Definition: 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 4.4 Schema Component Path Axes.

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

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

[Definition: 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').

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

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.

[Definition: 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. Counting starts at 1.

A path consisting of just '/' selects the schema description component.

A path of the form /S1 selects components linked to the schema 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.

model::sequence/schemaElement::my:section

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

//quantity

/~Items//quantity

/~Items//@partNum

4.4 Schema Component Path Axes

[Definition: 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. ]

4.5 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}

4.6 Canonical Schema Component Paths

[Definition: 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 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.

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

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

[Definition: The component relationship is the name of the schema component property on the current schema component which references the target schema component. ]

[Definition: 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.]

[Definition: 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".

[Definition: 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". ]

[Definition: 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.]

[Definition: 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.]

[Definition: 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.]

[Definition: 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.)

[Definition: 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.]

[Definition: 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.]

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

1. the target schema component is an identity constraint definition

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

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

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

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

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

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

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

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

   
<complexType name="foo">   
  <sequence>   
     <element name="bar" type="x:barType"/>   
  </sequence>   
</complexType>   

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>   

4.7 Equality of Schema Component Paths

[Definition: 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. .]

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.

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

5.2 Schema Component Designator Conformance

This specification normatively depends on the XPointer Framework [XPTR].

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

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

6.1 Extended Primer Example

This section walks through an example XML Schema Document from the XML Schema Part 0: Primer[XSD0] 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">   
<!-- elided... see below ... -->   
</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 description component is schema-URI#xscd(/).

   
<xsd:annotation>   
 <xsd:documentation xml:lang="en">   
  Purchase order schema for Example.com.   
  Copyright 2000 Example.com. All rights reserved.   
 </xsd:documentation>   
</xsd:annotation>   

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:

   
<!-- Stock Keeping Unit, a code for identifying products -->   
<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)   

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

   
<xsx:ui xmlns:err="http://example.com/extension/ui"    
        xmlns:p="http://example.com/schema/po">   
  <xsx:component>   
     <xsx:path>/~p:USAddress/p:state</xsx:path>   
     <xsx:prompt>State</xsx:prompt>   
     <xsx:display>selector</xsx:display>   
     <xsx:choices>http://example.com/state-menu.xml</xsx:choices>   
     <xsx:tab>Address</xsx:tab>   
  </xsx:component>   
</xsx:ui>   

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   

6.3 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

Using 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 element 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

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

Using 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

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 of the following paths can be shortened to //foo using the component and elided-component axes?

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.