W3C

XML Schema: Component Designators

W3C Working Draft 9 March 2004

This version:
http://www.w3.org/TR/2004/WD-xmlschema-ref-20040309/
Latest version:
http://www.w3.org/TR/xmlschema-ref/
Previous version:
http://www.w3.org/TR/2003/WD-xmlschema-ref-20030109/
Editors:
Mary Holstege, Cerisent
Asir S. Vedamuthu, webMethods

Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Abstract

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.

Status of this Document

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 Working Draft for review by members of the W3C and other interested parties. It has been produced by the W3C XML Schema Working Group as part of the W3C XML Activity, with the intention that it should, when complete, become a W3C Recommendation. It has been reviewed by the working group and the working group has agreed to publication. No part of this document has the formal consensus of the working group.

This version of this specification was published on 9 March 2004; it differs from the previous version (of 9 January 2003) in several ways:

  1. The use-cases and requirements have been extended and clarified.
  2. The draft allows for non-canonical schema component paths.
  3. The draft introduces a three-layer model for schema component reference: components in context, schema assembly, and schema reference.
  4. The draft has been substantially reorganized.

This document is intended to provide the membership and other interested parties with information on the technical direction the working group intends to take in this area to obtain early feedback and coordination. Please send comments on this document to www-xml-schema-comments@w3.org (archive). Concrete descriptions of use cases and rationales are particularly welcome.

Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page in conformance with W3C policy (specifically, the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure). 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.

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.

Table of Contents

1 Introduction
2 Goals and Use Cases
    2.1 Candidate Requirements
    2.2 Use Cases
3 Terminology
4 Schema Component Designators
    4.1 Schema Component Designator Syntax
    4.2 Schema Designators
5 Schema Component Paths
    5.1 Schema Component Graph Traversal
    5.2 Schema Component Path Syntax
    5.3 Canonical Schema Component Paths
    5.4 Equality of Schema Component Paths
6 Canonical Schema Component Designators
7 Equality of Schema Component Designators
8 Examples
    8.1 Example 1: Purchase Order from Primer
    8.2 Example 2: Report Schema from Primer
9 Conformance

Appendices

A Schema Component Properties
B Bibliography
C Issues

1 Introduction

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:

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

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

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

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

  3. Locally scoped element and attribute declarations cannot be uniquely named by an extended name.

  4. Anonymous type definitions have no extended name, or they have an extended name that is dependent upon the particular schema processor interpreting the schema.

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

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

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

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

  1. Designators must either include full extended names, or define namespace bindings.

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

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

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

  5. Designators must function in the face of redefinitions.

Of the various proposals considered [FD], [JRNUN], [PWNUN], [CXML], [HTNUN1], [HTNUN2], [MFNUN], two essential approaches stand out:

  1. Designators that navigate or reference some kind of canonicalized XML schema document representing an assembled XML Schema using standard XPath syntax. That is, construct XPaths against schema documents in an alternative XML syntax that more directly reflects the component structure, unrolling imports and includes, distributing the target namespace, and so on.

  2. Designators that navigate or reference schema components in an assembled XML Schema:

    1. Using an XPath-like syntax with special axes relevant to schema components, or

    2. Using an extended QName syntax, or

    3. Using the XPointer scheme syntax, with special schemes relevant to schemas.

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 deferencing 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 proposes to divide the problem of constructing schema component designators into two parts: defining a designator for an assembled schema, and defining a designator for a schema component, understood relative to a designated schema.

2 Goals and Use Cases

2.1 Candidate Requirements

Basic Functionality

  1. Designators should be unambiguous, designating exactly one component within a schema.

  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.

Properties of the Designator

  1. Designators should be human-readable.

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

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

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

Compatibility

  1. Designators should be URIs. ?URIReferences?

  2. Designators should work well in a RDDL environment.

  3. Editorial note1-October-2002
    Do we want statements of compatibility with XPointer? XPath?
Additional

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

  2. Component designators should allow users to make or to elide the distinction between schemas and schema documents.

    Editorial note1-October-2002
    Discussion in WG recast this as some members wanting to be able to refer to the abstract notion of, say, the HTML "P" element, without regard to which of these three schemas for that namespace was meant. If this were a requirement I would phrase it so: Form the class consisting of all the possible top-level schema components with a particular extended name of a particular kind (e.g. element declaration). It should be possible to provide a designator for this class. Explanation: restricted to top-level, because I can't see how you get anything else without having a schema and its particular structuring in mind. This definition is already pretty amorphous in that it has to account for all possible schemas that might have that element declaration in it. It must be understood as an explanation of an answer to the question: what does an namespace URI refer to. The answer being here: the set of all possible schemas for that namespace.
Non-goals

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

    Editorial note24-September-2003
    I would like to extend this to cover all helper components.

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

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

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

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

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

    • Naming the type of something that has been selected, as in XQuery, XPath 2.0, or XSLT 2.0

    • For use wherever types are named, for example to specify a type in an XPath 2.0 or XQuery expression. e,g. element-of(type-t)

    • Enabling DOM3 to expose anonymous types

  • Identifying types for TREAT AS (in Query) specifically wrt anonymous and local types.

  • Identifying types for function signatures for XQuery, XSLT 2.0 and related specifications.

Element declaration references

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

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

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

Miscellaneous text-based uses within schema-based tools

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

  • A tool that creates interlinked HTML pages describing a schema.

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

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

  • input/output

  • user reports

  • glue/interfaces among

Other

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

Out-of-scope

  • It should be possible to supply schema component designators for items in a document instance without access to the content models in the schema.

  • Writing a schema to describe results of cut and paste.

  • Schema fragment cloning

3 Terminology

Editorial note1-October-2002
TBD

4 Schema Component Designators

[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 relative (a relative schema component designator) to that assembled schema.]

Structurally, the first part looks like a URI, and the second part looks like an XPointer fragment identifier. An absolute schema component designator therefore is structurally a URI reference.

[Definition: The relative schema component designator is an XPointer scheme xscd() that uses schema component path as the scheme data. This XPointer scheme MAY be used in combination with the XPointer xmlns() scheme .] The construction and syntax of schema component paths are described in 5 Schema Component Paths.

4.1 Schema Component Designator Syntax

EBNF
[1]   schema-component-designator   ::=   schema-designator '#' relative-schema-component-designator
[2]   relative-schema-component-designator   ::=   'xscd(' schema-component-path ')'

Issue (issue-xptr-scheme):

Is is like an XPointer scheme or is it actually an Xpointer scheme? If it is an XPointer scheme then that sharpens the question of what the designator for an assembled schema is, because XPointer says you are pointing at an XML encoded resource of a particular MIME type. What MIME type? What resource? Update: open, but in the TAG's court.

4.2 Schema Designators

Section 4 of XML Schema Part 1: Structures specifies a 3-layer model of schema processor conformance. Layer 1 describes schema assessment in the context of a set of assembled schema components. Layer 2 describes assembly of schemas from schema documents. Layer 3 describes some conventions for accessing schema documents over the World Wide Web.

Schema component designators rely on a related 3-layer model of schema component reference: Layer 1, the reference core, specifies the manner in which schema component paths relate to schema components. Layer 2 specifies the mapping of a set of schema documents to a schema. Layer 3 provides a set of conventions for the identifying such a set of schema documents on the Web.

4.2.1 Layer 1: Reference Core

The schema component reference core defines reference to a schema component in the context of an assembled XML Schema. 5 Schema Component Paths defines this relationship between an assemblage of schema components and component paths.

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.

4.2.2 Layer 2: Schema Assembly

Section 4.2 of W3C XML Schema: Part 1 defines how a schema may be assembled from multiple source XML schema documents through the import, include, and redefine mechanisms. Section 4.3 goes a little further and countenances assembly of schemas from multiple independent schema documents, some of which may be referred to via the instance, perhaps only obliquely by use of a particular namespace.

Schema component designators do not depend on the presence of a particular instance: only an assembled schena. For our purposes, layer 2 is about assembling a schema from a collection of schema documents. That set of schema documents may have been obtained in a number of ways, including:

  1. from a single root schema document that imported or included other documents;

  2. from a set of schema elements embedded in or referred to in some start document (a WSDL document, for example);

  3. from some kind of package format defining the collection;

  4. from the set of schema documents a processor deems necessary to perform schema assessment on a particular instance document.

This specification imposes no particular constraint on how processors might obtain this collection of schema documents beyond that imposed by the XML Schema recommendation.

4.2.3 Layer 3: Schema URI

[Definition: A schema designator is a single URI that represents a collection of schema documents forming a schema.]

Layer 3 notes conventions for obtaining a single URI to refer to a collection of schema documents forming a schema. We expect that it will be highly desirable for the community to evolve one convention for doing this to ensure consistency of global schema component designators. This specification declines to specify what that one way should be.

The URI on the left hand side of the schema component designator should be a URI of an actual document, in some media type. That media type should be some XML derivative, so that the XPointer framework applies. For any of the cases outlined above, there is a single root XML document, whose URI can be taken as the starting point for assembling the schema and from there resolving the component path.

In the simplest case, where there is one root schema document, the URI of that document suffices. It therefore follows that a distinct copy of that schema document at some other location will give rise to different absolute schema component designators. Further absolutization, so that there is only one preferred schema URI is an additional convention that may prove useful, but one that this specification also declines to specify.

5 Schema Component Paths

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. First, this section describes the general procedure for traversing the graph and constructing paths, and then defines which path is the canonical one.

[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 5.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], and a [schema component kind].] 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. 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.

5.1 Schema Component Graph Traversal

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}
{annotations}
{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}
{annotation}
{attribute wildcard}
{model group}
{attribute declaration}
{term}

Editorial note9-July-2003
Will become {annotations}, not {annotation} and drop from this list.

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

{content type}

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.

5.2 Schema Component Path Syntax

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

/[schema component kind]([ns-prefix:[name]])[[predicate]]

where ns-prefix is bound to [target namespace]. Various abbreviations are possible as defined below.

5.2.1 Schema-as-a-whole Component

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

[target namespace]
[name]
[schema component kind]schema
[predicate]
Syntax: empty string.

5.2.2 Attribute Declaration

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

[target namespace]Value of {target namespace}
[name]Value of {name}
[schema component kind]attribute
[predicate]
Syntax: /attribute(prefix:name) or /@prefix:name

5.2.3 Element Declaration

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

[target namespace]Value of {target namespace}
[name]Value of {name}
[schema component kind]element
[predicate]None 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.
Syntax: /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.

5.2.4 Simple Type Definition

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

[target namespace]Value of {target namespace}
[name]Value of {name}
[schema component kind]simpleType
[predicate]If the superordinate component is a simple type schema component (call it S) and S's {variety} property is union, the pair {position, n} where n is the position of this simple type definition among S's {member type definitions}
Syntax: /simpleType(prefix:name)[n] where prefix:name will be empty for anonymous types. The [n] will be absent if the {variety} of the S is not union and may be absent if the value of n is 1.
Editorial note6-November-2003
On October 31st 2003, XML Schema WG decided to replace the keywords 'complexType' and 'simpleType' with 'type' (one keyword). Next version of this draft will reflect this change.

5.2.5 Complex Type Definition

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

[target namespace]Value of {target namespace}
[name]Value of {name}
[schema component kind]complexType
[predicate]
Syntax: /complexType(prefix:name) where prefix:name will be empty for anonymous types.
Editorial note6-November-2003
On October 31st 2003, XML Schema WG decided to replace the keywords 'complexType' and 'simpleType' with 'type' (one keyword). Next version of this draft will reflect this change.

5.2.6 Attribute Group Definition

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

[target namespace]Value of {target namespace}
[name]Value of {name}
[schema component kind]attributeGroup
[predicate]
Syntax: /attributeGroup(prefix:name)

5.2.7 Model Group Definition

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

[target namespace]Value of {target namespace}
[name]Value of {name}
[schema component kind]group
[predicate]
Syntax: /group(prefix:name)

5.2.8 Identity-constraint definition

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

[target namespace]Value of {target namespace}
[name]Value of {name}
[schema component kind]identityConstraint
[predicate]
Syntax: /identityConstraint(prefix:name)

5.2.9 Notation declaration

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

[target namespace]Value of {target namespace}
[name]Value of {name}
[schema component kind]notation
[predicate]
Syntax: /notation(prefix:name)

5.2.10 Annotation

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

[target namespace]
[name]
[schema component kind]annotation
[predicate]
Syntax: /annotation()
Editorial note8-July-2003
This needs to be fixed up apropos decision to just designate the whole set of annotations, not any annotation in particular. This is very different from how we deal with other components, so needs some rework.

5.2.11 Model Group

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

[target namespace]
[name]
[schema component kind]The value of the {compositor} property, one of sequence, choice, or all
[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.

Issue (issue-choice-predicate):

There is no defined ordering for particles in a choice group. We need a better predicate, or a defined order.

Syntax: /sequence()[n] or /choice()[n] or /all()[n where the [n] may be absent if the value of n is 1 (as it always is for the all compositor).

5.2.12 Particle

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

5.2.13 Wildcard

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

[target namespace]
[name]
[schema component kind]If the wildcard is the {term} of some particle, then any, otherwise anyAttribute
[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.
Syntax: /any()[n] or /*[n] or /anyAttribute() or /@* where the [n] may be absent if the value of n is 1.

5.2.14 Attribute Use

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

5.2.15 Fundamental Facets

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

[target namespace]
[name]
[schema component kind]The facet name, one of ordered, bounded, cardinality, or numeric
[predicate]
Syntax: /ordered() or /bounded() or /cardinality() or /numeric()

5.2.16 Constraining Facets

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

[target namespace]
[name]
[schema component kind]The facet name, one of whiteSpace, minInclusive, maxInclusive, minExclusive, maxExclusive, totalDigits, fractionDigits, length, minLength, maxLength, pattern, or enumeration
[predicate]
Syntax: /whiteSpace() or /minInclusive() or /maxInclusive() or /minExclusive() or /maxExclusive() or /totalDigits() or /fractionDigits() or /length() or /minLength() or /maxLength() or /pattern() or /enumeration()

5.2.17 EBNF for Schema Component Path Syntax

Path EBNF
[3]   schema-component-path   ::=   step*
[4]   step   ::=   '/' ( attribute-step | element-step | simpleType-step | complexType-step | attributeGroup-step | group-step | identityConstraint-step | notation-step | annotation-step | modelGroup-step | wildcard-step | facet-step )
[5]   attribute-step   ::=   attribute-fullform | attribute-shortform
[6]   attribute-fullform   ::=   'attribute' '(' QName ')'
[7]   attribute-shortform   ::=   '@' QName
[8]   element-step   ::=    ( element-fullform | element-shortform ) predicate?
[9]   element-fullform   ::=   'element' '(' QName ')'
[10]   element-shortform   ::=   QName
[11]   simpleType-step   ::=   'simpleType' '(' QName? ')' predicate?
[12]   complexType-step   ::=   'complexType' '(' QName? ')'
[13]   attributeGroup-step   ::=   'attributeGroup' '(' QName ')'
[14]   group-step   ::=   'group' '(' QName ')'
[15]   identityConstraint-step   ::=   'identityConstraint' '(' QName ')'
[16]   notation-step   ::=   'notation' '(' QName ')'
[17]   annotation-step   ::=   'annotation' '()'
[18]   modelGroup-step   ::=   ('sequence' | 'choice' | 'all') predicate?
[19]   wildcard-step   ::=   wildcard-longform | wildcard-shortform
[20]   wildcard-longform   ::=    ( 'any' '()' predicate? ) | ('anyAttribute' '()')
[21]   wildcard-shortform   ::=    ( '*' predicate? ) | '@*'
[22]   facet-step   ::=    facet-name '()'
[23]   facet-name   ::=   'ordered' | 'bounded' | 'numeric' | 'cardinality' | 'whiteSpace' | 'minInclusive' | 'maxInclusive' | 'minExclusive' | 'maxExclusive' | 'totalDigits' | 'fractionDigits' | 'length' | 'minLength' | 'maxLength' | 'pattern' | 'enumeration'
[24]   predicate   ::=   '[' [0-9]+ ']'

Editorial note9-July-2003
Do we want to allow for elision of top-level sequence() or anon complexType()? e.g. abbreviate /complexType(ipo:Items)/sequence()/item/complexType()/sequence()/quantity as /complexType(ipo:Items)/item/complexType()/quantity or /complexType(ipo:Items)/sequence()/item/sequence()/quantity or even /complexType(ipo:Items)/item/quantity

5.3 Canonical Schema Component Paths

[Definition: Of the possible paths to a schema component, one of them is the canonical schema component path such that it captures the origin of it's schema component.]

Editorial note6-November-2003
We have to elaborate on the phrase 'origin of it's schema component'.

Each schema component that has any valid path to it will have exactly one canonical path, which should be the path with the fewest steps. Certain paths or traversals will be pruned to find the canonical path.

Generally speaking, traversal for a canonical path through the schema component graph will be cut off for any path to a named schema component that could be reached more expediciously from the schema-as-a-whole schema component.

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

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

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), and the last condition accounts for element and attribute declarations stemming from named model groups and attribute groups.

Editorial note5-November-2003
Note that we rely on certain changes to component model here wrt 1.0: the {identity constraint definitions} on the schema-as-a-whole component; decisions about {scope} for items arising from named model groups. Some of this will obviate certain of the issues below.

Issue (issue-ag-dups):

Traversal through the attribute group's {attribute uses} property is where you want to refer to, say, the foo attribute of the bar attribute group without reference to a specific complex type in which it is used. This can lead to multiple paths (this is OK). One of these paths is the canonical path. How to identify this canonical path?

Issue (issue-mg-dups):

Traversal through {model group} is where you want to refer to, say, the foo element of the bar model group without reference to a specific complex type in which it is used. This can lead to multiple paths (this is OK). One of these paths is the canonical path. How to identify this canonical path?

Issue (issue-facet-annotations):

enumeration and pattern have only one {annotation} even when they collapse several distinct elements (each with its own annotation) in the schema. So when you refer to that annotation, which one are you referring to? Which one is it in the component model?

Issue (issue-derived-cm-not-manifest):

ISSUE: "Inherited" portions of content model do not manifest. Suppose one type extends another type by adding additional terms to a sequence. In the schema component model there is no direct way to determine which terms in the sequence come from the base type: the inheritance is "compiled out" as it were. This will lead to multiple paths (this is OK). One of these paths is the canonical path. How to identify this canonical path?

Issue (issue-local-attr-dups):

A local attribute in a base type leads to multiple paths (this is OK): /complexType(baseType)/@attr and /complexType(derivedType)/@attr; former is the canonical path. How to identify this canonical path?

Issue (issue-derived-facet-dups):

Facets from base types lead to multiple paths (this is OK): /complexType(baseType)/minInclusive() and /complexType(derivedType)/minInclusive(); former is the canonical path. How to identify this canonical path?

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 /complexType(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>

5.3.1 Canonical Syntax

The concrete syntax provides for certain abbreviations, such as eliding the positional predicate when the position is 1, or using short forms for element and attribute declarations, uses, and wildcards. Canonical path syntax forbids all these abbreviations.

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

6 Canonical Schema Component Designators

Editorial note17-October-2003
TBD: LHS is probably just canonicalization of the URI, according to rules for that. OTOH, if this is a namespace which is not really a URI but just a string that quacks like a URI, canonicalization is identity. Need to spell out RHS canonicalization; if we canonicalize the namespace prefixes we can have string comparison. But comparison at the conceptual level is as easy as canonicalizing NS prefixes, and not sure it is worth defining such a procedure here, where we are treading outside our territory a bit.

7 Equality of Schema Component Designators

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

This definition of equality is in keeping with that suggested by current drafts of the update to RFC2396.

8 Examples

8.1 Example 1: Purchase Order from Primer

Editorial note1-October-2002
Need smaller illustrative examples. This is too hard to follow in the present form. 
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:po="http://www.example.com/PO1"
        targetNamespace="http://www.example.com/PO1"
        elementFormDefault="unqualified"
        attributeFormDefault="unqualified">

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

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

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

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

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

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

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

</xsd:schema>

This schema leads to following set of schema component designators:

#xscd(/annotation())
#xmlns(po=http://www.example.com/PO1) xscd(/po:purchaseOrder)
#xmlns(po=http://www.example.com/PO1) xscd(/po:comment)

#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:purchaseOrderType))
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:purchaseOrderType)/sequence()/shipTo)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:purchaseOrderType)/sequence()/billTo)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:purchaseOrderType)/sequence()/items)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:purchaseOrderType)/@orderDate)

#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:USAddress))
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:USAddress)/sequence()/name)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:USAddress)/sequence()/street)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:USAddress)/sequence()/city)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:USAddress)/sequence()/state)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:USAddress)/sequence()/zip)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:USAddress)/@country)

#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:Items))
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:Items)/sequence()/item)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:Items)/sequence()/item/complexType())
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:Items)/sequence()/item/complexType()/sequence()/productName)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:Items)/sequence()/item/complexType()/sequence()/quantity)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:Items)/sequence()/item/complexType()/sequence()/quantity/simpleType())
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:Items)/sequence()/item/complexType()/sequence()/quantity/simpleType()/maxExclusive())
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:Items)/sequence()/item/complexType()/sequence()/USPrice)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:Items)/sequence()/item/complexType()/sequence()/shipDate)
#xmlns(po=http://www.example.com/PO1) xscd(/complexType(po:Items)/sequence()/item/complexType()/@partNum)

#xmlns(po=http://www.example.com/PO1) xscd(/simpleType(po:SKU))
#xmlns(po=http://www.example.com/PO1) xscd(/simpleType(po:SKU)/pattern())

8.2 Example 2: Report Schema from Primer

<schema targetNamespace="http://www.example.com/Report"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:r="http://www.example.com/Report"
        xmlns:xipo="http://www.example.com/IPO"
        elementFormDefault="qualified">

 <!-- for SKU -->
 <import namespace="http://www.example.com/IPO"/>

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

 <element name="purchaseReport">
  <complexType>
   <sequence>
    <element name="regions" type="r:RegionsType">
     <keyref name="dummy2" refer="r:pNumKey">
      <selector xpath="r:zip/r:part"/>
      <field xpath="@number"/>
     </keyref>
    </element>

    <element name="parts" type="r:PartsType"/>
   </sequence>
   <attribute name="period"       type="duration"/>
   <attribute name="periodEnding" type="date"/>
  </complexType>

  <unique name="dummy1">
   <selector xpath="r:regions/r:zip"/>
   <field xpath="@code"/>
  </unique>

  <key name="pNumKey">
   <selector xpath="r:parts/r:part"/>
   <field xpath="@number"/>
  </key>
 </element>

 <complexType name="RegionsType">
  <sequence>
   <element name="zip" maxOccurs="unbounded">
    <complexType>
     <sequence>
      <element name="part" maxOccurs="unbounded">
       <complexType>
        <complexContent>
         <restriction base="anyType">
          <attribute name="number"   type="xipo:SKU"/>
          <attribute name="quantity" type="positiveInteger"/>
         </restriction>
        </complexContent>
       </complexType>
      </element>
     </sequence>
     <attribute name="code" type="positiveInteger"/>
    </complexType>
   </element>
  </sequence>
 </complexType>

 <complexType name="PartsType">
  <sequence>
   <element name="part" maxOccurs="unbounded">
    <complexType>
     <simpleContent>
      <extension base="string">
       <attribute name="number" type="xipo:SKU"/>
      </extension>
     </simpleContent>
    </complexType>
   </element>
  </sequence>
 </complexType>

</schema>

<schema targetNamespace="http://www.example.com/IPO"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:ipo="http://www.example.com/IPO">

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

 <!-- include address constructs -->
 <include
  schemaLocation="http://www.example.com/schemas/address.xsd"/>

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

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

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

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

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

</schema>

<schema targetNamespace="http://www.example.com/IPO"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:ipo="http://www.example.com/IPO">

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

 <complexType name="Address">
  <sequence>
   <element name="name"   type="string"/>
   <element name="street" type="string"/>
   <element name="city"   type="string"/>
  </sequence>
 </complexType>

 <complexType name="USAddress">
  <complexContent>
   <extension base="ipo:Address">
    <sequence>
     <element name="state" type="ipo:USState"/>
     <element name="zip"   type="positiveInteger"/>
    </sequence>
   </extension>
  </complexContent>
 </complexType>

 <complexType name="UKAddress">
  <complexContent>
   <extension base="ipo:Address">
    <sequence>
     <element name="postcode" type="ipo:UKPostcode"/>
    </sequence>
    <attribute name="exportCode" type="positiveInteger" fixed="1"/>
   </extension>
  </complexContent>
 </complexType>

 <!-- other Address derivations for more countries -->

 <simpleType name="USState">
  <restriction base="string">
   <enumeration value="AK"/>
   <enumeration value="AL"/>
   <enumeration value="AR"/>
   <!-- and so on ... -->
  </restriction>
 </simpleType>

 <!-- simple type definition for UKPostcode -->
 <simpleType name="UKPostcode">
   <restriction base="ipo:Postcode">
     <pattern value="[A-Z]{2}\d\s\d[A-Z]{2}"/>
   </restriction>
 </simpleType>
</schema>

This schema leads to following set of canonical schema component designators:

#xscd(/annotation()) /* there is an issue with annotation */

#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Address))
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Address)/sequence()/name)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Address)/sequence()/street)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Address)/sequence()/city)

#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:USAddress))
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:USAddress)/sequence()/sequence()[1]/name)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:USAddress)/sequence()/sequence()[1]/street)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:USAddress)/sequence()/sequence()[1]/city)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:USAddress)/sequence()/sequence()[2]/state)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:USAddress)/sequence()/sequence()[2]/zip)

#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:UKAddress))
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:UKAddress)/sequence()/sequence()[1]/name)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:UKAddress)/sequence()/sequence()[1]/street)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:UKAddress)/sequence()/sequence()[1]/city)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:UKAddress)/sequence()/sequence()[2]/postcode)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:UKAddress)/@exportCode)

#xmlns(ipo=http://www.example.com/IPO) xscd(/simpleType(ipo:USState))
#xmlns(ipo=http://www.example.com/IPO) xscd(/simpleType(ipo:USState)/enumeration())

#xmlns(ipo=http://www.example.com/IPO) xscd(/simpleType(ipo:UKPostcode))
#xmlns(ipo=http://www.example.com/IPO) xscd(/simpleType(ipo:UKPostcode)/pattern())

#xmlns(ipo=http://www.example.com/IPO) xscd(/ipo:purchaseOrder)
#xmlns(ipo=http://www.example.com/IPO) xscd(/ipo:comment)

#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:purchaseOrderType))
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:purchaseOrderType)/sequence()/shipTo)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:purchaseOrderType)/sequence()/billTo)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:purchaseOrderType)/sequence()/items)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:purchaseOrderType)/@orderDate)

#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Items))
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Items)/sequence()/item)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Items)/sequence()/item/complexType())
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Items)/sequence()/item/complexType()/sequence()/productName)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Items)/sequence()/item/complexType()/sequence()/quanity)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Items)/sequence()/item/complexType()/sequence()/quantity/simpleType())
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Items)/sequence()/item/complexType()/sequence()/quantity/simpleType()/maxExclusive())
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Items)/sequence()/item/complexType()/sequence()/USPrice)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Items)/sequence()/item/complexType()/sequence()/shipDate)
#xmlns(ipo=http://www.example.com/IPO) xscd(/complexType(ipo:Items)/sequence()/item/complexType()/@partNum)

#xmlns(ipo=http://www.example.com/IPO) xscd(/simpleType(ipo:SKU))
#xmlns(ipo=http://www.example.com/IPO) xscd(/simpleType(ipo:SKU)/pattern())

#xmlns(r=http://www.example.com/Report) xscd(/r:purchaseReport)
#xmlns(r=http://www.example.com/Report) xscd(/r:purchaseReport/complexType()/sequence()/r:regions)
#xmlns(r=http://www.example.com/Report) xscd(/r:purchaseReport/complexType()/sequence()/r:regions/identityConstraint(r:dummy2))
#xmlns(r=http://www.example.com/Report) xscd(/r:purchaseReport/complexType()/sequence()/r:parts)
#xmlns(r=http://www.example.com/Report) xscd(/r:purchaseReport/@period)
#xmlns(r=http://www.example.com/Report) xscd(/r:purchaseReport/@periodEnding)
#xmlns(r=http://www.example.com/Report) xscd(/r:purchaseReport/identityConstraint(r:dummy1))
#xmlns(r=http://www.example.com/Report) xscd(/r:purchaseReport/identityConstraint(r:pNumKey))

#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:RegionsType))
#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:RegionsType)/sequence()/r:zip)
#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:RegionsType)/sequence()/r:zip/complexType())
#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:RegionsType)/sequence()/r:zip/complexType()/sequence()/r:part)
#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:RegionsType)/sequence()/r:zip/complexType()/sequence()/r:part/complexType())
#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:RegionsType)/sequence()/r:zip/complexType()/sequence()/r:part/complexType()/@number)
#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:RegionsType)/sequence()/r:zip/complexType()/sequence()/r:part/complexType()/@quantity)
#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:RegionsType)/sequence()/r:zip/complexType()/@code)

#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:PartsType))
#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:PartsType)/sequence()/r:part)
#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:PartsType)/sequence()/r:part/complexType())
#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:PartsType)/sequence()/r:part/complexType()/simpleType())
#xmlns(r=http://www.example.com/Report) xscd(/complexType(r:PartsType)/sequence()/r:part/complexType()/@number)

9 Conformance

Editorial note1-October-2002
TBD

A Schema Component Properties

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.

ComponentPropertyUse
Attribute Declaration
{type definition}traversed
{annotation}traversed
{name}referenced
{target namespace}referenced
{scope}referenced
{value constraint}none
Element Declaration
{type definition}traversed
{identity-constraint definitions}traversed
{annotation}traversed
{name}referenced
{target namespace}referenced
{scope}referenced
{value constraint}none
{nillable}none
{substitution group affiliation}none
{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
{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
{name}referenced
{target namespace}referenced
Model Group Definition
{model group}traversed
{annotation}traversed
{name}referenced
{target namespace}referenced
Model Group
{particles}traversed
{annotation}traversed
{compositor}referenced
Particle
{term}traversed
{min occurs}none
{max occurs}none
Wildcard
{annotation}traversed
{namespace constraint}none
{process contents}none
Identity-constraint Definition
{annotation}traversed
{name}referenced
{target namespace}referenced
{identity-constraint category}none
{selector}none
{fields}none
{referenced key}none ??nc??
Notation Declaration
{annotation}traversed
{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
{identity constraint definitions}traversed
{annotations}traversed
Simple Type Definition
{base type definition}traversed
{facets}traversed
{fundamental facets}traversed
{item type definition}traversed
{member type definitions}traversed
{annotations}traversed
{name}referenced
{target namespace}referenced
{variety}referenced
{final}none
{primitive type definition}none ??NC??
Facets
{annotation}traversed
{value}none
{fixed}none

B Bibliography

RFC 2396
Tim Berners-Lee et al, RFC 2396: Uniform Resource Identifiers, Internet Engineering Task Force, 1995, available at http://www.ietf.org/rfc/rfc2396.txt.
XSD2
Paul V. Biron and Ashok Malhotra, XML Schema Part 2: Datatypes, World Wide Web Consortium, 2001, available at http://www.w3.org/TR/xmlschema-2/
XML
Tim Bray and Jean Paoli and C. M. Sperberg-McQueen, Extensible Markup Language (XML) 1.0, World Wide Web Consortium, 1998, available at http://www.w3.org/TR/REC-xml
FD
Allen Brown, Matthew Fuchs, Jonathan Robie, and Philip Wadler, XML Schema Part: Formal Description, World Wide Web Consortium, 2001, available at http://www.w3.org/TR/2001/WD-xmlschema-formal-20010925/
XPath
James Clark and Steve DeRose, XML path language (XPath) version 1.0, World Wide Web Consortium, 1999, available at http://www.w3.org/TR/xpath
XSD0
David C. Fallside, XML Schema Part 0: Primer, World Wide Web Consortium, 2001, available at http://www.w3.org/TR/xmlschema-0/
MFNUN
Matthew Fuchs, Rec'd NUNs, email to interest group, September 2002, available at http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Sep/0100.html (W3C Member-only link).
JRNUN
Jonathan Robie, Normalized Universal Names for XML Schema Declarations, working paper, 2001, available at http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Apr/att-0008/01-nuns.html (W3C Member-only link).
CXML
C. M. Sperberg-McQueen, Canonical XML forms for post-schema-validation infosets: A preliminary reconnaissance, working paper, 2002, available at http://www.w3.org/2002/04/xmlschema-psvi-in-xml (W3C Member-only link). See section 2.2, Names of types, in particular.
HTNUN1
Henry S. Thompson, XPointer NUN proposal, minutes of face to face meeting, October 2001, available at http://www.w3.org/XML/Group/2001/10/xml-schema-ftf-minutes#ab1b3b3b7b2b2 (W3C Member-only link).
HTNUN2
Henry S. Thompson, Straw man reflection-based NUN proposal, email to interest group, September 2002, available at http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Sep/0083.html (W3C Member-only link).
XSD1
Henry S. Thompson, David Beech, Murray Maloney and Noah Mendelsohn, XML Schema Part 1: Structures, World Wide Web Consortium, 2001, available at http://www.w3.org/TR/xmlschema-1/
PWNUN
Philip Wadler, a proposal for NUNs, working paper, 2001, available at http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001May/0016.html (W3C Member-only link).

C Issues

  1. [Issue 1: ] XPointer scheme in fact or in syntax only?

  2. [Issue 2: ] Choice particle predicate rule

  3. [Issue 3: ] Attribute group can lead to multiple paths. Which one is canonical?

  4. [Issue 4: ] Model group can lead to multiple paths. Which one is canonical?

  5. [Issue 5: ] Enumeration/pattern annotations

  6. [Issue 6: ] "Inherited" portions of content model lead to multiple paths. Which one is canonical?

  7. [Issue 7: ] "Inherited" local attribute declarations lead to multiple paths. Which one is canonical?

  8. [Issue 8: ] "Inherited" facets lead to multiple paths. Which one is canonical?