Copyright©2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document contains a list of requirements and desiderata for XML Schema 1.1.
This document is an W3C Internal Draft. It is not intended for distribution.....
This document contains a list of potential requirements for XML Schema 1.1. These issues have been collected from e-mail, minutes or telcons and meetings as well as from the various issues lists that the XML Schema WG has created during its lifetime. Links are provided to further discusion....
what is a desiderata vs. a reqt etc.This section of the document outlines the design goals identified by the Working Group.
Address localization concerns regarding Part 2: Datatypes.
Ed. Note: This needs to be analysed into its constituent items, and each item acted on individually.
Unit of length must be defined for the types anyURI, QName, and NOTATION.
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. Define a regular expression or EBNF grammar for each lexical space, and for each set of canonical forms. 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
Ed. Note: The meaning of this item is unclear to the members of the WG present at the August 2002 face to face; it needs to be clarified and either retained or dropped.
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.
Allow scientific notation for decimals.
Allow negative values for the scale facet.
Provide a datatype which retains trailing zeroes in the lexical representation of decimal numbers.
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.
Address localization concerns regarding the date and time types.
Ed. Note: This needs to be analysed into its constituent items, and each item acted on individually.
Resolve the issue that relates to timezone normalization resulting in a time crossing over the date line.
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.
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
Ed. Note: This needs to be analysed into its constituent items, and each item acted on individually.
Provide support for inline schema information, allowing schemas definitions to be included in instance documents.
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.
Revise the derivation of complex-type restriction so as to eliminate the problems with pointless occurrences.
Revise the particle derivation rules so as to eliminate the problems with choice/choice rules.
Eliminate or simplify the interactions between final and block.
Allow abstract simple types.
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 decls 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.
Clarify 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.
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."
Interaction between substitution group exclusions and disallowed substitutions in the XSDL element component.
The XML representation for
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.
Include the identity constraint definition in the schema component
Ed. Note: This item is unclear to the members of the WG present at the August 2002 face to face meeting; a clearer statement of the intended requirement is needed.
Add the ability to define and enforce co-occurrence constraints.
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.
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.
Systematise and correct the handling of annotations and out-of-bound attributes in the PSVI.
Add a [normalized value] property to the constructed attribute infoitem which arises when a default value is applied.