XML Schema 1.1 Part 2: Datatypes

3.3.1.2 Lexical Mapping

The ·lexical space· of string is the set of finite-length sequences of characters (as defined in [XML]) that ·match· the Char production from [XML].

It is implementation-defined whether an implementation of this specification supports the Char production from [XML], or that from [XML 1.0], or both. See Dependencies on Other Specifications (§1.3).

The ·lexical mapping· for string is ·stringLexicalMap·, and the ·canonical mapping· is ·stringCanonicalMap·; each is a subset of the identity function.

3.3.2.1 Value Space

boolean has the ·value space· of two-valued logic:  {true, false}.

3.3.2.4 Lexical Mapping

boolean's lexical space is a set of four ·literals·:

The ·lexical mapping· for boolean is ·booleanLexicalMap·; the ·canonical mapping· is ·booleanCanonicalMap·.

3.3.5.1 Value Space

The ·value space· of float contains the non-zero numbers  m × 2^e , where m is an integer whose absolute value is less than 2²⁴, and e is an integer between −149 and 104, inclusive.  In addition to these values, the ·value space· of float also contains the following special values:  positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber.

Equality and order for float are defined as follows:

• Equality is identity, except that  0 = −0  (although they are not identical) and  NaN ≠ NaN  (although NaN is of course identical to itself).

  0 and −0 are thus distinct for purposes of enumerations and identity constraints, but equal for purposes of minimum and maximum values.

• For the basic values, the order relation on float is the order relation for rational numbers.  INF is greater than all other non-NaN values; −INF is less than all other non-NaN values.  NaN is ·incomparable· with any value in the ·value space· including itself.  0 and −0 are greater than all the negative numbers and less than all the positive numbers.

3.3.5.4 Lexical Mapping

The ·lexical space· of float is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '-INF', and 'NaN'

The floatRep production is equivalent to this regular expression:

(-|+)?(([0-9]+(.[0-9]*)?)|(.[0-9]+))((e|E)(-|+)?[0-9]+)?|-?INF|NaN

The float datatype is designed to implement for schema processing the single-precision floating-point datatype of [IEEE 754-1985].  That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used.  Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, satisfies the requirements of [IEEE 754-1985], and correctly handles the special values (numericalSpecialRep ·literals·), satisfies the conformance requirements of this specification.

Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·.

The ·lexical mapping· ·floatLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible—and is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping.  The simple rounding algorithm used in ·floatLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)].

The ·canonical mapping· ·floatCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·.  Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-1985].

3.3.6.1 Value Space

The ·value space· of double contains the non-zero numbers  m × 2^e , where m is an integer whose absolute value is less than 2⁵³, and e is an integer between −1074 and 971, inclusive.  In addition to these values, the ·value space· of double also contains the following special values:  positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber.

Equality and order for double are defined as follows:

• Equality is identity, except that  0 = −0  (although they are not identical) and  NaN ≠ NaN  (although NaN is of course identical to itself).

  0 and −0 are thus distinct for purposes of enumerations and identity constraints, but equal for purposes of minimum and maximum values.

• For the basic values, the order relation on double is the order relation for rational numbers.  INF is greater than all other non-NaN values; −INF is less than all other non-NaN values.  NaN is ·incomparable· with any value in the ·value space· including itself.  0 and −0 are greater than all the negative numbers and less than all the positive numbers.

3.3.6.4 Lexical Mapping

The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '-INF', and 'NaN'

The doubleRep production is equivalent to this regular expression:

(-|+)?(([0-9]+(.[0-9]*)?)|(.[0-9]+))((e|E)(-|+)?[0-9]+)?|-?INF|NaN

The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-1985].  That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used.  Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, satisfies the requirements of [IEEE 754-1985], and correctly handles the special values (numericalSpecialRep ·literals·), satisfies the conformance requirements of this specification.

Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·.

The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible—and is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping.  The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)].

The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·.  Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-1985].

3.3.7.1 Value Space

Duration values can be modelled as two-property tuples. Each value consists of an integer number of months and a decimal number of seconds. The ·seconds· value must not be negative if the ·months· value is positive and must not be positive if the ·months· is negative.

duration is partially ordered.  Equality of duration is defined in terms of equality of dateTime; order for duration is defined in terms of the order of dateTime. Specifically, the equality or order of two duration values is determined by adding each duration in the pair to each of the following four dateTime values:

• 1696-09-01T00:00:00Z
• 1697-02-01T00:00:00Z
• 1903-03-01T00:00:00Z
• 1903-07-01T00:00:00Z

If all four resulting dateTime value pairs are ordered the same way (less than, equal, or greater than), then the original pair of duration values is ordered the same way; otherwise the original pair is ·incomparable·.

Under the definition just given, two duration values are equal if and only if they are identical.

3.3.7.3 Lexical Space

The ·lexical representations· of duration are more or less based on the pattern:

PnYnMnDTnHnMnS

More precisely, the ·lexical space· of duration is the set of character strings that satisfy durationLexicalRep as defined by the following productions:

Thus, a durationLexicalRep consists of one or more of a duYearFrag, duMonthFrag, duDayFrag, duHourFrag, duMinuteFrag, and/or duSecondFrag, in order, with letters 'P' and 'T' (and perhaps a '-') where appropriate.

The language accepted by the durationLexicalRep production is the set of strings which satisfy all of the following three regular expressions:

• The expression '-?P([0-9]+Y)?([0-9]+M)?([0-9]+D)?(T([0-9]+H)?([0-9]+M)?((([0-9]+(.[0-9]*)?)|(.[0-9]+))S)?)?' matches only strings in which the fields occur in the proper order.
• The expression '.*[YMDHS].*' matches only strings in which at least one field occurs.
• The expression '.*[^T]' matches only strings in which 'T' is not the final character, so that if 'T' appears, something follows it. The first rule ensures that what follows 'T' will be an hour, minute, or second field.

The intersection of these three regular expressions is equivalent to the following (after removal of the white space inserted here for legibility):

-?P(((([0-9]+Y([0-9]+M)?)|
      (       ([0-9]+M) ) )(([0-9]+D(T(([0-9]+H([0-9]+M)?([0-9]+(\.[0-9]+)?S)?)|
                                       (       ([0-9]+M) ([0-9]+(\.[0-9]+)?S)?)|
                                       (                 ([0-9]+(\.[0-9]+)?S) ) ))?)|
                            (       (T(([0-9]+H([0-9]+M)?([0-9]+(\.[0-9]+)?S)?)|
                                       (       ([0-9]+M) ([0-9]+(\.[0-9]+)?S)?)|
                                       (                 ([0-9]+(\.[0-9]+)?S) ) )) ) )?)|
    (                      (([0-9]+D(T(([0-9]+H([0-9]+M)?([0-9]+(\.[0-9]+)?S)?)|
                                       (       ([0-9]+M) ([0-9]+(\.[0-9]+)?S)?)|
                                       (                 ([0-9]+(\.[0-9]+)?S) ) ))?)|
                            (       (T(([0-9]+H([0-9]+M)?([0-9]+(\.[0-9]+)?S)?)|
                                       (       ([0-9]+M) ([0-9]+(\.[0-9]+)?S)?)|
                                       (                 ([0-9]+(\.[0-9]+)?S) ) )) ) ) ) )

The ·lexical mapping· for duration is ·durationMap·.

·The canonical mapping· for duration is ·durationCanonicalMap·.

3.3.7.8 Related Datatypes

The following ·built-in· datatypes are ·derived· from duration:

• yearMonthDuration
• dayTimeDuration

3.3.8.1 Value Space

dateTime uses the date/timeSevenPropertyModel, with no properties except ·timezone· permitted to be absent. The ·timezone· property remains ·optional·.

Equality and order are as prescribed in The Seven-property Model (§D.2.1).  dateTime values are ordered by their ·timeOnTimeline· value.

3.3.8.4 Lexical Mappings

The lexical representations for dateTime are as follows:

In such representations:

• yearFrag is a numeral consisting of at least four decimal digits, optionally preceded by a minus sign; leading '0' digits are prohibited except to bring the digit count up to four.  It represents the ·year· value.
• Subsequent '-', 'T', and ':', separate the various numerals.
• monthFrag, dayFrag, hourFrag, and minuteFrag are numerals consisting of exactly two decimal digits.  They represent the ·month·, ·day·, ·hour·, and ·minute· values respectively.
• dayFrag is a numeral consisting of exactly two decimal digits, or two decimal digits, a decimal point, and one or more trailing digits.  It represents the ·second· value.
• Alternatively, endOfDayFrag combines the hourFrag, minuteFrag, minuteFrag, and their separators to represent midnight of the day, which is the first moment of the next day.
• timezoneFrag, if present, specifies the timezone in which the moment occurs.  Timezones are a count of minutes (expressed in timezoneFrag as a count of hours and minutes) that are added or subtracted from UTC time to get the "local" time.  'Z' is an alternative representation of the timezone of UTC, which is, of course, zero minutes from UTC.

  For example, 2002-10-10T12:00:00−05:00 (noon on 10 October 2002, Central Daylight Savings Time as well as Eastern Standard Time in the U.S.) is equal to 2002-10-10T17:00:00Z, five hours later than 2002-10-10T12:00:00Z.

The dateTimeLexicalRep production is equivalent to this regular expression once whitespace is removed.

\-?([1-9][0-9][0-9][0-9]+)|(0[0-9][0-9][0-9])\-(0[1-9])|(1[0-2])\-(0[1-9])([12][0-9])|(3[01])
 T(([01][0-9])|(2[0-3]):[0-5][0-9]:([0-5][0-9])(\.[0-9]+)?)|(24:00:00(\.0+)?)
   ([+\-](0[0-9])|(1[0-4]):[0-5][0-9])?

Note that neither the dateTimeLexicalRep production nor this regular expression alone enforce the constraint on dateTimeLexicalRep given above.

The ·lexical mapping· for dateTime is ·dateTimeLexicalMap·. The ·canonical mapping· is ·dateTimeCanonicalMap·.

3.3.9.1 Value Space

time uses the date/timeSevenPropertyModel, with ·year·, ·month·, and ·day· required to be absent.  ·timezone· remains ·optional·.

Equality and order are as prescribed in The Seven-property Model (§D.2.1).  time values (points in time in an "arbitrary" day) are ordered taking into account their ·timezone·.

A calendar ( or "local time") day with an early timezone begins earlier than the same calendar day with a later timezone.  Since the timezones allowed spread over 28 hours, there are timezone pairs for which a given calendar day in the two timezones are totally disjoint—the earlier day ends before the same day starts in the later timezone.  The moments in time represented by a single calendar day are spread over a 52-hour interval, from the beginning of the day in the +14:00 timezone to the end of that day in the −14:00 timezone.

3.3.9.4 Lexical Mappings

The lexical representations for time are "projections" of those of dateTime, as follows:

The timeLexicalRep production is equivalent to this regular expression, once whitespace is removed:

(((([01][0-9])|(2[0-3])):([0-5][0-9]):(([0-5][0-9])(\.[0-9]+)?))
  |(24:00:00(\.0+)?))
(Z|((+|-)(0[0-9]|1[0-4]):[0-5][0-9]))?

Note that neither the timeLexicalRep production nor this regular expression alone enforce the constraint on timeLexicalRep given above.

The ·lexical mapping· for time is ·timeLexicalMap·; the ·canonical mapping· is ·timeCanonicalMap·.

3.3.10.1 Value Space

date uses the date/timeSevenPropertyModel, with ·hour·, ·minute·, and ·second· required to be absent.  ·timezone· remains ·optional·.

Equality and order are as prescribed in The Seven-property Model (§D.2.1).

3.3.10.4 Lexical Mappings

The lexical representations for date are "projections" of those of dateTime, as follows:

The dateLexicalRep production is equivalent to this regular expression:

\-?([1-9][0-9][0-9][0-9]+)|(0[0-9][0-9][0-9])\-(0[1-9])|(1[0-2])\-([0-2][0-9])|(3[01])((+|\-)(0[0-9]|1[0-4]):[0-5][0-9])?

Note that neither the dateLexicalRep production nor this regular expression alone enforce the constraint on dateLexicalRep given above.

The ·lexical mapping· for date is ·dateLexicalMap·. The ·canonical mapping· is ·dateCanonicalMap·.

3.3.11.1 Value Space

gYearMonth uses the date/timeSevenPropertyModel, with ·day·, ·hour·, ·minute·, and ·second· required to be absent.  ·timezone· remains ·optional·.

Equality and order are as prescribed in The Seven-property Model (§D.2.1).

3.3.12.1 Value Space

gYear uses the date/timeSevenPropertyModel, with ·month·, ·day·, ·hour·, ·minute·, and ·second· required to be absent.  ·timezone· remains ·optional·.

Equality and order are as prescribed in The Seven-property Model (§D.2.1).