This document is also available in these non-normative formats: XML.
Copyright © 2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademarkand document use rules apply.
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 is a W3C Last Call Working Draft of the XML Schema: Component Designators document 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 2005-03-04. It has been reviewed by the working group and the working group has agreed to publication as a Last Call draft. The Last Call comment period is expected to end 26 April 2005. Following this Last Call for review the Working Group intends to submit this specification as a publication for Candidate Recommendation.
This schedule may vary, depending on the comments of the public and of other W3C working groups on this draft. Such comments are instrumental in the WG's deliberations, and we encourage readers to review the draft and to send comments to www-xml-schema-comments@w3.org mailing list (archived at http://lists.w3.org/Archives/Public/www-xml-schema-comments/). Commenters are requested to put the string "[XSCD]" at the beginning of the subject field of email messages. Note that all outstanding issues against this document are documented in the Working Group's running issues list.
Although the Working Group does not anticipate further changes to the functionality described here, this is still a working draft, subject to change. The present version should be implemented only by those interested in providing a check on its design or by those preparing for an implementation of the Candidate Recommendation. The Schema WG will not allow early implementation to constrain its ability to make changes to this specification prior to final release.
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.
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/. They may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress".
The following changes were made since the last working draft:
This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing [and excluding] a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction (Non-Normative)
2 Goals and Use Cases (Non-Normative)
2.1 Requirements
2.2 Use Cases
3 Schema Component Designators
3.1 Schema Component Designator Syntax
3.2 Canonical Schema Component Designators
3.3 Equality of Schema Component Designators
4 Schema Component Paths
4.1 Schema Component Graph Traversal
4.2 Schema Component Path Syntax
4.3 Canonical Schema Component Paths
4.4 Equality of Schema Component Paths
5 Conformance
5.1 Schema Component Path Conformance
5.2 Schema Component Designator Conformance
6 Example (Non-Normative)
A Schema Component Properties (Non-Normative)
B Glossary (Non-Normative)
C References
C.1 Normative References
C.2 Non-normative Informational References
This document defines a system for designating XML Schema components. Part 1 of the W3C XML Schema recommendation [XSD1] 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.
Finally, there are schema components for the facets defined in Part 2 of the W3C XML Schema recommendation [XSD2]:
Fundamental Facets: ordered, bounded, cardinality, numeric
Constraining Facets: whiteSpace, minInclusive, maxInclusive, minExclusive, maxExclusive, totalDigits, fractionDigits, length, minLength, maxLength, pattern, enumeration
At first blush, a QName (prefix:localname) may seem sufficient to the task of designating any schema component. This is incorrect 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 extended name, or {namespace name, local name} pair.
The same extended 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 be uniquely named by an extended name.
Anonymous type definitions have no extended name, or they have an extended name that is dependent upon the particular schema processor interpreting the schema.
Certain schema components (annotation, particle, wildcard) are purely 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 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 extended 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 component.
Designators must function in the face of redefinitions.
The schema-as-a-whole 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, 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.
Designators should be unambiguous, designating exactly one component within a schema. However, certain abbreviation and wildcarding constructs may designate collections of components. In any case, each component should have at least one unambiguous designator that designates that component and no other.
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 human-readable.
Given a designator, it should be possible to get the extended 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, 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.
Designators should be URI references.
Designators should work well in a RDDL environment.
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 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.
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 DOM3 to expose anonymous types.
Identifying types for casting, specifically wrt anonymous and local types.
Identifying types for function signatures.
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'.
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 a local element with 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 separately refer to particles versus groups is important. Being able to separately refer 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.
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
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.
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 rely on a layered model of schema component reference. Schema component paths designate components in the context of a particular schema assembly. Full blown schema designators build on this by applying the schema component paths in the context of a URI reference, where the URI identifies the schema, and the fragment part encapsulates a schema component path to designate components in the context of that schema.
This section describes schema component designators as a whole. The details of schema component paths are described in 4 Schema Component Paths.
[Definition: 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.
Note:
The representation of a resource obtained by dereferencing a schema URI must allow for the fragment identifier syntax defined here. 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. 4 Schema Component Paths 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 cannot be used to construct a valid path; nor can a schema component be successfully referenced through a path that references a missing component.
[Definition: An absolute schema component designator 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, and the second part is an XPointer fragment identifier. An absolute schema component designator therefore is a URI reference.
[Definition: The
relative schema component designator is 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 be used in
combination with other XPointer schemes.
The construction and syntax of schema component paths are described in
4 Schema Component Paths.
[1] | SchemaComponentDesignator | ::= | AbsoluteSchemaComponentDesignator |
RelativeSchemaComponentDesignator |
[2] | AbsoluteSchemaComponentDesignator | ::= | SchemaDesignator '#'
RelativeSchemaComponentDesignator |
[3] | SchemaDesignator | ::= | URI |
[4] | RelativeSchemaComponentDesignator | ::= | XmlnsPointerPart*
XscdPointerPart
|
[5] | XmlnsPointerPart | ::= |
'xmlns' '(' XmlnsSchemeData ')'
|
[6] | XscdPointerPart | ::= | 'xscd' '(' SchemaComponentPath ')'
|
[Definition:
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
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 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.
[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.]
An assembled schema forms a graph of schema components, where certain schema component properties contain other schema components as their values (or part of their values). 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 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, and then defines which path is the canonical one.
For the purposes of schema component paths, presume the existence of an {identity constraint definitions} property of the schema-as-a-whole 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.
[Definition: A schema component path 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 4.2 Schema Component Path Syntax.
[Definition: A [step] represents 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.
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]:
{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}
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}
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.
{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}
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".
[Definition: A traversal from one component to another takes place across some particular component property. This property is the axis of traversal. ]
[Definition: A default axis is a privileged axis of traversal. ] The default axes are:
{type definition}
{content type}
{attribute declaration}
{attribute uses}
{model group}
{particles}
{term}
{element declarations}
{facets}
In general the syntax of a step of the schema component path has the following form:
::
ns-prefix:
[name][
[predicate]]
where ns-prefix is bound to the [target namespace]
of the component. 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 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:
::*
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
:
::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.
The [step] for the schema-as-a-whole schema component has the properties:
[target namespace] | |
[name] | |
[schema component kind] | schema |
[axis] |
|
[predicate] |
/
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 |
[predicate] |
attribute::prefix:name
or @prefix:name
The [step] for an element declaration schema component has the properties:
[target namespace] | Value of {target namespace} |
[name] | Value of {name} |
[schema component kind] | element |
[axis] | element declaration , term , or substitution group affiliation |
[predicate] | None if the [axis] is
substitution group affiliation 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. |
substitution
group
affiliation
then
substitutionGroup::prefix:name
element::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 the value of
n
is 1.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 , or
primitive type definition |
[predicate] |
If the [axis] is member type definition , the pair
{position, n} where n is the
position of this simple type definition among S's {member type definitions}.
Otherwise, none. |
base
type
definition
then
baseType::prefix:name
primitive
type
definition
then
primitiveType::prefix:name
member
type
definition
then
memberType::prefix:name[n]
item
type
definition
then
itemType::prefix:name
type::prefix:name
or ~prefix:name
prefix:name
will be 0
for anonymous types.
The [n]
may be absent if the value of
n
is 1.
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 ,
or scope |
[predicate] |
scope
then
scope::prefix:name
base
type
definition
then
baseType::prefix:name
type::prefix:name
or ~prefix:name
prefix:name
will be 0
for anonymous types.
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 |
[predicate] |
attributeGroup::prefix:name
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 |
[predicate] |
group::prefix:name
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] |
referenced key
then
key::prefix:name
identityConstraint::prefix:name
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
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.
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 the value of
n
is 1 (as it always is for the all
compositor).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.
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 |
[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 the value of
n
is 1.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 [step] for a facet schema component has the properties:
[target namespace] | |
[name] | The facet name, one of
whiteSpace , minInclusive ,
maxInclusive , minExclusive ,
maxExclusive , totalDigits ,
fractionDigits , length , minLength ,
maxLength , pattern , enumeration ,
ordered , bounded , cardinality ,
or numeric |
[schema component kind] | facet |
[axis] | facet or
fundamental facet |
[predicate] |
facet::name
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
:
/element::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
:
/attribute::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/element::my:section
And the following schema component path refers to the second:
/type::my:articleType/model::sequence/element::my:appendix
A schema component path referring to the (anonymous) complex type of the globally defined element:
/element::my:chapter/type::0
A schema component path that refers to the wildcard in the globally defined element:
/element::my:chapter/type::0/model::sequence/any::*
A schema component path that refers to the attribute of the globally defined element:
/element::my:chapter/type::0/attribute::name
[Definition: An intermediate step is a [step] piece that is neither the first step nor the last step in a schema component path.] [Definition: Head steps are a series of steps in a schema component path, begin with the first step and end 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:
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.
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.
Here is a path that designates an attribute declaration whose local name is
period
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 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 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
:
//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
.
/~Items//quantity
This path designates global or local attribute
declarations whose local name is partNum
wgere these declarations
are in the subgraph represented by the global complex type component whose
local name is Items
:
/~Items//@partNum
[7] | SchemaComponentPath | ::= | SchemaStep |
StepSepator
RelativeSchemaComponentPath
|
[8] | SchemaStep | ::= | '/' |
[9] | RelativeSchemaComponentPath | ::= | Step |
Step
StepSeparator
RelativeSchemaComponentPath
|
[10] | StepSeparator | ::= | '/' | '//' |
[11] | Step | ::= | AttributeStep |
ElementStep |
SimpleTypeStep |
ComplexTypeStep |
AttributeGroupStep |
GroupStep |
IdentityConstraintStep |
NotationStep |
AnnotationsStep |
ModelGroupStep |
WildcardStep |
FacetStep
|
[12] | NameOrWildcard | ::= | QName | '*' |
[13] | NameWildcardOrAnonymous | ::= | QName | '*' | '0' |
[14] | AttributeStep | ::= | AttributeFullform |
AttributeShortform |
[15] | AttributeFullform | ::= | 'attribute' '::' NameOrWildcard |
[16] | AttributeShortform | ::= | '@' NameOrWildcard
|
[17] | ElementStep | ::= | ( ( ElementFullform |
ElementShortform )
Predicate? ) |
SubstitutionGroupAxis |
[18] | ElementFullform | ::= | 'element' '::' NameOrWildcard |
[19] | ElementShortform | ::= | NameOrWildcard
|
[20] | SubstitutionGroupAxis | ::= | 'substitutionGroup' '::' NameOrWildcard |
[21] | SimpleTypeStep | ::= | TypeDefinitionAxis |
BaseTypeAxis |
PrimitiveTypeAxis |
ItemTypeAxis |
MemberTypeAxis
|
[22] | TypeDefinitionAxis | ::= | TypeDefinitionAxisFullform |
TypeDefinitionAxisShortform
|
[23] | TypeDefinitionAxisFullform | ::= | 'type' '::' NameWildcardOrAnonymous |
[24] | TypeDefinitionAxisShortform | ::= | '~' NameWildcardOrAnonymous |
[25] | BaseTypeAxis | ::= | 'baseType' '::' NameOrWildcard |
[26] | PrimitiveTypeAxis | ::= | 'primitiveType' '::' NameOrWildcard |
[27] | ItemTypeAxis | ::= | 'itemType' '::' NameWildcardOrAnonymous |
[28] | MemberTypeAxis | ::= | 'memberType' '::' NameWildcardOrAnonymous
Predicate?
|
[29] | ComplexTypeStep | ::= | TypeDefinitionAxis |
BaseTypeAxis |
ScopeAxis
|
[30] | ScopeAxis | ::= | 'scope' '::' NameWildcardOrAnonymous |
[31] | AttributeGroupStep | ::= | 'attributeGroup' '::' NameOrWildcard |
[32] | GroupStep | ::= | 'group' '::' NameOrWildcard |
[33] | IdentityConstraintStep | ::= | IdentityConstraintAxis |
ReferencedKeyAxis
|
[34] | IdentityConstraintAxis | ::= | 'identityContraint' '::' NameOrWildcard |
[35] | ReferencedKeyAxis | ::= | 'key' '::' NameOrWildcard |
[36] | NotationStep | ::= | 'notation' '::' NameOrWildcard |
[37] | AnnotationsStep | ::= | 'annotation' '::' '*' |
[38] | ModelGroupStep | ::= | 'model' '::' ('sequence' | 'choice' | 'all' | '*') ')' Predicate? |
[39] | WildcardStep | ::= | ( 'any' '::' '*' Predicate? ) | ('anyAttribute' '::' '*')
|
[40] | FacetStep | ::= | 'facet' '::' ( FacetName | '*' ) |
[41] | FacetName | ::= | 'ordered' | 'bounded' | 'numeric' | 'cardinality' |
'whiteSpace' | 'minInclusive' | 'maxInclusive' | 'minExclusive' |
'maxExclusive' | 'totalDigits' | 'fractionDigits' | 'length' | 'minLength' |
'maxLength' | 'pattern' | 'enumeration'
|
[42] | Predicate | ::= | '[' [0-9]+ ']' |
[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. ]
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-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:
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 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.
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
:
<complexType name="foo"> <sequence> <element name="bar" type="x:barType"/> </sequence> </complexType>
But for this schema fragment, it represents a non-canonical path. The
canonical path would be /group::x:barGroup/element::x:bar
.
<group name="barGroup"> <sequence> <element name="bar" type="x:barType"/> </sequence> </group> <complexType name="foo"> <sequence> <group ref="x:barGroup"/> </sequence> </complexType>
The concrete syntax allows certain abbreviations, such as
eliding the positional predicate when the position is 1, 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.
[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 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.
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>
The canonical schema component designator for this schema-as-a-whole
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(/element::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(/element::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/element::shipTo) schema-URI#xscd(/type::purchaseOrderType/model::sequence/element::billTo) schema-URI#xscd(/element::comment) schema-URI#xscd(/type::purchaseOrderType/model::sequence/element::items) schema-URI#xscd(/type::purchaseOrderType/attribute::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/element::name) schema-URI#xscd(/type::USAddress/model::sequence/element::street) schema-URI#xscd(/type::USAddress/model::sequence/element::city) schema-URI#xscd(/type::USAddress/model::sequence/element::state) schema-URI#xscd(/type::USAddress/model::sequence/element::zip) schema-URI#xscd(/type::USAddress/attribute::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,
schema-URI#xscd(/type::Items) schema-URI#xscd(/type::Items/model::sequence/element::item) schema-URI#xscd(/type::Items/model::sequence/element::item/type::0) schema-URI#xscd(/type::Items/model::sequence/element::item/type::0/model::sequence/element::productName) schema-URI#xscd(/type::Items/model::sequence/element::item/type::0/model::sequence/element::quantity) schema-URI#xscd(/type::Items/model::sequence/element::item/type::0/model::sequence/element::quantity/type::0) schema-URI#xscd(/type::Items/model::sequence/element::item/type::0/model::sequence/element::quantity/type::0/facet::maxExclusive) schema-URI#xscd(/type::Items/model::sequence/element::item/type::0/model::sequence/element::USPrice) schema-URI#xscd(/element::comment) schema-URI#xscd(/type::Items/model::sequence/element::item/type::0/model::sequence/element::shipDate) schema-URI#xscd(/type::Items/model::sequence/element::item/type::0/attribute::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)
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 | Property | Use |
---|---|---|
Attribute Declaration | ||
{type definition} | traversed * | |
{annotation} | traversed (special) | |
{name} | referenced | |
{target namespace} | referenced | |
{scope} | traversed | |
{value constraint} | none | |
Element Declaration | ||
{type definition} | traversed * | |
{identity-constraint definitions} | traversed | |
{annotation} | traversed (special) | |
{name} | referenced | |
{target namespace} | referenced | |
{scope} | traversed | |
{value constraint} | none | |
{nillable} | none | |
{substitution group affiliation} | traversed | |
{substitution group exclusions} | none | |
{disallowed substitutions} | none | |
{abstract} | none | |
Complex Type Definition | ||
{base type definition} | traversed | |
{attribute uses} | traversed | |
{attribute wildcard} | traversed | |
{content type} | traversed * | |
{annotations} | traversed (special) | |
{name} | referenced | |
{target namespace} | referenced | |
{derivation method} | none | |
{final} | none | |
{abstract} | none | |
{prohibited substitutions} | none | |
Attribute Use | ||
{attribute declaration} | traversed * | |
{value constraint} | none | |
{required} | none | |
Attribute Group Definition | ||
{attribute uses} | traversed * | |
{attribute wildcard} | traversed | |
{annotation} | traversed (special) | |
{name} | referenced | |
{target namespace} | referenced | |
Model Group Definition | ||
{model group} | traversed * | |
{annotation} | traversed (special) | |
{name} | referenced | |
{target namespace} | referenced | |
Model Group | ||
{particles} | traversed * | |
{annotation} | traversed (special) | |
{compositor} | referenced | |
Particle | ||
{term} | traversed * | |
{min occurs} | none | |
{max occurs} | none | |
Wildcard | ||
{annotation} | traversed (special) | |
{namespace constraint} | none | |
{process contents} | none | |
Identity-constraint Definition | ||
{annotation} | traversed (special) | |
{name} | referenced | |
{target namespace} | referenced | |
{identity-constraint category} | none | |
{selector} | none | |
{fields} | none | |
{referenced key} | traversed | |
Notation Declaration | ||
{annotation} | 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 | |
{annotations} | traversed (special) | |
{name} | referenced | |
{target namespace} | referenced | |
{variety} | referenced | |
{final} | none | |
{primitive type definition} | traversed | |
Facets | ||
{annotation} | traversed (special) | |
{value} | none | |
{fixed} | none |
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.
xmlns
XPointer pointer part (if required) followed
by a canonicalized xscd
XPointer pointer part.
xscd
XPointer pointer part is
an xscd
XPointer pointer part where the pointer data is a canonical schema
component path.
xscd()
that uses a schema component path
as the scheme data.