W3C

XML Schema 1.1 Requirements

W3C Internal Draft 09 September 2002

This version:
http://www.w3.org/2001/09/xmlschema-1.1-reqs-20010720
Latest version:
http://www.w3.org/2001/09/xmlschema-1.1-reqs
Editors:
Charles Campbell <campbelc@acm.org>
Ashok Malhotra (Microsoft) <ashokma@microsoft.com>
Priscilla Walmsley <pwalmsley@datypic.com>

Abstract

This document contains a list of requirements and desiderata for XML Schema 1.1.

Status of this document

This document is an W3C Internal Draft. It is not intended for distribution.....

Table of contents

1 Introduction
2 Design Goals
3 Datatypes Requirements and Desiderata
    3.1 General Datatypes
    3.2 Numeric Datatypes
    3.3 Date and Time Datatypes
4 Structures Requirements and Desiderata
    4.1 General Structures
    4.2 Types and Type Derivation
    4.3 Wildcards
    4.4 Substitution Groups
    4.5 Named Model Group Definitions
    4.6 Constraints
    4.7 PSVI

Appendices

A References

1 Introduction

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.

2 Design Goals

This section of the document outlines the design goals identified by the Working Group.

3 Datatypes Requirements and Desiderata

3.1 General Datatypes

3.1.1 Requirements

  1. Localization issues with datatypes (localization)

    Address localization concerns regarding Part 2: Datatypes.

    Ed. Note: This needs to be analysed into its constituent items, and each item acted on individually.

  2. Unit of length for all primitive types (unit-of-length)

    Unit of length must be defined for the types anyURI, QName, and NOTATION.

3.1.2 Desiderata

  1. Provide regex or BNF for all primitive types (bnf)

    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.

  2. Systematic treatment of fundamental facets (fundamental)

    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.

  3. Interactions with legacy types (legacies)

    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.

3.2 Numeric Datatypes

3.2.1 Requirements

  1. Canonical representation of float and double (canonical-float)

    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.

3.2.2 Opportunistic Desiderata

  1. Scientific notation for decimals (scientific-notn)

    Allow scientific notation for decimals.

  2. Negative Scale (negative-scale)

    Allow negative values for the scale facet.

  3. Provide decimal type that retains trailing zeroes (trailing-zeroes)

    Provide a datatype which retains trailing zeroes in the lexical representation of decimal numbers.

3.3 Date and Time Datatypes

3.3.1 Requirements

  1. Canonical representation of duration (canonical-durati)

    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.

  2. Date and time localization (datetime-localiz, datetime-localzn)

    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.

  3. Time zone normalization crosses date line (time)

    Resolve the issue that relates to timezone normalization resulting in a time crossing over the date line.

3.3.2 Desiderata

  1. Provide ordered duration types (ordered-duration)

    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.

4 Structures Requirements and Desiderata

4.1 General Structures

4.1.1 Desiderata

  1. First class objects (first-class-obj)

    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.

4.1.2 Opportunistic Desiderata

  1. Localization of Structures (localization)

    Address localization concerns regarding Part 1: Structures

    Ed. Note: This needs to be analysed into its constituent items, and each item acted on individually.

  2. Inline schemas (inline-schema)

    Provide support for inline schema information, allowing schemas definitions to be included in instance documents.

4.2 Types and Type Derivation

4.2.1 Requirements

  1. Redo restriction rules (restrictn-rules, restrictn-cplx)

    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.

  2. Pointless occurrences rule eliminates some derivations (pointless-occs)

    Revise the derivation of complex-type restriction so as to eliminate the problems with pointless occurrences.

  3. Choice:choice (choice-vs-choice)

    Revise the particle derivation rules so as to eliminate the problems with choice/choice rules.

4.2.2 Desiderata

  1. Simplify final and block (final-and-block)

    Eliminate or simplify the interactions between final and block.

4.2.3 Opportunistic Desiderata

  1. Allow abstract simple types (abstract-simples)

    Allow abstract simple types.

  2. Local references (local-references)

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

  3. Normalized value for complex/mixed elements (norm-value)

    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.

4.3 Wildcards

4.3.1 Requirements

  1. Interaction between wildcards and substitution groups (wildcards, wildcards-subs)

    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.

  2. Expand wildcard namespace constraints (wildcard-ns-sets)

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

4.4 Substitution Groups

4.4.1 Requirements

  1. Interaction between exclusions and disallowed substitutions (substitn-groups)

    Interaction between substitution group exclusions and disallowed substitutions in the XSDL element component.

4.5 Named Model Group Definitions

4.5.1 Opportunistic Desiderata

  1. Improve named model group syntax (named-groups)

    Clean up named model group syntax and component.

4.6 Constraints

4.6.1 Requirements

  1. No schema component for selector/ field annotations. (id-inconsistency)

    The XML representation for and allows an , but there is no schema component to which this annotation can adhere. This inconsistency must be resolved.

  2. Problematic restriction of identity constraints. (id-restriction)

    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.

  3. Include the identity constraint definition in the schema component (id-components)

    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.

4.6.2 Desiderata

  1. Co-occurrence constraints (co-occurrence)

    Add the ability to define and enforce co-occurrence constraints.

4.6.3 Opportunistic Desiderata

  1. Key constraints based on element types (keys-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.

  2. Co-constraints (coconstraints)

    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.

4.7 PSVI

4.7.1 Requirements

  1. Correct handling of annotations in PSVI. (annotation-psvi)

    Systematise and correct the handling of annotations and out-of-bound attributes in the PSVI.

4.7.2 Desiderata

  1. Normalized default value for attributes (norm-default)

    Add a [normalized value] property to the constructed attribute infoitem which arises when a default value is applied.


A References

Character Model for the World Wide Web 1.0
Character Model for the World Wide Web 1.0. Available at: http://www.w3.org/TR/charmod/
XML Information Set
World Wide Web Consortium. XML Information Set (public WD) Available at: http://www.w3.org/TR/xml-infoset
XML Pointer Language
World Wide Web Consortium. XML Pointer Language (XPointer). Available at: http://www.w3.org/TR/xptr
XML 1.0 Recommendation (Second Edition)
World Wide Web Consortium. Extensible Markup Language (XML) 1.0, Second Edition. Available at: http://www.w3.org/TR/2000/WD-xml-2e-20000814
XML Path 1.0
World Wide Web Consortium. XML Path Language (XPath). Available at: http://www.w3.org/TR/xpath
XML Schema Part 0: Primer
XML Schema Part 0: Primer. Available at: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/
XML Schema Part 1: Structures
XML Schema Part 1: Structures. Available at: http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
XML Schema Part 2: Datatypes
XML Schema Part 2: Datatypes. Available at: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/