Copyright ©2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document contains a list of requirements and desiderata for version 1.1 of XML Schema.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This is a W3C Working Draft for review by W3C Members and other interested parties. It is a draft document and may be updated, replaced or made obsolete 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". This is work in progress and its publication does not imply endorsement by the W3C membership.
Since the XML Schema Recommendation (Part 0: Primer, Part 1: Structures, and Part 2: Datatypes) was first published in May, 2001, it has gained acceptance as the primary technology for specifying and constraining the structure of XML documents. Users have employed XML Schema for a wide variety of purposes in many, many different situations. In doing so, they have uncovered some errors and requested some clarifications. They have also requested additional functionality.
Most of the errors and clarifications are addressed in the published errata and will be integrated into XML Schema 1.0 Second Edition, to be published shortly. Additional functionality and any remaining errors and clarifications will be addressed in XML Schema 1.1 and XML Schema 2.0.
This document discusses the requirements for version 1.1 of XML Schema.
The requirements included in this document were culled from public and member-only messages sent to the XML Schema Working Group. Each message was acknowledged. The requirements were then discussed by the Working Group and accepted requirements were classified into the three categories described in 1 Introduction.
It is the intention of the Working Group that this requirement gathering and classification should continue and that updated versions of this document should be published from time to time. This is not a Last-Call publication of this Working Draft.
This document has been produced by the W3C XML Schema Working Group as part of the W3C XML Activity. The authors of this document are the members of the XML Schema Working Group.
Patent disclosures relevant to this specification may be found on the XML Schema Working Group's patent disclosure page at http://www.w3.org/2002/11/xml-schema-IPR-statements.html.
Please report comments on this document to www-xml-schema-comments@w3.org (archive). A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
1 Introduction
2 Structures Requirements and Desiderata
2.1 Complex Types
2.1.1 Requirements
2.1.2 Desiderata
2.1.3 Opportunistic Desiderata
2.2 Constraints and Keys
2.2.1 Requirements
2.2.2 Desiderata
2.2.3 Opportunistic Desiderata
2.3 PSVI
2.3.1 Requirements
2.3.2 Desiderata
2.4 Restrictions
2.4.1 Requirements
2.5 Structures (General)
2.5.1 Desiderata
2.5.2 Opportunistic Desiderata
2.6 Substitution Groups
2.6.1 Requirements
2.6.2 Desiderata
2.7 Wildcards
2.7.1 Requirements
2.7.2 Opportunistic Desiderata
3 Datatypes Requirements and Desiderata
3.1 Datatypes (General)
3.1.1 Requirements
3.1.2 Desiderata
3.1.3 Opportunistic Desiderata
3.2 Date and Time Types
3.2.1 Requirements
3.2.2 Desiderata
3.3 Numeric Types
3.3.1 Requirements
3.3.2 Desiderata
3.3.3 Opportunistic Desiderata
This document contains a list of requirements and desiderata for XML Schema 1.1. These issues have been collected from e-mail lists and minutes of telcons and meetings, as well as from the various issues lists that the XML Schema Working Group has created during its lifetime. Links are provided for further information.
The items in this document are divided into three categories:
A requirement must be met in XML Schema 1.1.
A desideratum should be met in XML Schema 1.1.
An opportunistic desideratum may be met in XML Schema 1.1.
Clarify the expected processor behavior if an attribute has both use="prohibited", and a fixed value specified.
See (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Sep/0122.html .
We need to be clear where the XML Schema spec depends on component identity. We need a language to talk about identity of types, in general, and particularly with respect to anonymous types. Can an inherited type have an anonymous type? Are anonymous types that appear multiple types in a model group the same type?
See (member-only link) minutes of 10/24 telcon .
Clean up named model group syntax and component.
See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000OctDec/0339.html .
Change the XML representation (and possibly the component structure) of local element declarations to at least allow, if not require, all particles to be references, with scope, i.e. put the local declarations directly under <complexType>
Proposal
Provide a [schema normalized value] for all valid element infoitems, not just those of simple type, and address the question of typing the characters in mixed content.
Relax the constraint that a complex type may contain at most one attribute of type ID.
See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0069.html .
Proposal
The XML representation for field and selector allows an annotation, but there is no schema component to which this annotation can adhere. This inconsistency must be resolved.
See http://www.w3.org/2001/05/xmlschema-rec-comments#pfiIdConstrAnnot : R-46.
Resolve the issues associated with restricting types whose elements include identity constraints. Specifically, (1) the rule must changed to state that the restricted type must have a superset rather than a subset of identity constraints, (2) the term superset must be clearly defined, and (3) there must be a way to redefine identity constraints in the restricted type without causing duplicate name problems.
See http://www.w3.org/2001/05/xmlschema-rec-comments#pfiIdConsRestrict : R-94.
Add the ability to define and enforce co-constraints on attribute values, or on attribute values and sub-elements. For example, if attribute a has value foo, the attribute b must have one of the values fuzz, duz, or buzz; but if attribute a has value bar, the attribute b must have one of the values car, far, or tar. Or: if attribute href occurs, the element must be empty; if it does not occur, then it must have type phrase-level-content.
See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000OctDec/0040.html : LC-193 Response.
Key constraints to restrict which element types can be pointed to: Allow a schema author use key constaints to specify that a value (which otherwise behaves like an SGML or XML ID) is restricted to pointing at one (or more) particular element type(s)?
See (member-only link) http://www.w3.org/XML/Group/xmlschema-current/lcissues.html#typed-refs : LC-151.
Revise the derivation of complex-type restriction so as to eliminate the problems with pointless occurrences. Currently, it eliminates some derivations that should otherwise be valid.
See http://www.w3.org/2001/05/xmlschema-rec-comments#pfipointless : R-24.
Proposal
Revise the particle derivation rules so as to eliminate the problems with choice/choice rules.
See http://www.w3.org/2001/05/xmlschema-rec-comments#pfichoicechoice : R-42.
Remove the current rules on derivation by restriction; define legal restrictions in terms of their effect on the language, not in terms of a structural relationship between the base type and the derived type.
See (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2001May/0018.html .
Define an algorithm for generating a URI for any construct in a schema (or, possibly, in a schema document), thus making schema constructs first-class objects in the Web. Minimally the algorithm should cover element( type)s, attributes, simple types, complex types, and notations. Optionally it may also cover other constructs such as named groups and items in enumerations of legal values.
See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0025.html .
Address localization concerns regarding Part 1: Structures.
See (member-only link) http://www.w3.org/XML/Group/xmlschema-current/lcissues.html#i18n-str-misdirected : LC-206.
Specify a manner in which schema documents can be included in-line in instances.
See (member-only link) http://www.w3.org/XML/Group/xmlschema-current/issues.html#inlineSchemaInfo : Issue 42.
Improve interaction between substitution group exclusions and disallowed substitutions in the element component.
See (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Apr/0049.html .
Allow an element declaration to be in more than one substitution group.
See (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2002Sep/0016.html .
Address problems with the interaction between wildcards and substitution groups. Specifically, resolve the bug where if complex type A has a wildcard, and B restricts A, then it can restrict the wildcard to a set of elements that match the wildcard. Not all elements in the substitution groups of those elements necessarily match the wildcard - so B is not a subset of A.
See (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Apr/0047.html .
The namespace constraints on wildcards must be more expressive in order to be able to express the union or intersection of any two wildcards. Specifically, it must be possible to express "any namespace except those in the following list."
See http://www.w3.org/2000/12/xmlschema-crcomments.html#wildcard-minus : CR-20.
Proposals
Allow a wildcard to indicate that it will allow any element that conforms to a specified type.
See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/1137.html .
Proposal
Address localization concerns regarding Part 2: Datatypes.
See (member-only link) http://www.w3.org/XML/Group/xmlschema-current/lcissues.html#i18n-dt-misdirected : LC-207.
Unit of length must be defined for the all primitive types, including anyURI, QName, and NOTATION.
See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JanMar/0391.html .
See (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Nov/0186.html .
Proposal
Provide regular expressions or BNF productions to express (1) the valid lexical representations and (2) the canonical lexical representation of each primitive built-in type.
Proposal
Make the treatment of fundamental facets more systematic. Define canonical forms for all types, and specify the rules for generating the canonical form, given a value. Clarify the status of anySimpleType and define its value space (if any). Clarify the assignment of types to nodes in the absence of relevant schema components. Distinguish our identity relation from the mathematical relation of quantitative equality.
Interaction between uniqueness and referential integrity constraints on legacy types and union types.
See http://www.w3.org/2000/12/xmlschema-crcomments.html#idrefinunion : CR-50 (broken link).
XML Schema Part 1 (Structure) and XML Schema Part 2 (Datatypes) have different notions of "derived" for simple types, specifically with regard to list and union types.
See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0014.html .
Proposal
Allow abstract simple types.
See http://www.w3.org/2000/12/xmlschema-crcomments.html#abstract-simples : CR-47.
Proposals
Add a "URI" type that allows only a URI, not a URI reference. The current anyURI type allows a URI reference.
See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/1141.html .
Support for extensible enumerations such as allowed in Java.
See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/1130.html .
There must be a canonical representation of duration, and a process for calculating the canonical representation from any other lexical representation. Currently, a period of one day and a period of 24 hours are considered two different values in the value space. They should be considered two different lexical representations of the same value.
See (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Jan/0215.html . See also http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0102.html : R-170.
Proposals
Address localization concerns regarding the date and time types.
See (member-only link) http://www.w3.org/XML/Group/xmlschema-current/lcissues.html#i18n-datetime : LC-221.
Resolve the issue that relates to timezone normalization resulting in a time crossing over the date line.
See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JanMar/0366.html .
The definition of the dateTime value space does not reference a part of ISO 8601 that defines dateTime values, only lexical representations. The reference should be corrected, and the recommendation should explain or fix the fuzziness and/or gaps in the definitions referenced.
See (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0258.html .
Proposal
The year 0000 should be allowed in the types date, dateTime, gYear and gYearMonth.
See (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0258.html .
Proposal
Provide totally ordered duration types, specifically one that is expressed only in years and months, and one that is expressed only in days, hours, minutes, and seconds (ignoring leap seconds.) Possibly define other totally ordered duration types such as day/hour/minute and hour/minute/second duration.
Proposal
yearMonthDuration and dayTimeDuration as defined in XQuery and XPath Function and Operators
The canonical representation of float and double must be refined because it currently maps several lexical representations into a single legal value. Specifically, the description of the canonical representation must address (1) signed exponents, and (2) trailing zeroes in the mantissa.
See (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Mar/0184.html .
Proposal
Provide a datatype which retains trailing zeroes in the lexical representation of decimal numbers.
See http://www.w3.org/2000/12/xmlschema-crcomments.html#canonical-decimals : CR-42.
Proposals
Allow scientific notation for decimals.
See http://www.w3.org/2000/12/xmlschema-crcomments.html#scientific-decimals : CR-23.
Allow negative values for the fractionDigits facet.
See http://www.w3.org/2000/12/xmlschema-crcomments.html#negative-scale : CR-22.