Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document is an editors' copy that has no official standing.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a ↑member-only review version which will in due course become a↑ Public Working Draft of XML Schema 1.1: Datatypes. It ↑has no formal standing within W3C; it↑ is here made available for review by W3C members↓ and the public↓. This version of this document was created on 19 September 2007.↑ It reflects (unless otherwise noted elsewhere) all decisions on this document made by the Working Group through 14 September 2007. The document thus incorporates all decisions made by the Working Group to date. ↑
For those primarily interested in the changes since version 1.0, the Changes since version 1.0 (§H) appendix, which summarizes both changes already made and also those in prospect, with links to the relevant sections of this draft, is the recommended starting point. An accompanying version of this document displays in color all changes to normative text since version 1.0; another shows changes since the previous Working Draft.
The major changes since version 1.0 include:
Changes since the previous Working Draft include the following:
Comments on this document should be made in W3C's public installation of Bugzilla, specifying "XML Schema" as the product. Instructions can be found at http://www.w3.org/XML/2006/01/public-bugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list, www-xml-schema-comments@w3.org (archive) Each Bugzilla entry and email message should contain only one comment.
The end of the Last Call review period is 8 November 2007; comments received after that date will be considered if time allows, but no guarantees can be offered.
Although feedback based on any aspect of this specification is welcome, there are certain aspects of the design presented herein for which the Working Group is particularly interested in feedback. These are designated 'priority feedback' aspects of the design, and identified as such in editorial notes at appropriate points in this draft.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced by the W3C XML Schema Working Group as part of the W3C XML Activity. The goals of the XML Schema language version 1.1 are discussed in the Requirements for XML Schema 1.1 document. The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors.
This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures made in connection with this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification must disclose the information in accordance with section 6 of the W3C Patent Policy.
The English version of this specification is the only normative version. Information about translations of this document is available at http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlschema.
The presentation of this document has been augmented to identify
changes from a previous version, controlled by
dg-b2947.xml
, which shows the status-quo text without
adornment. Three kinds of changes are highlighted: ↑new, added
text↑, ↑changed
text↓, and ↓deleted
text↓.
This section describes the conceptual framework behind the datatype system defined in this specification. The framework has been influenced by the [ISO 11404] standard on language-independent datatypes as well as the datatypes for [SQL] and for programming languages such as Java.
The datatypes discussed in this specification are for the most part well known abstract concepts such as integer and date. It is not the place of this specification to thoroughly define these abstract concepts; many other publications provide excellent definitions. However, this specification will attempt to describe the abstract concepts well enough that they can be readily recognized and distinguished from other abstractions with which they may be confused.
[Definition:] The value space of a datatype is the set of values for that datatype. Associated with each value space are selected operations and relations necessary to permit proper schema processing. Each value in the value space of a datatype is denoted by one or more character strings in its ·lexical space·, according to ·the lexical mapping·. (If the mapping is restricted during a derivation in such a way that a value has no denotation, that value is dropped from the value space.)
The value spaces of datatypes are abstractions, and are defined in Built-in Datatypes and Their Definitions (§3) to the extent needed to clarify them for readers. For example, in defining the numerical datatypes, we assume some general numerical concepts such as number and integer are known. In many cases we provide references to other documents providing more complete definitions.
The relations of identity↓,↓↑and↑ equality↓, and order↓ are required for each value space. ↑An order relation is specified for some value spaces, but not all.↑ A very few datatypes have other relations or operations prescribed for the purposes of this specification.
↓Each datatype has an order relation prescribed.↓↑For some datatypes, an order relation is prescribed, for use in checking upper and lower bounds of the ·value space·.↑ This order may be a partial order, which means that there may be values in the ·value space· which are neither equal, less-than, nor greater-than. Such value pairs are incomparable. In many cases, ↓the prescribed order is the "null order": the ultimate partial order, in which no pairs are less-than or greater-than↓↑no order is prescribed↑; ↓they are all↓↑each pair of values is either↑ equal or ·incomparable·. [Definition:] Two values that are neither equal, less-than, nor greater-than are incomparable. Two values that are not ·incomparable· are comparable. The order relation is used in conjunction with equality when making ·facet-based restrictions· involving order. This is the only use of order for schema processing.
In this specification, this less-than order relation is denoted by '<' (and its inverse by '>'), the weak order by '≤' (and its inverse by '≥'), and the resulting ·incomparable· relation by '<>', each used as a binary infix predicate: x < y , x ≤ y , x > y , x ≥ y , and x <> y .
For purposes of this specification, the value spaces of primitive datatypes are disjoint, even in cases where the abstractions they represent might be thought of as having values in common. In the order relation defined in this specification, values from different value spaces are thus ·incomparable·. For example, the numbers two and three are values in both the precisionDecimal datatype and the float datatype. In the order relation defined here, the two in the decimal datatype is not less than the three in the float datatype; the two values are incomparable. Other applications making use of these datatypes may choose to consider values such as these comparable.
While it is not an error to attempt to compare values from the value spaces of two different primitive datatypes, they will always be ·incomparable· and therefore unequal: If x and y are in the value spaces of different primitive datatypes then x <> y (and hence x ≠ y ).
The preceding sections of this specification have described datatypes in a way largely independent of their use in the particular context of schema-aware processing as defined in [XML Schema Part 1: Structures].
This section presents the mechanisms necessary to integrate datatypes into the context of [XML Schema Part 1: Structures], mostly in terms of the Schema Component abstraction introduced there. The account of datatypes given in this specification is also intended to be useful in other contexts. Any specification or other formal system intending to use datatypes as defined above, particularly if definition of new datatypes via facet-based restriction is envisaged, will need to provide analogous mechanisms for some, but not necessarily all, of what follows below. For example, the {target namespace} and {final} properties are required because of particular aspects of [XML Schema Part 1: Structures] which are not in principle necessary for the use of datatypes as defined here.
The following sections provide full details on the properties and significance of each kind of schema component involved in datatype definitions. For each property, the kinds of values it is allowed to have is specified. Any property not identified as optional is required to be present; optional properties which are not present have absent as their value. Any property identified as a having a set, subset or ·list· value may have an empty value unless this is explicitly ruled out: this is not the same as absent. Any property value identified as a superset or a subset of some set may be equal to that set, unless a proper superset or subset is explicitly called for.
For more information on the notion of schema components, see Schema Component Details of [XML Schema Part 1: Structures].
[Definition:] A component may be referred to as the owner of its properties, and of the values of those properties.
[Definition:] Each fundamental facet is a schema component that provides a limited piece of information about some aspect of each datatype. All ·fundamental facet· components are defined in this section. For example, cardinality is a ·fundamental facet·. Most ·fundamental facets· are given a value fixed with each primitive datatype's definition, and this value is not changed by subsequent ·derivations· (even when it would perhaps be reasonable to expect an application to give a more accurate value based on the constraining facets used to define the ·derivation·). The cardinality and bounded facets are exceptions to this rule; their values may change as a result of certain ·derivations·.
A ·fundamental facet· can occur only in the {fundamental facets} of a Simple Type Definition, and this is the only place where ·fundamental facet· components occur. Each kind of ·fundamental facet· component occurs (once) in each Simple Type Definition's {fundamental facets} set.
↓Some datatypes have a nontrivial order relation associated with their value spaces (see Order (§2.2.3)). (There is always a trivial partial ordering wherein every value pair that is not equal is incomparable, which could be associated with any value space.) The ordered facet value is a "near-boolean": one of false, partial, and total, as prescribed in Fundamental Facets (§F.1) for ·primitive· datatypes; all ·ordinary· datatypes inherit this value without change. The value for a ·list· is always false and the value for a ·union· is computed as described below.↓↑For some datatypes, this document specifies an order relation for their value spaces (see Order (§2.2.3)); the ordered facet reflects this. It takes the values total, partial, and false, with the meanings described below. For the ·primitive· datatypes, the value of the ordered facet is specified in Fundamental Facets (§F.1). For ·ordinary· datatypes, the value is inherited without change from the ·base type·. For a ·list·, the value is always false; for a ·union·, the value is computed as described below. ↑
A false value means no order is prescribed; a total value assures that the prescribed order is a total order; a partial value means that the prescribed order is a partial order, but not (for the primitive type in question) a total order. ↓Derivation of new datatypes from datatypes with partial orders may impose constraints which make the effective ordering either a trivial order or a non-trivial total order, but the value of the ordered facet is not changed to reflect this.↓
[Definition:] A ·value space·, and hence a datatype, is said to be ordered if ↓this specification prescribes a non-trivial order for that ·value space·↓↑the members of the ·value space· are all drawn from the same ·primitive· datatype, and the table in Fundamental Facets (§F.1) specifies the value total or partial for the ordered facet of that ·primitive· datatype↑.
The listing below is for the benefit of readers of a printed version of this document: it collects together all the definitions which appear in the document above.
...