XML Schema Part 2: Datatypes

W3C XML Schema Working Group"> actual value"> attribute"> children"> child"> attributes"> children"> value"> character code"> ]>

XML Schema Part 2: Datatypes Second Edition

rec-20041028

W3C Recommendation

28 October 2004 Id: datatypes-with-errata.xml,v 1.20 2004/10/07 22:51:40 cmsmcq Exp http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ XML Independent copy of the schema for schema documents A schema for built-in datatypes only, in a separate namespace Independent copy of the DTD for schema documents http://www.w3.org/TR/xmlschema-2/ http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/ Paul V. Biron Kaiser Permanente, for Health Level Seven Paul.V.Biron@kp.org Ashok Malhotra Microsoft (formerly of IBM) ashokma@microsoft.com

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 W3C Recommendation, which forms part of the Second Edition of XML Schema. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

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 are discussed in the XML Schema Requirements document. The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors.

This version of this document incorporates some editorial changes from earlier versions.

This document was produced under the 24 January 2002 Current Patent Practice (CPP) as amended by the W3C Patent Policy Transition Procedure. The Working Group maintains a public list of patent disclosures relevant to 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 should disclose the information in accordance with section 6 of the W3C Patent Policy.

Please report errors in this document to www-xml-schema-comments@w3.org (archive). The list of known errors in this specification is available at http://www.w3.org/2001/05/xmlschema-errata.

The English version of this specification is the only normative version. Information about translations of this document is available at http://www.w3.org/2001/05/xmlschema-translations.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

This second edition is not a new version, it merely incorporates the changes dictated by the corrections to errors found in the first edition as agreed by the XML Schema Working Group, as a convenience to readers. A separate list of all such corrections is available at http://www.w3.org/2001/05/xmlschema-errata.

The errata list for this second edition is available at http://www.w3.org/2004/03/xmlschema-errata.

Please report errors in this document to www-xml-schema-comments@w3.org (archive).

Ashok Malhotra's affiliation has changed since the completion of editorial work on this second edition. He is now at Oracle, and can be contacted at <ashok.malhotra@oracle.com>.

XML Schema: Datatypes is part 2 of the specification of the XML Schema language. It defines facilities for defining datatypes to be used in XML Schemas as well as other XML specifications. The datatype language, which is itself represented in XML 1.0, provides a superset of the capabilities found in XML 1.0 document type definitions (DTDs) for specifying datatypes on elements and attributes.

English Extended Backus-Naur Form (formal grammar) 2001-04-03: pvb: added 0-9 to IsBlock production (to cover Latin1-Suppliment) 2001-04-03: pvb: fixed typos in \w (word char) multi-char escape: \p{S} -> \p{Z} and "control" -> "other" 2001-04-03: pvb: modified the pattern facet on language in the schema for datatypes to restrict sub-tags to no more than 8 chars, and changed the xsd:documentation to discuss section 2.12 of XML 1.02e and RFC 1766 instead of "production 33 of XML 1.0". 2001-04-03: pvb: fixed the order relation on duration from x <= y iff s+x <= s+y 2001-04-03: pvb: fixed incorrect values in duration partial order table (from <= and >= to <>. 2001-04-03: pvb: clarified a misleading statement in the lexical representation for durations regarding the omitition of "lower order items". 2001-04-03: pvb: clarified COS "maxInclusive-maxExclusive" and "minInclusive and minExclusive" to note that the prohibitions are within a single derivation step 2001-04-03: pvb: {typ,think}os in definition of restriction: missing "when" added and "one or more facet" changed to "zero or more" 2001-04-03: pvb: added gYearMonth and gDay to the list of types for which appendix E applies 2001-04-03: pvb: fixed incorrect comparisons in dateTime order relation algorithm (from <= to < and >= to >. 2001-04-03: pvb: in COS "maxExclusive-valid-restriction", fixed 2nd clause: {value} >= maxInclusive(parent) -> {value} > maxInclusive(parent) 2001-04-03: pvb: in COS "minExclusive-valid-restriction", fixed 1st clause: {value} > minExclusive(parent) -> {value} < minExclusive(parent) 2001-04-04: pvb: in COS "minExclusive-valid-restriction", fixed 3rd clause: {value} <= minInclusive(parent) -> {value} < minInclusive(parent) 2001-04-04: pvb: in COS "length-valid-restriction", fixed: {value} > length(parent) -> {value} != length(parent) 2001-04-04: pvb: changed antisymmetry to asymmetry in description of properties of partial orders: a R b and b R a ==> a = b -> a R b ==> not(b R a) 2001-04-04: pvb: fixed how cardinality gets valued for atomic types...if base is finite, then restriction is finite; else, added length, maxLength, totalDigits and fractionDigits to the list of facets which guarantee finite. 2001-04-10: pvb: fixed typo in schema def of ENTITIES; <xs:minLength value="1" id="ENTITES.minLength"/> went to <xs:minLength value="1" id="ENTITIES.minLength"/> 2001-04-12: pvb: added canonical form for hexBinary 2001-04-23: pvb: completed first pass at "refactoring": bringing all there is to know about any concept (e.g., a facet) into the same section, instead of having it spread all over the spec...thus, making this spec closer in organization to part 1. 2001-04-23: pvb: brought the stylesheet for parts 1 and 2 into alignment, so that both parts can use the same stylesheet. 2001-04-24: pvb: fixed several occurances of <xspecref> which should have been <xnt> (e.g., Name and NCName) 2001-04-24: pvb: fixed order in which derived types are listed in section 3 2001-04-25: pvb: removed dichot vs. tricot ednote 2001-04-25: pvb: clarified that optional + sign is not allowed in mantisa or exponent of canon rep for float/double 2001-04-25: pvb: clarified that both hh:mm are required for time zones 2001-04-25: pvb: fixed bug in dateTime normalization example 2001-04-25: pvb: fixed bug in indeterminate dateTime compare example 2001-04-25: pvb: updated reference to unicode char db 3.1, as well as the table of block names and general category values accordingly 2001-04-26: pvb: rewrote enumeration valid constraint to be less confusing 2001-04-26: pvb: corrected description of how cardinality gets valued to account for date types 2001-04-26: pvb: corrected signs of timezones in clauses C and D of dateTime comparison algorithm 2001-04-26: pvb: added note to ENTITY specifying value space is scoped, like the one in ENTITIES 2001-04-26: pvb: clarified that only the seconds part of durations may specify fractions 2001-04-26: pvb: corrected incorrect namespace name in section 3 2001-04-26: pvb: added "...(and other relevant portions of section 4)..." to the part of conformance that references the XML Rep of simple type defns. 2001-04-26: pvb: moved equal to section 4 2001-04-26: pvb: added fact that canonical rep for midnight is 00:00:00 to time 2001-04-26: pvb: added note to ordered and bounded that when inheriting value from basetype, the value for primitive types is in appx C. 2001-04-26: pvb: removed {pos,neg}CharGroupND productions from regex and redefined the charClassSub production as :== ( posCharGroup | negCharGroup) '-' charClassExpr (and moved a few other productions around as a result) 2003-03-05: pvb: errata: added "line feed (#xA)" to the list of chars excluded from the lexical space of normalizedString 2003-03-05: pvb: errata: corrected regex in 2e example in 2.5.1.2 and changed all mention of "whitespace" to "space" in descriptions of the lexical space of lists 2003-03-05: pvb: errata: removed mention of {total,fraction}Digits from description of lexical representation of decimal 2003-03-05: pvb: errata: changed {total,fraction}Digits validation rules to talk about "numbers expressible as ix10^-n",etc. instead of "number of digits = xxx". 2004-07-01: MSM: errata: changed charRange and some accompanying text, erratum E2-67.

Introduction Purpose

The specification defines limited facilities for applying datatypes to document content in that documents may contain or refer to DTDs that assign types to elements and attributes. However, document authors, including authors of traditional documents and those transporting data in XML, often require a higher degree of type checking to ensure robustness in document understanding and data interchange.

The table below offers two typical examples of XML instances in which datatypes are implicit: the instance on the left represents a billing invoice, the instance on the right a memo or perhaps an email message in XML.

Data oriented	Document oriented
1999-01-21 1999-01-25 Ashok Malhotra 123 Microsoft Ave. Hawthorne NY 10532-0000 555-1234 555-4321 ]]>	Paul V. Biron Ashok Malhotra Latest draft We need to discuss the latest draft immediately. Either email me at mailto:paul.v.biron@kp.org or call 555-9876 ]]>

The invoice contains several dates and telephone numbers, the postal abbreviation for a state (which comes from an enumerated list of sanctioned values), and a ZIP code (which takes a definable regular form). The memo contains many of the same types of information: a date, telephone number, email address and an "importance" value (from an enumerated list, such as "low", "medium" or "high"). Applications which process invoices and memos need to raise exceptions if something that was supposed to be a date or telephone number does not conform to the rules for valid dates or telephone numbers.

In both cases, validity constraints exist on the content of the instances that are not expressible in XML DTDs. The limited datatyping facilities in XML have prevented validating XML processors from supplying the rigorous type checking required in these situations. The result has been that individual applications writers have had to implement type checking in an ad hoc manner. This specification addresses the need of both document authors and applications writers for a robust, extensible datatype system for XML which could be incorporated into XML processors. As discussed below, these datatypes could be used in other XML-related standards as well.

Requirements

The document spells out concrete requirements to be fulfilled by this specification, which state that the XML Schema Language must:

provide for primitive data typing, including byte, date, integer, sequence, SQL and Java primitive datatypes, etc.;

define a type system that is adequate for import/export from database systems (e.g., relational, object, OLAP);

distinguish requirements relating to lexical data representation vs. those governing an underlying information set;

allow creation of user-defined datatypes, such as datatypes that are derived from existing datatypes and which may constrain certain of its properties (e.g., range, precision, length, format).

Scope

This portion of the XML Schema Language discusses datatypes that can be used in an XML Schema. These datatypes can be specified for element content that would be specified as #PCDATA and attribute values of various types in a DTD. It is the intention of this specification that it be usable outside of the context of XML Schemas for a wide range of other XML-related activities such as and .

Terminology

The terminology used to describe XML Schema Datatypes is defined in the body of this specification. The terms defined in the following list are used in building those definitions and in describing the actions of a datatype processor:

for compatibility

A feature of this specification included solely to ensure that schemas which use this feature remain compatible with

may

Conforming documents and processors are permitted to but need not behave as described.

match

(Of strings or names:) Two strings or names being compared must be identical. Characters with multiple possible representations in ISO/IEC 10646 (e.g. characters with both precomposed and base+diacritic forms) match only if they have the same representation in both strings. No case folding is performed. (Of strings and rules in the grammar:) A string matches a grammatical production if it belongs to the language generated by that production.

must

Conforming documents and processors are required to behave as described; otherwise they are in error.

error

A violation of the rules of this specification; results are undefined. Conforming software detect and report an error and recover from it.

Constraints and Contributions

This specification provides three different kinds of normative statements about schema components, their representations in XML and their contribution to the schema-validation of information items:

Constraint on Schemas

Constraints on the schema components themselves, i.e. conditions components satisfy to be components at all. Largely to be found in .

Schema Representation Constraint

Constraints on the representation of schema components in XML. Some but not all of these are expressed in and .

Validation Rule

Constraints expressed by schema components which information items satisfy to be schema-valid. Largely to be found in .

Type System

This section describes the conceptual framework behind the type system defined in this specification. The framework has been influenced by the standard on language-independent datatypes as well as the datatypes for and for programming languages such as Java.

The datatypes discussed in this specification are computer representations of well known abstract concepts such as integer and date. It is not the place of this specification to define these abstract concepts; many other publications provide excellent definitions.

Datatype

In this specification, a datatype is a 3-tuple, consisting of a) a set of distinct values, called its , b) a set of lexical representations, called its , and c) a set of s that characterize properties of the , individual values or lexical items.

Value space

A value space is the set of values for a given datatype. Each value in the value space of a datatype is denoted by one or more literals in its .

The of a given datatype can be defined in one of the following ways:

defined axiomatically from fundamental notions (intensional definition) [see ]

enumerated outright (extensional definition) [see ]

defined by restricting the of an already defined datatype to a particular subset with a given set of properties [see ]

defined as a combination of values from one or more already defined (s) by a specific construction procedure [see and ]

s have certain properties. For example, they always have the property of , some definition of equality and might be , by which individual values within the can be compared to one another. The properties of s that are recognized by this specification are defined in .

Lexical space

In addition to its , each datatype also has a lexical space.

A lexical space is the set of valid literals for a datatype.

For example, "100" and "1.0E2" are two different literals from the of which both denote the same value. The type system defined in this specification provides a mechanism for schema designers to control the set of values and the corresponding set of acceptable literals of those values for a datatype.

The literals in the s defined in this specification have the following characteristics:

Interoperability:

The number of literals for each value has been kept small; for many datatypes there is a one-to-one mapping between literals and values. This makes it easy to exchange the values between different systems. In many cases, conversion from locale-dependent representations will be required on both the originator and the recipient side, both for computer processing and for interaction with humans.

Basic readability:

Textual, rather than binary, literals are used. This makes hand editing, debugging, and similar activities possible.

Ease of parsing and serializing:

Where possible, literals correspond to those found in common programming languages and libraries.

Canonical Lexical Representation

While the datatypes defined in this specification have, for the most part, a single lexical representation i.e. each value in the datatype's is denoted by a single literal in its , this is not always the case. The example in the previous section showed two literals for the datatype which denote the same value. Similarly, there be several literals for one of the date or time datatypes that denote the same value using different timezone indicators.

A canonical lexical representation is a set of literals from among the valid set of literals for a datatype such that there is a one-to-one mapping between literals in the canonical lexical representation and values in the .

Datatype dichotomies

It is useful to categorize the datatypes defined in this specification along various dimensions, forming a set of characterization dichotomies.

Atomic vs. list vs. union datatypes

The first distinction to be made is that between , and datatypes.

Atomic datatypes are those having values which are regarded by this specification as being indivisible.

List datatypes are those having values each of which consists of a finite-length (possibly empty) sequence of values of an datatype.

Union datatypes are those whose s and s are the union of the s and s of one or more other datatypes.

For example, a single token which es Nmtoken from could be the value of an datatype (); while a sequence of such tokens could be the value of a datatype ().

Atomic datatypes

datatypes can be either or . The of an datatype is a set of "atomic" values, which for the purposes of this specification, are not further decomposable. The of an datatype is a set of literals whose internal structure is specific to the datatype in question.

List datatypes

Several type systems (such as the one described in ) treat datatypes as special cases of the more general notions of aggregate or collection datatypes.

datatypes are always . The of a datatype is a set of finite-length sequences of values. The of a datatype is a set of literals whose internal structure is a white space-separated sequence of literals of the datatype of the items in the (where whitespace es S in ).

The or datatype that participates in the definition of a datatype is known as the itemType of that datatype.

]]> 8 10.5 12 ]]>

A datatype can be from an datatype whose allows whitespace (such as or )or a datatype any of whose 's allows whitespace. In such a case, regardless of the input, list items will be separated at whitespace boundaries.

]]> <someElement xsi:type='listOfString'> this is not list item 1 this is not list item 2 this is not list item 3 </someElement>

In the above example, the value of the someElement element is not a of 3; rather, it is a of 18.

When a datatype is from a datatype, the following s apply:

For each of , and , the unit of length is measured in number of list items. The value of is fixed to the value collapse.

For datatypes the (and hence, the ) is composed of whitespace-separated literals of its . Hence, any specified when a new datatype is from a datatype is matched against each literal of the datatype and not against the literals of the datatype that serves as its .

123 456 123 987 456 123 987 567 456 ]]>

The for the datatype is defined as the lexical form in which each item in the has the canonical lexical representation of its .

Union datatypes

The and of a datatype are the union of the s and s of its . datatypes are always . Currently, there are no datatypes.

A prototypical example of a type is the maxOccurs attribute on the element element in XML Schema itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string "unbounded", as shown below.

use="optional" use="optional" default="1" ]]>

Any number (greater than 1) of or s can participate in a type.

The datatypes that participate in the definition of a datatype are known as the memberTypes of that datatype.

The order in which the are specified in the definition (that is, the order of the <simpleType> children of the <union> element, or the order of the s in the memberTypes attribute) is significant. During validation, an element or attribute's value is validated against the in the order in which they appear in the definition until a match is found. The evaluation order can be overridden with the use of xsi:type.

For example, given the definition below, the first instance of the <size> element validates correctly as an , the second and third as .

]]> 1 large 1 ]]>

The for a datatype is defined as the lexical form in which the values have the canonical lexical representation of the appropriate .

A datatype which is in this specification need not be an "atomic" datatype in any programming language used to implement this specification. Likewise, a datatype which is a in this specification need not be a "list" datatype in any programming language used to implement this specification. Furthermore, a datatype which is a in this specification need not be a "union" datatype in any programming language used to implement this specification.

Primitive vs. derived datatypes

Next, we distinguish between and datatypes.

Primitive datatypes are those that are not defined in terms of other datatypes; they exist ab initio.

Derived datatypes are those that are defined in terms of other datatypes.

For example, in this specification, is a well-defined mathematical concept that cannot be defined in terms of other datatypes, while a is a special case of the more general datatype .

The simple ur-type definition is a special restriction of the ur-type definition whose name is anySimpleType in the XML Schema namespace. anySimpleType can be considered as the of all datatypes. anySimpleType is considered to have an unconstrained lexical space and a consisting of the union of the s of all the datatypes and the set of all lists of all members of the s of all the datatypes. There exists a conceptual datatype, whose name is anySimpleType, that is the simple version of the ur-type definition from . anySimpleType can be considered as the of all types. The of anySimpleType can be considered to be the of the s of all datatypes.

The datatypes defined by this specification fall into both the and categories. It is felt that a judiciously chosen set of datatypes will serve the widest possible audience by providing a set of convenient datatypes that can be used as is, as well as providing a rich enough base from which the variety of datatypes needed by schema designers can be .

In the example above, is from .

A datatype which is in this specification need not be a "primitive" datatype in any programming language used to implement this specification. Likewise, a datatype which is in this specification need not be a "derived" datatype in any programming language used to implement this specification.

As described in more detail in , each datatype be defined in terms of another datatype in one of three ways: 1) by assigning s which serve to restrict the of the datatype to a subset of that of the ; 2) by creating a datatype whose consists of finite-length sequences of values of its ; or 3) by creating a datatype whose consists of the union of the s of its .

Derived by restriction

A datatype is said to be by restriction from another datatype when values for zero or more s are specified that serve to constrain its and/or its to a subset of those of its .

Every datatype that is by restriction is defined in terms of an existing datatype, referred to as its base type. base types can be either or .

Derived by list

A datatype can be from another datatype (its ) by creating a that consists of a finite-length sequence of values of its .

Derived by union

One datatype can be from one or more datatypes by ing their s and, consequently, their s.

Built-in vs. user-derived datatypes

Built-in datatypes are those which are defined in this specification, and can be either or ;

User-derived datatypes are those datatypes that are defined by individual schema designers.

Conceptually there is no difference between the datatypes included in this specification and the datatypes which will be created by individual schema designers. The datatypes are those which are believed to be so common that if they were not defined in this specification many schema designers would end up "reinventing" them. Furthermore, including these datatypes in this specification serves to demonstrate the mechanics and utility of the datatype generation facilities of this specification.

A datatype which is in this specification need not be a "built-in" datatype in any programming language used to implement this specification. Likewise, a datatype which is in this specification need not be a "user-derived" datatype in any programming language used to implement this specification.

Built-in datatypes

Each built-in datatype in this specification (both and ) can be uniquely addressed via a URI Reference constructed as follows:

the base URI is the URI of the XML Schema namespace

the fragment identifier is the name of the datatype

For example, to address the datatype, the URI is:

http://www.w3.org/2001/XMLSchema#int

Additionally, each facet definition element can be uniquely addressed via a URI constructed as follows:

the base URI is the URI of the XML Schema namespace

the fragment identifier is the name of the facet

For example, to address the maxInclusive facet, the URI is:

http://www.w3.org/2001/XMLSchema#maxInclusive

Additionally, each facet usage in a built-in datatype definition can be uniquely addressed via a URI constructed as follows:

the base URI is the URI of the XML Schema namespace

the fragment identifier is the name of the datatype, followed by a period (".") followed by the name of the facet

For example, to address the usage of the maxInclusive facet in the definition of int, the URI is:

http://www.w3.org/2001/XMLSchema#int.maxInclusive

Namespace considerations

The datatypes defined by this specification are designed to be used with the &schema-language; as well as other XML specifications. To facilitate usage within the &schema-language;, the datatypes in this specification have the namespace name:

http://www.w3.org/2001/XMLSchema

To facilitate usage in specifications other than the &schema-language;, such as those that do not want to know anything about aspects of the &schema-language; other than the datatypes, each datatype is also defined in the namespace whose URI is:

http://www.w3.org/2001/XMLSchema-datatypes

This applies to both and datatypes.

Each datatype is also associated with a unique namespace. However, datatypes do not come from the namespace defined by this specification; rather, they come from the namespace of the schema in which they are defined (see XML Representation of Schemas in ).

Primitive datatypes

The datatypes defined by this specification are described below. For each datatype, the and are defined, s which apply to the datatype are listed and any datatypes from this datatype are specified.

datatypes can only be added by revisions to this specification.

string

The string datatype represents character strings in XML. The of string is the set of finite-length sequences of characters (as defined in ) that the Char production from . A character is an atomic unit of communication; it is not further specified except to note that every character has a corresponding Universal Character Set code point, which is an integer.

Many human languages have writing systems that require child elements for control of aspects such as bidirectional formating or ruby annotation (see and Section 8.2.4 Overriding the bidirectional algorithm: the BDO element of ). Thus, string, as a simple type that can contain only characters but not child elements, is often not suitable for representing text. In such situations, a complex type that allows mixed content should be considered. For more information, see Section 5.5 Any Element, Any Attribute of .

As noted in , the fact that this specification does not specify an for does not preclude other applications from treating strings as being ordered.

Derived datatypes boolean

boolean has the required to support the mathematical concept of binary-valued logic: {true, false}.

Lexical representation

An instance of a datatype that is defined as can have the following legal literals {true, false, 1, 0}.

Canonical representation

The canonical representation for boolean is the set of literals {true, false}.

decimal

decimal represents a subset of the real numbers, which can be represented by decimal numeralsarbitrary precision decimal numbers. The of decimal is the set of numbers that can be obtained by multiplying an integer by a non-positive power of ten, i.e., expressible as i × 10^-n where i and n are integers and n >= 0the values i × 10^-n, where i and n are integers such that n >= 0. Precision is not reflected in this value space; the number 2.0 is not distinct from the number 2.00. The on decimal is the order relation on real numbers, restricted to this subset: x < y iff y - x is positive.

The of types derived from decimal with a value for of p is the set of values i × 10^-n, where n and i are integers such that p >= n >= 0 and the number of significant decimal digits in i is less than or equal to p.

The of types derived from decimal with a value for of s is the set of values i × 10^-n, where i and n are integers such that 0 <= n <= s.

All processors support decimal numbers with a minimum of 18 decimal digits (i.e., with a of 18). However, processors set an application-defined limit on the maximum number of decimal digits they are prepared to support, in which case that application-defined maximum number be clearly documented.

Lexical representation

decimal has a lexical representation consisting of a finite-length sequence of decimal digits (#x30-#x39) separated by a period as a decimal indicator. If is specified, the number of digits must be less than or equal to . If is specified, the number of digits following the decimal point must be less than or equal to the . An optional leading sign is allowed. If the sign is omitted, "+" is assumed. Leading and trailing zeroes are optional. If the fractional part is zero, the period and following zero(es) can be omitted. For example: -1.23, 12678967.543233, +100000.00, 210.

Canonical representation

The canonical representation for decimal is defined by prohibiting certain options from the . Specifically, the preceding optional "+" sign is prohibited. The decimal point is required. Leading and trailing zeroes are prohibited subject to the following: there must be at least one digit to the right and to the left of the decimal point which may be a zero.

Derived datatypes float

float is patterned aftercorresponds to the IEEE single-precision 32-bit floating point type . The basic of float consists of the values m × 2^e, where m is an integer whose absolute value is less than 2^24, and e is an integer between -149 and 104, inclusive. In addition to the basic described above, the of float also contains the following three special values: positive and negative zero, positive and negative infinity and not-a-number (NaN). The on float is: x < y iff y - x is positive for x and y in the value space. Positive infinity is greater than all other non-NaN values. NaN equals itself but is with (neither greater than nor less than) any other value in the . Positive zero is greater than negative zero. Not-a-number equals itself and is greater than all float values including positive infinity.

"Equality" in this Recommendation is defined to be "identity" (i.e., values that are identical in the are equal and vice versa). Identity must be used for the few operations that are defined in this Recommendation. Applications using any of the datatypes defined in this Recommendation may use different definitions of equality for computational purposes; -based computation systems are examples. Nothing in this Recommendation should be construed as requiring that such applications use identity as their equality relationship when computing.

Any value with the value used for the four bounding facets (, , , and ) will be excluded from the resulting restricted . In particular, when "NaN" is used as a facet value for a bounding facet, since no other float values are with it, the result is a either having NaN as its only member (the inclusive cases) or that is empty (the exclusive cases). If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ; to add NaN back in requires union with the NaN-only space.

This datatype differs from that of in that there is only one NaN and only one zero. This makes the equality and ordering of values in the data space differ from that of only in that for schema purposes NaN = NaN.

A literal in the representing a decimal number d maps to the normalized value in the of float that is closest to d in the sense defined by ; if d is exactly halfway between two such values then the even value is chosen.

Lexical representation

float values have a lexical representation consisting of a mantissa followed, optionally, by the character "E" or "e", followed by an exponent. The exponent be an . The mantissa must be a number. The representations for exponent and mantissa must follow the lexical rules for and . If the "E" or "e" and the following exponent are omitted, an exponent value of 0 is assumed.

The special values positive and negative zero, positive and negative infinity and not-a-number have lexical representations 0, -0, INF, -INF and NaN, respectively. Lexical representations for zero may take a positive or negative sign.

For example, -1E4, 1267.43233E12, 12.78e-2, 12 , -0, 0 and INF are all legal literals for float.

Canonical representation

The canonical representation for float is defined by prohibiting certain options from the . Specifically, the exponent must be indicated by "E". Leading zeroes and the preceding optional "+" sign are prohibited in the exponent. If the exponent is zero, it must be indicated by "E0". For the mantissa, the preceding optional "+" sign is prohibited and the decimal point is required. For the exponent, the preceding optional "+" sign is prohibited. Leading and trailing zeroes are prohibited subject to the following: number representations must be normalized such that there is a single digit which is non-zero to the left of the decimal point and at least a single digit to the right of the decimal point unless the value being represented is zero. The canonical representation for zero is 0.0E0.

double

The double datatype is patterned after the corresponds to IEEE double-precision 64-bit floating point type . The basic of double consists of the values m × 2^e, where m is an integer whose absolute value is less than 2^53, and e is an integer between -1075 and 970, inclusive. In addition to the basic described above, the of double also contains the following three special values: positive and negative zero, positive and negative infinity and not-a-number (NaN). The on double is: x < y iff y - x is positive for x and y in the value space. Positive infinity is greater than all other non-NaN values. NaN equals itself but is with (neither greater than nor less than) any other value in the . Positive zero is greater than negative zero. Not-a-number equals itself and is greater than all float values including positive infinity.

Any value with the value used for the four bounding facets (, , , and ) will be excluded from the resulting restricted . In particular, when "NaN" is used as a facet value for a bounding facet, since no other double values are with it, the result is a either having NaN as its only member (the inclusive cases) or that is empty (the exclusive cases). If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ; to add NaN back in requires union with the NaN-only space.

A literal in the representing a decimal number d maps to the normalized value in the of double that is closest to d; if d is exactly halfway between two such values then the even value is chosen. This is the best approximation of d (, ), which is more accurate than the mapping required by .

Lexical representation

double values have a lexical representation consisting of a mantissa followed, optionally, by the character "E" or "e", followed by an exponent. The exponent be an integer. The mantissa must be a decimal number. The representations for exponent and mantissa must follow the lexical rules for and . If the "E" or "e" and the following exponent are omitted, an exponent value of 0 is assumed.

For example, -1E4, 1267.43233E12, 12.78e-2, 12 , -0, 0 and INF are all legal literals for double.

Canonical representation

The canonical representation for double is defined by prohibiting certain options from the . Specifically, the exponent must be indicated by "E". Leading zeroes and the preceding optional "+" sign are prohibited in the exponent. If the exponent is zero, it must be indicated by "E0". For the mantissa, the preceding optional "+" sign is prohibited and the decimal point is required. For the exponent, the preceding optional "+" sign is prohibited. Leading and trailing zeroes are prohibited subject to the following: number representations must be normalized such that there is a single digit which is non-zero to the left of the decimal point and at least a single digit to the right of the decimal point unless the value being represented is zero. The canonical representation for zero is 0.0E0.

duration

duration represents a duration of time. The of duration is a six-dimensional space where the coordinates designate the Gregorian year, month, day, hour, minute, and second components defined in § 5.5.3.2 of , respectively. These components are ordered in their significance by their order of appearance i.e. as year, month, day, hour, minute, and second.

All processors support