XML Schema: Component Designators

W3C Working Draft 09 January 2003

This version:
Latest version:
Mary Holstege, Invited Expert <holstege@mathling.com>
Asir S. Vedamuthu, webMethods <asirv@webmethods.com>


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

Status of this Document

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. It has been reviewed by the working group and the working group has agreed to publication. No part of this document has consensus of the working group.

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. A number of issues remain open and are called out in the draft; editorial notes call attention to some known shortcomings in this document and plans for improvement. 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.

A list of current W3C working drafts can be found 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".

Table of Contents

1 Introduction
2 Goals and Use Cases
    2.1 Candidate Requirements
    2.2 Use Cases
3 Terminology
4 Designators
    4.1 Designators Relative to a Schema
    4.2 Designator of a Schema
    4.3 Equality of Schema Component Designators
    4.4 Examples
5 Conformance


A Bibliography
B Issues
    B.1 Issues from this document
    B.2 Issues pulled from FD proposal

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.

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

  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.

We propose to divude 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.

  3. NUNs 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. Designators should be algorithmically generatable such that for each component there is one and only one designators.

    Editorial note1-October-2002
    "one and only one" is partially redundant and partially contradictory. This is really a separate point on predictability of the relation between the schema and the NUNs. rand() is an algorithm, after all. So this needs rephrasing, big time. Part of the desired predictability is also expressed above and part below. Maybe we don't even need this as a separate point.
  4. Designators should be parsable with compositional semantics (or, in other words, they should have expressive notation).

  1. Designators should be URIs. ?URIReferences?

    Editorial note1-October-2002
    Do they need to be resolvable? If they look resolvable (i.e. http://...) to what do they resolve? What is the MIME type? More than one MIME type?
  2. Designators should work well in a RDDL environment.

    Editorial note1-October-2002
    Concretely, what does this mean?
  3. Editorial note1-October-2002
    Do we want statements of compatibility with XPointer? XPath?
  1. There should be a formal specification of what constitutes a legal designator.

  2. NUNs should allow users of NUNs 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: Call 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.
  1. It is not a requirement that it be possible to construct designators to refer to arbitrary schema components without any knowledge of schema internals.

  2. It is not a requirement that we 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.

  3. NUNs do not need to ... compensate for namespace validation?

    Editorial note1-October-2002
    (do not need to what? this was not present in the minutes)
  4. 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

Editorial note1-October-2002
This list also needs some reorganization and clean-up. It seems to me that some of these use cases are really about pointing at particular elements in particular schema documents, for which we already have XPath/XPointer. I would like such use cases ruled out of scope. Some of these overlap a little with the PSVI use cases document also.
Type references
  • Identifying types for TREAT AS (in Query) specifically wrt anonymous and local types.

  • Identifying types for function signatures (in Query)

  • Describing type of an expression (in Query)

  • Source code tests of type equivalence.

Uncategorized hodgepodge
  • Data integration scenario creating new schema in which using things that are not globally declared or for which there is more than one declaration.

  • RDF assertions about x [with and without detailed knowledge of schema internals]

    Editorial note1-October-2002
    "without" can be ruled out by non-goals
  • Formal description requires unique identifier for each declaration and definition used within the context of the validation episode. HT objects to this as a type error as in declarations and definitions are not used in validation episodes, components do. ISSUE:

    • identify each component

    • identify each declaration/definition

    • identify each schema document element

  • Writing error messages

  • Enumerate dependencies in schema document

  • Miscellaneous text-based uses within schema-based tools:

    • input/output

    • user reports

    • glue/interfaces among

  • Schema documentation

  • Commentary on schemas, e.g. best practices documents

  • It should be possible to supply NUNs 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

4 Designators

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

Editorial note1-October-2002
Tighten up this description so that it is more like an XPointer scheme, which may or may not encompass all of the "right hand side" (likely not: you'll need xmlns() in there too). Still need to work out what the designator for an assembled schema is.

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?

4.1 Designators Relative to a Schema

Schema component designators can be regarded as being constructed step-by-step by traversing the schema component properties, starting at the schema-as-a-whole schema component. The schema components form a graph, and there may be more than one path to a particular schema component. We will first describe the general procedure for traversing the schema component graph to construct schema component designators, and then define which path is the correct or canonical path.

Conceptually, a schema component designator is formed from a series of [designator step] pieces, each of which corresponds to a particular schema component along the path from the schema-as-a-whole schema component. Each designator step has a concrete syntactic representation, which may be an empty string. That is, some logical steps have no syntactic reflection.

Each [designator 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.

Editorial note1-October-2002
It remains to be seen whether this conceptual model helps or hinders presentation. Try it and see if it helps.

In general the syntax of a step of the schema component designator 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.

4.1.1 EBNF for Relative Schema Component Designator Syntax

Editorial note1-October-2002
Need to fix this: should just define xs-nun XPointer scheme and leave xmlns definition out of it. Also, need a better name than xs-nun. xschema? c.f. http://www.w3.org/TR/2002/WD-xptr-framework-20020710/#NT-pointer
[1]   schema-component-designator   ::=   ('xmlns(' xmlnsschemedata ')' S)* 'xs-nun' '(' designator-step* ')'
[2]   designator-step   ::=   '/' (fullform | shortform) predicate?
[3]   fullform   ::=   schema-component-kind '(' QName? ')'
[4]   shortform   ::=   element-shortform | attribute-shortform | any-shortform | anyAttribute-shortform
[5]   element-shortform   ::=   QName
[6]   attribute-shortform   ::=   '@'QName
[7]   any-shortform   ::=   '*'
[8]   anyAttribute-shortform   ::=   '@*'
[9]   predicate   ::=   '[' position ']'

Generally speaking, traversal 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. In particular, if a schema component meets any of the following criteria, traversal to that schema component to generate a designator is forbidden unless traversal is directly from the schema-as-a-whole schema component:

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

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

4.1.2 Schema-as-a-whole Component

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

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

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 [designator step]:

{type definitions}
{attribute declarations}
{element declarations}
{attribute group definitions}
{model group definitions}
{notation declarations}

4.1.3 Attribute Declaration

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

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

Traversal through the schema component graph occurs through either the {type definition} or {annotation} properties by taking that schema component as the basis for the next [designator step].

4.1.4 Element Declaration

The [designator 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. It will always be present in the canonical form.

Traversal through the schema component graph occurs through the {type definition}, {annotation}, or {identity constraint definitions} properties.

4.1.5 Simple Type Definition

The [designator 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 {variety} is union and the [name] is empty, the pair {position, n} where n is the position of the simple type definition among {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 simple type definition is not union and may be absent if the value of n is 1. It will always be present in the canonical form.

Issue (issue_simpletype_predicate):

Is the predicate rule good enough? Need to look at more examples to be sure.

Traversal through the schema component graph occurs through the {facets}, {fundamental facets}, {annotation}, {item type definition}, or {member type definitions} properties. properties.

4.1.6 Complex Type Definition

The [designator 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
Syntax: /complexType(prefix:name) where prefix:name will be empty for anonymous types.

Traversal through the schema component graph occurs through the {attribute uses}, {attribute wildcard}, and {annotation} properties. Traversal will also proceed through the particle of the {content type} property if a content model is present, or through the {content type} property if it is a simple type definition and the {name} property of that simple type definition is absent. That is, traversal will continue for anonymous simple type definitions and terminate for named ones, as the named ones will be referenced directly from the {type definitions} property of the schema-as-a-whole schema component.

4.1.7 Attribute Group Definition

The [designator 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
Syntax: /attributeGroup(prefix:name)

Traversal through the schema component graph continues through the members of the {attribute uses} as well as through the {attribute wildcard} and {annotation} property.

Issue (issue_ag_dups):

Traversal through the {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 duplicate NUNs. We need to fix that.

4.1.8 Model Group Definition

The [designator 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
Syntax: /group(prefix:name)

Traversal through the schema component graph continues through the {model group} and {annotation} properties.

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 duplicate NUNs. We need to fix that.

4.1.9 Identity-constraint definition

The [designator 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
Syntax: /identityConstraint(prefix:name)

Traversal through the schema component graph occurs through the {annotation} property.

4.1.10 Notation declaration

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

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

Traversal through the schema component graph occurs through the {annotation} property.

4.1.11 Annotation

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

[target namespace]
[schema component kind]annotation

Issue (issue_annotation_predicate):

We will need a predicate for those places where more than one annotation can adhere. There is neither a logical canonical order so position will not do. We have no good ideas here.

Syntax: /annotation()

Traversal through the schema component graph ends with an annotation.

Issue (issue_annotation_traverse):

Is this right? We may want to allow regular XPath traversal of the IIs under annotation via {application information}, {user information}, and {attributes} or we may want to allow for referring to those pieces, e.g. /annotation()/user-information()/....

4.1.12 Model Group

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

[target namespace]
[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.
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). It will always be present in the canonical form.

Traversal through the schema component graph occurs through the {annotation} and {particles} properties.

4.1.13 Particle

Issue (issue_particles_skipped):

Current proposal traverses over particles but doesn't record them as a step. Is that a problem?

A particle does not directly contribute a [designator step]. Traversal through the schema component graph continues through the {term} property.

Issue (issue_derived_cm_not_manifest):

ISSUE: "Inherited" portions of content model 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. Do we need to distinguish these cases in the designators, and if so how?

4.1.14 Wildcard

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

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

Issue (issue_wildcard_predicate):

Would NS selectors make a better predicate here? What would that look like? Would it be good enough?

Syntax: /any()[n] or /*[n] or /anyAttribute() or /@* where the [n] may be absent if the value of n is 1. It will always be present in the canonical form.

Issue (issue_wildcard_dups):

Can get duplicate NUNs. Need to fix.

Traversal through the schema component graph occurs through the {annotation} property.

4.1.15 Attribute Use

The attribute use schema component leads to a [designator step] whose properties derive from the {attribute declaration} of that attribute use.

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

Issue (issue_au_vs_ad):

Need to be sure that attribute use designators cannot be confused with attribute declaration designators. The rules here are not quite right: Where an attribute use has a global attribute declaration, we want to pull the information from the attribute declaration and then stop. Otherwise we want to get the information from the attribute use and then skip ahead through the attribute declaration without creating another step for it. This seems to produce the more intuitive results in the designator, although it does mean you cannot separately refer to the attribute use and its anonymous in-line attribute declaration. Is this a problem?

Traversal through the schema component graph continues through the {attribute declaration} property.

4.1.16 Fundamental Facets

Issue (issue_fundamental_facets):

Do we really need to be able to refer to fundamental facets in this way?

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

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

Traversal through the schema component graph ends with a fundamental facet.

4.1.17 Constraining Facets

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

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

Traversal through the schema component graph occurs through the {annotation} property.

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?

4.2 Designator of a Schema

Editorial note1-October-2002
Need to look at RDDL 'natures' here; in particular their answers for HTML are very interesting. Wondering if WebDAV plays here too in some way: in some sense RDDL is a collection with referenced members with properties.

What we want is some kind of URI that can provide a reliable context such that the relative designators for the schema component set it refers to can be compared simply as strings. It is easier to say what it is not, rather than what it is:

NOT a target namespace

The same namespace URI refers to a class of schemas, some of which may have different incompatible component graphs leading to different schema component designators; also, more than one target namespace may be involved; also, no target namespace may be involved.

NOT a schema location

Again, there may be more than one schema location involved. Could have many schema locations for same schema; processor is free to use whatever means it likes to obtain them. Cannot reliably refer to anything if it is bound to local file system via schema cache, for example.

4.3 Equality of Schema Component Designators

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

Two schema component designators are equal i they are absolute and their schema designator designates the same schema or if they are relative to the same schema, and they have the same number of designator steps, and each step in one designator is equal to the corresponding step in the other. Designator steps are equal if all of their properties have the same value.

Issue (issue_equality):

Need to spell this out more, e.g. wrt canonicalization.

4.4 Examples

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

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

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

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

 <xsd:complexType name="PurchaseOrderType">
   <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:attribute name="orderDate" type="xsd:date"/>

 <xsd:complexType name="USAddress">
   <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:attribute name="country" type="xsd:NMTOKEN"

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

 <!-- 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}"/>


This schema leads to following set of schema component designators:

#xmlns(po=http://www.example.com/PO1) xs-nun(/po:purchaseOrder)
#xmlns(po=http://www.example.com/PO1) xs-nun(/po:comment)

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

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

#xmlns(po=http://www.example.com/PO1) xs-nun(/complexType(po:Items))
#xmlns(po=http://www.example.com/PO1) xs-nun(/complexType(po:Items)/sequence()/item)
#xmlns(po=http://www.example.com/PO1) xs-nun(/complexType(po:Items)/sequence()/item/complexType())
#xmlns(po=http://www.example.com/PO1) xs-nun(/complexType(po:Items)/sequence()/item/complexType()/sequence()/produ
#xmlns(po=http://www.example.com/PO1) xs-nun(/complexType(po:Items)/sequence()/item/complexType()/sequence()/quant
#xmlns(po=http://www.example.com/PO1) xs-nun(/complexType(po:Items)/sequence()/item/complexType()/sequence()/quantity/simpleType())
#xmlns(po=http://www.example.com/PO1) xs-nun(/complexType(po:Items)/sequence()/item/complexType()/sequence()/quantity/simpleType()/maxExclusive())
#xmlns(po=http://www.example.com/PO1) xs-nun(/complexType(po:Items)/sequence()/item/complexType()/sequence()/USPrice)
#xmlns(po=http://www.example.com/PO1) xs-nun(/complexType(po:Items)/sequence()/item/complexType()/sequence()/shipDate)
#xmlns(po=http://www.example.com/PO1) xs-nun(/complexType(po:Items)/sequence()/item/complexType()/@partNum)

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

4.4.2 Example 2: Report Schema from Primer

<schema targetNamespace="http://www.example.com/Report"

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

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

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

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

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

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

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

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

<schema targetNamespace="http://www.example.com/IPO"

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

 <!-- include address constructs -->

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

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

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

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

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

<schema targetNamespace="http://www.example.com/IPO"

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

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

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

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

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

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

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

This schema leads to following set of schema component designators:

#xs-nun(/annotation()) /* there is an issue with annotation */

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

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

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

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

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

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

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

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

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

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

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

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

5 Conformance

Editorial note1-October-2002

A 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.
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/
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
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/
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
David C. Fallside, XML Schema Part 0: Primer, World Wide Web Consortium, 2001, available at http://www.w3.org/TR/xmlschema-0/
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).
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).
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.
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).
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).
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/
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).

B Issues

B.1 Issues from this document

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

  2. [Issue 3: ]Attribute group duplicate designators

  3. [Issue 2: ]Simple type definition predicate rule

  4. [Issue 4: ]Model group duplicate designators

  5. [Issue 5: ]No good predicate for multiple annotations

  6. [Issue 6: ]Traversing within annotation

  7. [Issue 7: ]Cannot refer to particles per se

  8. [Issue 8: ]"Inherited" portions of content model not manifest

  9. [Issue 9: ]Better predicate for attribute wildcards

  10. [Issue 10: ]Wildcard duplicate designators

  11. [Issue 11: ]Sanity: make sure attribute use/attribute declaration kept distinct as needed

  12. [Issue 12: ]Refer to fundamental facets?

  13. [Issue 13: ]Enumeration/pattern annotations

  14. [Issue 14: ]Clarification of equality wrt canonicalization

B.2 Issues pulled from FD proposal

  1. [F-1] http://www.w3.org/2001/03/xmlschema-fd-issues.html#schema-or-schemadoc

    Do the URIs in normalized universal names refer to schemas? to schema documents (or analogous resources)? to namespaces?

    Category - clarification

    NUN is a URI. And, it represents the normalized universal name of a schema component (neither schema nor schema documents)

    MH: No longer relevant. Will discuss under general issue of what the "lhs" of the URI is.

  2. [F-2] http://www.w3.org/2001/03/xmlschema-fd-issues.html#possible-id-conflict

    Assumptions and possible interactions with MIME types and other fragment-identifier syntaxes must be clarified. It may be useful to provide an xschema wrapper analogous to the existing xpointer wrapper to avoid conflicts when a schema is served as text/xml.

    Category - defect

    Proposed NUN representation uses a scheme, say xs-nun() and leverages on xmlns(), and will not conflict with bare ids

    MH: No longer relevant.

  3. [F-3] http://www.w3.org/2001/03/xmlschema-fd-issues.html#deref-uri

    When the URI in a normalized unique name is an http URL, is it (should / may / must it be) dereferenceable?

    Category - clarification

    This is a question for the WG, [NUNs-5] at http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Sep/0227.html (W3C Member-only link)

  4. [F-4] http://www.w3.org/2001/03/xmlschema-fd-issues.html#nun-ambiguity

    The short forms given for normalized universal names are ambiguous in some cases. Should this ambiguity be eliminated? If so, how?

    Category - defect

    I am not aware of any ambiguous representation in our proposed representation (both short/long lexical forms)

    MH: Not relevant to current proposal. Already a requirement.

  5. [F-6] http://www.w3.org/2001/03/xmlschema-fd-issues.html#missing-targetNS

    The symbol i is described as ranging over URIs (or URI references); it appears to need a broader range in order to handle schema documents with no target namespace.

    Category - defect

    Proposed representation uses xmlns() scheme to declare multiple namespaces and use prefixed names to identify a distinct target namespace. Absence of a prefix refers to no target namespace.

    MH: Not relevant.

  6. [F-13] http://www.w3.org/2001/03/xmlschema-fd-issues.html#nun-local

    If local elements are unqualified (instead of being qualified with the same namespace name of the type to which they are local), e.g. as in


    then what should the normalized name of the b element be?

    The draft says or implies that the normalized name of the f element is {a}#e::f, and that of the b element is {a}#e::f/e::b. But the rule says that only works if they are in the same namespace, but in unqualified case that isn't so.

    Category - defect

    Proposed approach representation uses xmlns() scheme to declare multiple namespaces (including absent namespace) and use prefixed names to identify a distinct target namespace. Absence of a prefix refers to no target namespace.

    MH: I don't think it is quite that simple. We need to look at this case closely.

  7. [F-28] http://www.w3.org/2001/03/xmlschema-fd-issues.html#nun-doc

    The work on naming conventions seems to have wide potential application; can/should it be published separately?

    Category - goal


    MH: Moot.

  8. [F-36] http://www.w3.org/2001/03/xmlschema-fd-issues.html#rose

    Issue (MSM): There is no formal specification of what constitutes a legal name in this naming scheme. (See proposed grammar below.) MF observes that this is not quite true: there is a formal grammar on page 9. Perhaps it needs to be revised.

    Category - inadequate

    Proposed draft will have a formal specification using EBNF

    MH: Moot.

  9. [F-37] http://www.w3.org/2001/03/xmlschema-fd-issues.html#nun-completeness

    Issue (MSM): The naming scheme provided does not provide names for all the nameable components of schemas. In discussion we established that the grammar provided later in the document does actually show how to produce names for all nameable components, but the examples in section 2.1 don't illustrate names for all component types.

    Category - defect

    Proposed approach will have a mechanism to name all the nameable components of schemas plus more.

    MH: This is one of the goals in the first section.

  10. [F-42] http://www.w3.org/2001/03/xmlschema-fd-issues.html#aliasing

    Issue (MSM): Is aliasing possible? Should it be? I.e. should it be possible to construct two names for the same construct? Editorially, the document needs to say up front whether it is possible or not. (It becomes apparent that the intention is for aliasing not to be possible, but this should be said earlier and more explicitly.) Substantively, the WG needs to decide whether aliasing should be possible.

    Matthew Fuchs observed that the document is currently designed with the assumption of a 1:1 mapping between NUNs (normalized univeral names) and constructs. Names are thus currently both unambiguous (except for the noted ambiguity of some short forms) and unique. MSM noted that allowing aliasing would simplify use of the NUNs outside of MSL (as described in his commentary), and defining one name as the canonical name would preserve the 1:1 mapping where needed. He observed that here, again, we must ask whether usability outside of MSL is a requirement or not.

    David Beech asked whether the naming convention would be the same if one were using the structures component model rather than the MSL component model? Or are the names defined here inseparable from the MSL model? Matthew Fuchs said he thought they would be the same; MSM concurred.

    Category - issue/requirement/convenience/usability/readability

    Proposed approach has one and only NUN for a component. It may have multiple lexical representations using long or short form.

    MH: THis is not an issue, but one of our goals. Need to define a canonical form.

  11. [F-55] http://www.w3.org/2001/03/xmlschema-fd-issues.html#realnuns

    ISSUE (Thompson) (already in list?): Either we should explicitly forestall any understanding or second guessing that this is a proposal for real universal names, or else we should step up to the question of producing real universal names, and look at questions like escaping URIs etc.

    Category - goal

    Indeed, we are stepping up and producing real universal names. And, it must address escaping URIs, etc.

  12. [F-56] http://www.w3.org/2001/03/xmlschema-fd-issues.html#anonstar

    ISSUE (Holstege): the use of '*' for anonymous is endlessly confusing.

    Category - usability

    Proposed approach does not use the character '*' to represent anonymous types. Anonymous types are represented as complexType() or simpleType() - in other words, absence of a QName.

    MH: Moot.

  13. [F-68] http://www.w3.org/2001/03/xmlschema-fd-issues.html#a.slash.b

    ISSUE. The collision between the interpretation of a/b in XPath (an element of type b inside an element of type a) and that given here (an element of type b local to top-level complex type a) also seems unfortunate; it would be better if the short forms avoided such collisions.

    Category - usability

    Proposed approach uses a new scheme, say xs-nun(). And, even in short forms, I do not foresee a construct such as a/b (an element of type b inside an element of type a) - am really confused by this example. To the extent that I understand, that is element b inside a, will be represented as a/complexType()/b (assuming anonymous complex type).

    MH: We should perhaps look at using syntax of XPath axes, however.