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.
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.
2 Structures Requirements and Desiderata
2.1 Complex Types
2.1.3 Opportunistic Desiderata
2.2 Constraints and Keys
2.2.3 Opportunistic Desiderata
2.5 Structures (General)
2.5.2 Opportunistic Desiderata
2.6 Substitution Groups
2.7.2 Opportunistic Desiderata
3 Datatypes Requirements and Desiderata
3.1 Datatypes (General)
3.1.3 Opportunistic Desiderata
3.2 Date and Time Types
3.3 Numeric Types
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.
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>
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.
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.
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.
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.
Revise the particle derivation rules so as to eliminate the problems with choice/choice rules.
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.
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."
Allow a wildcard to indicate that it will allow any element that conforms to a specified type.
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 (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Nov/0186.html .
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.
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.
Allow abstract simple types.
Add a "URI" type that allows only a URI, not a URI reference. The current anyURI type allows a URI reference.
Support for extensible enumerations such as allowed in Java.
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.
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.
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 .
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 .
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.
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 .
Provide a datatype which retains trailing zeroes in the lexical representation of decimal numbers.
Allow scientific notation for decimals.
Allow negative values for the fractionDigits facet.