Copyright ©2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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.
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".
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
This document defines a system for designating XML Schema components. Part 1 of the W3C XML Schema recommendation [XSD1] defines these schema components. Section 2.2 lays out the inventory of schema components into three classes:
Primary components: simple and complex type definitions, attribute declarations, and element declarations
Secondary components: attribute and model group definitions, identity-constraint definitions, and notation declarations
"Helper" components: annotations, model groups, particles, wildcards, and attribute uses
In addition there is a master schema component, the schema component representing the schema as a whole.
Finally, there are schema components for the facets defined in Part 2 of the W3C XML Schema recommendation [XSD2]:
Fundamental Facets: ordered, bounded, cardinality, numeric
Constraining Facets: whiteSpace, minInclusive, maxInclusive, minExclusive, maxExclusive, totalDigits, fractionDigits, length, minLength, maxLength, pattern, enumeration
At first blush, a QName (prefix:localname) may seem sufficient to the task of designating any schema component. This is incorrect for various reasons:
A QName is only meaningful in the context of particular namespace bindings so that the QName can be resolved to a particular extended name, or {namespace name, local name} pair.
The same extended name can be used in a particular schema to refer to an element declaration, an attribute declaration, a complex type definition, a simple type definition, a model group definition, an attribute group definition, an identity constraint definition, or a notation declaration.
Locally scoped element and attribute declarations cannot be uniquely named by an extended name.
Anonymous type definitions have no extended name, or they have an extended name that is dependent upon the particular schema processor interpreting the schema.
Certain schema components (annotation, particle, wildcard) are purely subordinate to some other schema component, and have no name of their own.
Certain schema components (attribute use and model group) are subordinate to some other schema component, and any name they might be construed to have is a reference to some other schema component (attribute declaration and model group definition, respectively).
The schema-as-a-whole schema component has no name at all.
The redefinition schema composition feature creates the situation where there are two variants of the 'same' schema component, both with the same name, one of which is derived from the other. If it is necessary to be able to name the base component, the same name cannot be used for both.
A key technical challenge to obtaining a useful system of naming XML Schema components is to address these issues or decide that certain cases need not be addressed.
Of the various proposals considered [FD], [JRNUN], [PWNUN], [CXML], [HTNUN1], [HTNUN2], [MFNUN], two essential approaches stand out:
Designators that navigate or reference some kind of canonicalized XML schema document representing an assembled XML Schema using standard XPath syntax
Designators that navigate or reference schema components in an assembled XML Schema:
Using an XPath-like syntax with special axes relevant to schema components, or
Using an extended QName syntax, or
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.
Designators should be unambiguous, designating exactly one component within a schema.
It should be possible to designate any schema component within a schema.
NUNs should provide (or assure) a URI for the unique identification of a schema.
If there is more than one designator for a construct, there should be exactly one canonical form of the designator.
Designators should be human-readable.
Given a designator, it should be possible to get the extended name for the designated component, if one exists for that component.
Designators should be algorithmically generatable such that for each component there is one and only one designators.
| Editorial note | 1-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. | |
Designators should be parsable with compositional semantics (or, in other words, they should have expressive notation).
Designators should be URIs. ?URIReferences?
| Editorial note | 1-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? | |
Designators should work well in a RDDL environment.
| Editorial note | 1-October-2002 |
| Concretely, what does this mean? | |
| Editorial note | 1-October-2002 |
| Do we want statements of compatibility with XPointer? XPath? | |
There should be a formal specification of what constitutes a legal designator.
NUNs should allow users of NUNs to make or to elide the distinction between schemas and schema documents.
| Editorial note | 1-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. | |
It is not a requirement that it be possible to construct designators to refer to arbitrary schema components without any knowledge of schema internals.
It is not a requirement 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.
NUNs do not need to ... compensate for namespace validation?
| Editorial note | 1-October-2002 |
| (do not need to what? this was not present in the minutes) | |
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.
| Editorial note | 1-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. | |
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.
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 note | 1-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
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 note | 1-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. | |
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?
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 note | 1-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.
| Editorial note | 1-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
The [designator step] for the schema-as-a-whole schema component has the properties:
| [target namespace] | |
| [name] | |
| [schema component kind] | schema |
| [predicate] |
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}
{annotations}
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 |
| [predicate] |
/attribute(prefix:name) or /@prefix:nameTraversal 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].
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. |
/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.
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} |
/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.
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 |
| [predicate] |
/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.
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 |
| [predicate] |
/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.
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 |
| [predicate] |
/group(prefix:name)Traversal through the schema component graph continues through the {model group} and {annotation} properties.
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 |
| [predicate] |
/identityConstraint(prefix:name)Traversal through the schema component graph occurs through the {annotation} property.
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 |
| [predicate] |
/notation(prefix:name)Traversal through the schema component graph occurs through the {annotation} property.
The [designator step] for an annotation schema component has the properties:
| [target namespace] | |
| [name] | |
| [schema component kind] | annotation |
| [predicate] |
/annotation()Traversal through the schema component graph ends with an annotation.
The [designator 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. |
/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.
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?
The [designator 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.
|
/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.Traversal through the schema component graph occurs through the {annotation} property.
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 |
| [predicate] |
/attribute(prefix:name) or
/@prefix:nameNeed 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.
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] | |
| [name] | |
| [schema component kind] | The facet name, one of ordered,
bounded, cardinality, or numeric |
| [predicate] |
/ordered() or /bounded() or /cardinality()
or /numeric()Traversal through the schema component graph ends with a fundamental facet.
The [designator 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] |
/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.
| Editorial note | 1-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:
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.
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.
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.
| Editorial note | 1-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:
#xs-nun(/annotation()) #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 ctName) #xmlns(po=http://www.example.com/PO1) xs-nun(/complexType(po:Items)/sequence()/item/complexType()/sequence()/quant ity) #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())
<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 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)
[Issue 1: ]XPointer scheme in fact or in syntax only?
[Issue 3: ]Attribute group duplicate designators
[Issue 2: ]Simple type definition predicate rule
[Issue 4: ]Model group duplicate designators
[Issue 5: ]No good predicate for multiple annotations
[Issue 6: ]Traversing within annotation
[Issue 7: ]Cannot refer to particles per se
[Issue 8: ]"Inherited" portions of content model not manifest
[Issue 9: ]Better predicate for attribute wildcards
[Issue 10: ]Wildcard duplicate designators
[Issue 11: ]Sanity: make sure attribute use/attribute declaration kept distinct as needed
[Issue 12: ]Refer to fundamental facets?
[Issue 13: ]Enumeration/pattern annotations
[Issue 14: ]Clarification of equality wrt canonicalization
[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.
[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.
[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)
[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.
[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.
[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
<a:f>
<b/>
</a:f>
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.
[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
Indeed
MH: Moot.
[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.
[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.
[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.
[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.
[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.
[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.