XML Schema 1.1 Part 2: Datatypes

2.6.1.1 Atomic datatypes

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

2.6.1.2 List datatypes

Several type systems (such as the one described in [ISO 11404]) treat ·list· datatypes as special cases of the more general notions of aggregate or collection datatypes.

·list· datatypes are always ·derived·. The ·value space· of a ·list· datatype is a set of finite-length sequences of ·atomic· values. The ·lexical space· of a ·list· datatype is a set of literals whose internal structure is a space-separated sequence of literals of the ·atomic· datatype of the items in the ·list·.

[Definition:]   The ·atomic· or ·union· datatype that participates in the definition of a ·list· datatype is known as the itemType of that ·list· datatype.

<simpleType name='sizes'>
  <list itemType='decimal'/>
</simpleType>

<cerealSizes xsi:type='sizes'> 8 10.5 12 </cerealSizes>

A ·list· datatype can be ·derived· from an ·atomic· datatype whose ·lexical space· allows space (such as string or anyURI)or a ·union· datatype any of whose {member type definitions}'s ·lexical space· allows space. In such a case, regardless of the input, list items will be separated at space boundaries.

<simpleType name='listOfString'>
  <list itemType='string'/>
</simpleType>

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

When a datatype is ·derived· from a ·list· datatype, the following ·constraining facet·s apply:

• ·length·
• ·maxLength·
• ·minLength·
• ·enumeration·
• ·pattern·
• ·whiteSpace·

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

For ·list· datatypes the ·lexical space· is composed of space-separated literals of its ·itemType·.  Hence, any ·pattern· specified when a new datatype is ·derived· from a ·list· datatype is matched against each literal of the ·list· datatype and not against the literals of the datatype that serves as its ·itemType·.

<xs:simpleType name='myList'>
	<xs:list itemType='xs:integer'/>
</xs:simpleType>
<xs:simpleType name='myRestrictedList'>
	<xs:restriction base='myList'>
		<xs:pattern value='123 (\d+\s)*456'/>
	</xs:restriction>
</xs:simpleType>
<someElement xsi:type='myRestrictedList'>123 456</someElement>
<someElement xsi:type='myRestrictedList'>123 987 456</someElement>
<someElement xsi:type='myRestrictedList'>123 987 567 456</someElement>

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

2.6.1.3 Union datatypes

The ·value space· and ·lexical space· of a ·union· datatype are the union of the ·value space·s and ·lexical space·s of its ·memberTypes·. ·union· datatypes are always ·derived·. Currently, there are no ·built-in· ·union· datatypes.

  <attributeGroup name="occurs">
    <attribute name="minOccurs" type="nonNegativeInteger"
    	use="optional" default="1"/>
    <attribute name="maxOccurs"use="optional" default="1">
      <simpleType>
        <union>
          <simpleType>
            <restriction base='nonNegativeInteger'/>
          </simpleType>
          <simpleType>
            <restriction base='string'>
              <enumeration value='unbounded'/>
            </restriction>
          </simpleType>
        </union>
      </simpleType>
    </attribute>
  </attributeGroup>

Any number (greater than 1) of ·atomic· or ·list· ·datatype·s can participate in a ·union· type.

[Definition:]   The datatypes that participate in the definition of a ·union· datatype are known as the memberTypes of that ·union· datatype.

The order in which the ·memberTypes· are specified in the definition (that is, the order of the <simpleType> children of the <union> element, or the order of the QNames in the memberTypes attribute) is significant. During validation, an element or attribute's value is validated against the ·memberTypes· 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.

  <xsd:element name='size'>
    <xsd:simpleType>
      <xsd:union>
        <xsd:simpleType>
          <xsd:restriction base='integer'/>
        </xsd:simpleType>
        <xsd:simpleType>
          <xsd:restriction base='string'/>
        </xsd:simpleType>
      </xsd:union>
    </xsd:simpleType>
  </xsd:element>

  <size>1</size>
  <size>large</size>
  <size xsi:type='xsd:string'>1</size>

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

2.6.2.1 Derived by restriction

[Definition:]  A datatype is said to be ·derived· by restriction from another datatype when values for zero or more ·constraining facet·s are specified that serve to constrain its ·value space· and/or its ·lexical space· to a subset of those of its ·base type·.

[Definition:]  Every datatype that is ·derived· by restriction is defined in terms of an existing datatype, referred to as its base type. base types can be either ·primitive· or ·derived·.

2.6.2.2 Derived by list

A ·list· datatype can be ·derived· from another datatype (its ·itemType·) by creating a ·value space· that consists of a finite-length sequence of values of its ·itemType·.

2.6.2.3 Derived by union

One datatype can be ·derived· from one or more datatypes by ·union·ing their ·value space·s and, consequently, their ·lexical space·s.

3.2.1.1 Constraining facets

string has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.2.1.2 Derived datatypes

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

• normalizedString

3.2.2.1 Lexical representation

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

3.2.2.2 Canonical representation

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

3.2.2.3 Constraining facets

boolean has the following ·constraining facets·:

• pattern
• whiteSpace

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

3.2.3.2 Canonical representation

The canonical representation for decimal is defined by prohibiting certain options from the Lexical representation (§3.2.3.1).  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.

3.2.3.3 Constraining facets

decimal has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.2.3.4 Derived datatypes

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

• integer

3.2.4.1 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 ·must· be an integer. The mantissa must be a decimal number. The representations for exponent and mantissa must follow the lexical rules for integer and decimal.  If the "E" or "e" and the following exponent are omitted, an exponent value of 0 is assumed.

The special values positive and negative infinity and not-a-number have lexical representations 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.

3.2.4.2 Canonical representation

The canonical representation for float is defined by prohibiting certain options from the Lexical representation (§3.2.4.1).  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. 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.

3.2.4.3 Constraining facets

float has the following ·constraining facets·:

• pattern
• enumeration
• whiteSpace
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.2.5.1 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 ·must· be an integer.  The mantissa must be a decimal number. The representations for exponent and mantissa must follow the lexical rules for integer and decimal.  If the "E" or "e" and the following exponent are omitted, an exponent value of 0 is assumed.

The special values positive and negative infinity and not-a-number have lexical representations 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 double.

3.2.5.2 Canonical representation

The canonical representation for double is defined by prohibiting certain options from the Lexical representation (§3.2.5.1).  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. 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.

3.2.5.3 Constraining facets

double has the following ·constraining facets·:

• pattern
• enumeration
• whiteSpace
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.2.6.1 Value Space

Equality and order for precisionDecimal are defined as follows:

• Two numerical precisionDecimal values are ordered (or equal) as their ·numericalValue· values are ordered (or equal).  (This means the two zeros with a given ·arthmeticPrecision· but different ·sign· are equal; negative zeros are not ordered less than positive zeros.)
• INF is equal only to itself, and is greater than –INF and all numerical precisionDecimal values.
• –INF is equal only to itself, and is less than INF and all numerical precisionDecimal values.
• NaN is incomparable with all values, including itself.

3.2.6.2 Lexical Mapping

Editorial Note: The notation constraining facet has not yet been written up.  Its effect will be to remove some portions of the lexical mapping.

precisionDecimal's lexical space is the set of all no-decimal-point, decimal, and scientific numerals, plus the character strings 'INF', '+INF', '-INF', and 'NaN'.  (Lexical representations of numbers are traditionally called "numerals".)  The notation constraining facet can remove any one or two of the three subsets of numerals, with corresponding reductions in the value space.  Using this facet rather than pattern will change the canonical mapping to insure that the resulting datatype will still have canonical representations of all its values.

3.2.6.3 Constraining Facets

Editorial Note: The notation constraining facet has not yet been written up.  It's effect will be to remove some portions of the lexical mapping.

precisionDecimal has the following ·constraining facets·:

• fractionDigits
• minFractionDigits
• totalDigits
• specials
• notation constraining
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive
• pattern
• whitespace
• eunmeration

3.2.7.1 Value Space

Durations can be modeled in at least two ways: as six-property tuples (similar to the seven-property model used for other date/time datatypes) or as two-property tuples (somewhat similar to the alternative one-property timeOnTimeline model especially useful for dateTime order).  For durations, it is useful to use the latter: duration values are two-property tuples.  (Note, however, that the six-property model was implicitly used in Schema 1.0.  The only effective difference to the user caused by this change is in the canonical representations.)  See The Seven-property Model (§D.2.2) for more information on the seven-property model.

duration is partially ordered.  Equality and order are defined in terms of that of dateTime, and are determined by adding each duration value pair in turn to 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.

It turns out that under the definition just given, two duration values are equal if and only if they are identical.

3.2.7.2 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 durationLexicalRep production is equivalent to this regular expression

-?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) ) )) ) ) ) )

once you delete the whitespace.  Redundant parehtheses are shown as "ghosts"; some find them helpful in reading the expression.)

The ·lexical mapping· for duration is called "·durationMap·" herein.

·The canonical mapping· for duration is called "·durationCanonicalMap·" herein.

3.2.7.3 Constraining Facets

duration has the following ·constraining facets·:

• pattern
• enumeration
• whiteSpace
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.2.8.1 Lexical representation

The ·lexical space· of dateTime consists of finite-length sequences of characters of the form: '-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?, where

• '-'? yyyy is a four-or-more digit optionally negative-signed numeral that represents the year; if more than four digits, leading zeros are prohibited, and '0000' is prohibited (see the Note above (§3.2.8); also note that a plus sign is not permitted);
• the remaining '-'s are separators between parts of the date portion;
• the first mm is a two-digit numeral that represents the month;
• dd is a two-digit numeral that represents the day;
• 'T' is a separator indicating that time-of-day follows;
• hh is a two-digit numeral that represents the hour; '24' is permitted if the minutes and seconds represented are zero, and the dateTime value so represented is the first instant of the following day (the hour property of a dateTime object in the ·value space· cannot have a value greater than 23);
• ':' is a separator between parts of the time-of-day portion;
• the second mm is a two-digit numeral that represents the minute;
• ss is a two-integer-digit numeral that represents the whole seconds;
• '.' s+ (if present) represents the fractional seconds;
• zzzzzz (if present) represents the timezone (as described below).

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 2002-10-10T17:00:00Z, five hours later than 2002-10-10T12:00:00Z.

For further guidance on arithmetic with dateTimes and durations, see Adding durations to dateTimes (§H).

3.2.8.2 Canonical representation

Except for trailing fractional zero digits in the seconds representation, '24:00:00' time representations, and timezone (for timezoned values), the mapping from literals to values is one-to-one. Where there is more than one possible representation, the canonical representation is as follows:

• The 2-digit numeral representing the hour must not be '24';
• The fractional second string, if present, must not end in '0';
• for timezoned values, the timezone must be represented with 'Z' (All timezoned dateTime values are ·UTC·.).

3.2.8.3 Timezones

Timezones are durations with (integer-valued) hour and minute properties (with the hour magnitude limited to at most 14, and the minute magnitude limited to at most 59, except that if the hour magnitude is 14, the minute value must be 0); they may be both positive or both negative.

The lexical representation of a timezone is a string of the form: (('+' | '-') hh ':' mm) | 'Z', where

• hh is a two-digit numeral (with leading zeros as required) that represents the hours,
• mm is a two-digit numeral that represents the minutes,
• '+' indicates a nonnegative duration,
• '-' indicates a nonpositive duration.

The mapping so defined is one-to-one, except that '+00:00', '-00:00', and 'Z' all represent the same zero-length duration timezone, ·UTC·; 'Z' is its canonical representation.

When a timezone is added to a ·UTC· dateTime, the result is the date and time "in that timezone".  For example, 2002-10-10T12:00:00+05:00 is 2002-10-10T07:00:00Z and 2002-10-10T00:00:00+05:00 is 2002-10-09T19:00:00Z.

3.2.8.4 Order relation on dateTime

dateTime value objects on either timeline are totally ordered by their timeOnTimeline values; between the two timelines, dateTime value objects are ordered by their timeOnTimeline values when their timeOnTimeline values differ by more than fourteen hours, with those whose difference is a duration of 14 hours or less being incomparable.

In general, the ·order-relation· on dateTime is a partial order since there is no determinate relationship between certain instants. For example, there is no determinate ordering between (a) 2000-01-20T12:00:00 and (b) 2000-01-20T12:00:00Z. Based on timezones currently in use, (c) could vary from 2000-01-20T12:00:00+12:00 to 2000-01-20T12:00:00-13:00. It is, however, possible for this range to expand or contract in the future, based on local laws. Because of this, the following definition uses a somewhat broader range of indeterminate values: +14:00..-14:00.

The following definition uses the notation S[year] to represent the year field of S, S[month] to represent the month field, and so on. The notation (Q & "-14:00") means adding the timezone -14:00 to Q, where Q did not already have a timezone. This is a logical explanation of the process. Actual implementations are free to optimize as long as they produce the same results.

The ordering between two dateTimes P and Q is defined by the following algorithm:

A.Normalize P and Q. That is, if there is a timezone present, but it is not Z, convert it to Z using the addition operation defined in Adding durations to dateTimes (§H)

• Thus 2000-03-04T23:00:00+03:00 normalizes to 2000-03-04T20:00:00Z

B. If P and Q either both have a time zone or both do not have a time zone, compare P and Q field by field from the year field down to the second field, and return a result as soon as it can be determined. That is:

1. For each i in {year, month, day, hour, minute, second}
   1. If P[i] and Q[i] are both not specified, continue to the next i
   2. If P[i] is not specified and Q[i] is, or vice versa, stop and return P <> Q
   3. If P[i] < Q[i], stop and return P < Q
   4. If P[i] > Q[i], stop and return P > Q
2. Stop and return P = Q

C.Otherwise, if P contains a time zone and Q does not, compare as follows:

1. P < Q if P < (Q with time zone +14:00)
2. P > Q if P > (Q with time zone -14:00)
3. P <> Q otherwise, that is, if (Q with time zone +14:00) < P < (Q with time zone -14:00)

D. Otherwise, if P does not contain a time zone and Q does, compare as follows:

1. P < Q if (P with time zone -14:00) < Q.
2. P > Q if (P with time zone +14:00) > Q.
3. P <> Q otherwise, that is, if (P with time zone +14:00) < Q < (P with time zone -14:00)

Examples:

3.2.8.5 Totally ordered dateTimes

Certain derived types from dateTime can be guaranteed have a total order. To do so, they must require that a specific set of fields are always specified, and that remaining fields (if any) are always unspecified. For example, the date datatype without time zone is defined to contain exactly year, month, and day. Thus dates without time zone have a total order among themselves.

3.2.8.6 Constraining facets

dateTime has the following ·constraining facets·:

• pattern
• enumeration
• whiteSpace
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.2.9.1 Lexical representation

The lexical representation for time is the left truncated lexical representation for dateTime: hh:mm:ss.sss with optional following time zone indicator.  For example, to indicate 1:20 pm for Eastern Standard Time which is 5 hours behind Coordinated Universal Time (·UTC·), one would write: 13:20:00-05:00. See also ISO 8601 Date and Time Formats (§G).

3.2.9.2 Canonical representation

The canonical representation for time is defined by prohibiting certain options from the Lexical representation (§3.2.9.1).  Specifically, either the time zone must be omitted or, if present, the time zone must be Coordinated Universal Time (·UTC·) indicated by a "Z". Additionally, the canonical representation for midnight is 00:00:00.

3.2.9.3 Constraining facets

time has the following ·constraining facets·:

• pattern
• enumeration
• whiteSpace
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.2.10.1 Lexical representation

For the following discussion, let the "date portion" of a dateTime or date object be an object similar to a dateTime or date object, with similar year, month, and day properties, but no others, having the same value for these properties as the original dateTime or date object.

The ·lexical space· of date consists of finite-length sequences of characters of the form: '-'? yyyy '-' mm '-' dd zzzzzz? where the date and optional timezone are represented exactly the same way as they are for dateTime.  The first moment of the interval is that represented by: '-' yyyy '-' mm '-' dd 'T00:00:00' zzzzzz? and the least upper bound of the interval is the timeline point represented (noncanonically) by: '-' yyyy '-' mm '-' dd 'T24:00:00' zzzzzz?.

3.2.10.2 Canonical representation

Given a member of the date ·value space·, the date portion of the canonical representation (the entire representation for nontimezoned values, and all but the timezone representation for timezoned values) is always the date portion of the dateTime canonical representation of the interval midpoint (the dateTime representation, truncated on the right to eliminate 'T' and all following characters). For timezoned values, append the canonical representation of the ·recoverable timezone·.

3.2.11.1 Lexical representation

The lexical representation for gYearMonth is the reduced (right truncated) lexical representation for dateTime: CCYY-MM.  No left truncation is allowed.  An optional following time zone qualifier is allowed.  To accommodate year values outside the range from 0001 to 9999, additional digits can be added to the left of this representation and a preceding "-" sign is allowed.

For example, to indicate the month of May 1999, one would write: 1999-05. See also ISO 8601 Date and Time Formats (§G).

3.2.11.2 Constraining facets

gYearMonth has the following ·constraining facets·:

• pattern
• enumeration
• whiteSpace
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.2.12.1 Lexical representation

The lexical representation for gYear is the reduced (right truncated) lexical representation for dateTime: CCYY. No left truncation is allowed.  An optional following time zone qualifier is allowed as for dateTime.  To accommodate year values outside the range from 0001 to 9999, additional digits can be added to the left of this representation and a preceding "-" sign is allowed.

For example, to indicate 1999, one would write: 1999. See also ISO 8601 Date and Time Formats (§G).

3.2.12.2 Constraining facets

gYear has the following ·constraining facets·:

• pattern
• enumeration
• whiteSpace
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.2.13.1 Lexical representation

The lexical representation for gMonthDay is the left truncated lexical representation for date: --MM-DD. An optional following time zone qualifier is allowed as for date. No preceding sign is allowed.  No other formats are allowed. See also ISO 8601 Date and Time Formats (§G).

This datatype can be used to represent a specific day in a month. To say, for example, that my birthday occurs on the 14th of September ever year.

3.2.13.2 Constraining facets

gMonthDay has the following ·constraining facets·:

• pattern
• enumeration
• whiteSpace
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.2.14.1 Value Space

gDay uses the date/timeSevenPropertyModel, with ·year·, ·month·, ·hour·, ·minute·, and ·second· required to be absent.  ·timezone· remains ·optional· and ·day· must be between 1 and 31 inclusive.

Equality and order are as prescribed in The Seven-property Model (§D.2.2).  Since gDay values (days) are ordered by their first moments, it is possible for apparent anomalies to appear in the order when ·timezone· values are differ by at least 24 hours.  (It is possible for ·timezone· values to differ by up to 28 hours.)

Examples that may appear anomalous (see Lexical Mappings (§3.2.14.3) for the notations):

• ---15 < ---16 , but  ---15–13:00 > ---16+13:00
• ---15–11:00 = ---16+13:00
• ---15–13:00 <> ---16 , because  ---15–13:00 > ---16+14:00  and ---15–13:00 < 16–14:00

3.2.14.3 Lexical Mappings

The lexical representations for gDay are "restrictions" of those of dateTime, as follows:

The gDayLexicalRep is equivalent to this regular expression:

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

The lexical mapping and canonical mapping for gDay are defined as follows:

3.2.14.4 Constraining Facets

gDay has the following ·constraining facets·:

• pattern
• enumeration
• whiteSpace
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.2.15.1 Lexical representation

The lexical representation for gMonth is the left and right truncated lexical representation for date: --MM. An optional following time zone qualifier is allowed as for date.  No preceding sign is allowed. No other formats are allowed.  See also ISO 8601 Date and Time Formats (§G).

3.2.15.2 Constraining facets

gMonth has the following ·constraining facets·:

• pattern
• enumeration
• whiteSpace
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.2.16.1 Lexical Representation

hexBinary has a lexical representation where each binary octet is encoded as a character tuple, consisting of two hexadecimal digits ([0-9a-fA-F]) representing the octet code. For example, "0FB7" is a hex encoding for the 16-bit integer 4023 (whose binary representation is 111110110111).

3.2.16.2 Canonical Representation

The canonical representation for hexBinary is defined by prohibiting certain options from the Lexical Representation (§3.2.16.1).  Specifically, the lower case hexadecimal digits ([a-f]) are not allowed.

3.2.16.3 Constraining facets

hexBinary has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.2.17.1 Constraining facets

base64Binary has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.2.18.1 Lexical representation

The ·lexical space· of anyURI is finite-length character sequences which, when the algorithm defined in Section 5.4 of [XML Linking Language] is applied to them, result in strings which are legal URIs according to [RFC 2396], as amended by [RFC 2732].

3.2.18.2 Constraining facets

anyURI has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.2.19.1 Constraining facets

QName has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

The use of ·length·, ·minLength· and ·maxLength· on datatypes ·derived· from QName is deprecated.  Future versions of this specification may remove these facets for this datatype.

3.2.20.1 Constraining facets

NOTATION has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

The use of ·length·, ·minLength· and ·maxLength· on datatypes ·derived· from NOTATION is deprecated.  Future versions of this specification may remove these facets for this datatype.

3.3.1.1 Constraining facets

normalizedString has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.3.1.2 Derived datatypes

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

• token

3.3.2.1 Constraining facets

token has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.3.2.2 Derived datatypes

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

• language
• NMTOKEN
• Name

3.3.3.1 Constraining facets

language has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.3.4.1 Constraining facets

NMTOKEN has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.3.4.2 Derived datatypes

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

• NMTOKENS

3.3.5.1 Constraining facets

NMTOKENS has the following ·constraining facets·:

• length
• minLength
• maxLength
• enumeration
• whiteSpace
• pattern

3.3.6.1 Constraining facets

Name has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.3.6.2 Derived datatypes

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

• NCName

3.3.7.1 Constraining facets

NCName has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.3.7.2 Derived datatypes

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

• ID
• IDREF
• ENTITY

3.3.8.1 Constraining facets

ID has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.3.9.1 Constraining facets

IDREF has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.3.9.2 Derived datatypes

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

• IDREFS

3.3.10.1 Constraining facets

IDREFS has the following ·constraining facets·:

• length
• minLength
• maxLength
• enumeration
• whiteSpace
• pattern

3.3.11.1 Constraining facets

ENTITY has the following ·constraining facets·:

• length
• minLength
• maxLength
• pattern
• enumeration
• whiteSpace

3.3.11.2 Derived datatypes

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

• ENTITIES

3.3.12.1 Constraining facets

ENTITIES has the following ·constraining facets·:

• length
• minLength
• maxLength
• enumeration
• whiteSpace
• pattern

3.3.13.1 Lexical representation

integer has a lexical representation consisting of a finite-length sequence of decimal digits (#x30-#x39) with an optional leading sign.  If the sign is omitted, "+" is assumed.  For example: -1, 0, 12678967543233, +100000.

3.3.13.2 Canonical representation

The canonical representation for integer is defined by prohibiting certain options from the Lexical representation (§3.3.13.1).  Specifically, the preceding optional "+" sign is prohibited and leading zeroes are prohibited.

3.3.13.3 Constraining facets

integer has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.13.4 Derived datatypes

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

• nonPositiveInteger
• long
• nonNegativeInteger

3.3.14.1 Lexical representation

nonPositiveInteger has a lexical representation consisting of an optional preceding sign followed by a finite-length sequence of decimal digits (#x30-#x39). The sign may be "+" or may be omitted only for lexical forms denoting zero; in all other lexical forms, the negative sign ("-") must be present. For example: -1, 0, -12678967543233, -100000.

3.3.14.2 Canonical representation

The canonical representation for nonPositiveInteger is defined by prohibiting certain options from the Lexical representation (§3.3.14.1). In the canonical form for zero, the sign must be omitted.  Leading zeroes are prohibited.

3.3.14.3 Constraining facets

nonPositiveInteger has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.14.4 Derived datatypes

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

• negativeInteger

3.3.15.1 Lexical representation

negativeInteger has a lexical representation consisting of a negative sign ("-") followed by a finite-length sequence of decimal digits (#x30-#x39).  For example: -1, -12678967543233, -100000.

3.3.15.2 Canonical representation

The canonical representation for negativeInteger is defined by prohibiting certain options from the Lexical representation (§3.3.15.1).  Specifically, leading zeroes are prohibited.

3.3.15.3 Constraining facets

negativeInteger has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.16.1 Lexical representation

long has a lexical representation consisting of an optional sign followed by a finite-length sequence of decimal digits (#x30-#x39).  If the sign is omitted, "+" is assumed. For example: -1, 0, 12678967543233, +100000.

3.3.16.2 Canonical representation

The canonical representation for long is defined by prohibiting certain options from the Lexical representation (§3.3.16.1).  Specifically, the the optional "+" sign is prohibited and leading zeroes are prohibited.

3.3.16.3 Constraining facets

long has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.16.4 Derived datatypes

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

• int

3.3.17.1 Lexical representation

int has a lexical representation consisting of an optional sign followed by a finite-length sequence of decimal digits (#x30-#x39).  If the sign is omitted, "+" is assumed. For example: -1, 0, 126789675, +100000.

3.3.17.2 Canonical representation

The canonical representation for int is defined by prohibiting certain options from the Lexical representation (§3.3.17.1).  Specifically, the the optional "+" sign is prohibited and leading zeroes are prohibited.

3.3.17.3 Constraining facets

int has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.17.4 Derived datatypes

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

• short

3.3.18.1 Lexical representation

short has a lexical representation consisting of an optional sign followed by a finite-length sequence of decimal digits (#x30-#x39).  If the sign is omitted, "+" is assumed. For example: -1, 0, 12678, +10000.

3.3.18.2 Canonical representation

The canonical representation for short is defined by prohibiting certain options from the Lexical representation (§3.3.18.1).  Specifically, the the optional "+" sign is prohibited and leading zeroes are prohibited.

3.3.18.3 Constraining facets

short has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.18.4 Derived datatypes

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

• byte

3.3.19.1 Lexical representation

byte has a lexical representation consisting of an optional sign followed by a finite-length sequence of decimal digits (#x30-#x39).  If the sign is omitted, "+" is assumed. For example: -1, 0, 126, +100.

3.3.19.2 Canonical representation

The canonical representation for byte is defined by prohibiting certain options from the Lexical representation (§3.3.19.1).  Specifically, the the optional "+" sign is prohibited and leading zeroes are prohibited.

3.3.19.3 Constraining facets

byte has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.20.1 Lexical representation

nonNegativeInteger has a lexical representation consisting of an optional sign followed by a finite-length sequence of decimal digits (#x30-#x39).  If the sign is omitted, the positive sign ("+") is assumed. If the sign is present, it must be "+" except for lexical forms denoting zero, which may be preceded by a positive ("+") or a negative ("-") sign. For example: 1, 0, 12678967543233, +100000.

3.3.20.2 Canonical representation

The canonical representation for nonNegativeInteger is defined by prohibiting certain options from the Lexical representation (§3.3.20.1).  Specifically, the the optional "+" sign is prohibited and leading zeroes are prohibited.

3.3.20.3 Constraining facets

nonNegativeInteger has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.20.4 Derived datatypes

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

• unsignedLong
• positiveInteger

3.3.21.1 Lexical representation

unsignedLong has a lexical representation consisting of a finite-length sequence of decimal digits (#x30-#x39). For example: 0, 12678967543233, 100000.

3.3.21.2 Canonical representation

The canonical representation for unsignedLong is defined by prohibiting certain options from the Lexical representation (§3.3.21.1).  Specifically, leading zeroes are prohibited.

3.3.21.3 Constraining facets

unsignedLong has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.21.4 Derived datatypes

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

• unsignedInt

3.3.22.1 Lexical representation

unsignedInt has a lexical representation consisting of a finite-length sequence of decimal digits (#x30-#x39).  For example: 0, 1267896754, 100000.

3.3.22.2 Canonical representation

The canonical representation for unsignedInt is defined by prohibiting certain options from the Lexical representation (§3.3.22.1).  Specifically, leading zeroes are prohibited.

3.3.22.3 Constraining facets

unsignedInt has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.22.4 Derived datatypes

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

• unsignedShort

3.3.23.1 Lexical representation

unsignedShort has a lexical representation consisting of a finite-length sequence of decimal digits (#x30-#x39). For example: 0, 12678, 10000.

3.3.23.2 Canonical representation

The canonical representation for unsignedShort is defined by prohibiting certain options from the Lexical representation (§3.3.23.1).  Specifically, the leading zeroes are prohibited.

3.3.23.3 Constraining facets

unsignedShort has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.23.4 Derived datatypes

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

• unsignedByte

3.3.24.1 Lexical representation

unsignedByte has a lexical representation consisting of a finite-length sequence of decimal digits (#x30-#x39). For example: 0, 126, 100.

3.3.24.2 Canonical representation

The canonical representation for unsignedByte is defined by prohibiting certain options from the Lexical representation (§3.3.24.1).  Specifically, leading zeroes are prohibited.

3.3.24.3 Constraining facets

unsignedByte has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.25.1 Lexical representation

positiveInteger has a lexical representation consisting of an optional positive sign ("+") followed by a finite-length sequence of decimal digits (#x30-#x39). For example: 1, 12678967543233, +100000.

3.3.25.2 Canonical representation

The canonical representation for positiveInteger is defined by prohibiting certain options from the Lexical representation (§3.3.25.1).  Specifically, the optional "+" sign is prohibited and leading zeroes are prohibited.

3.3.25.3 Constraining facets

positiveInteger has the following ·constraining facets·:

• totalDigits
• fractionDigits
• pattern
• whiteSpace
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive

3.3.26.1 The yearMonthDuration Lexical Mapping

The lexical space is reduced from that of duration by disallowing duDayFrag and duTimeFrag fragments in the ·lexical representations·. The ·lexical mapping·, called "·yearMonthDurationMap·" herein, is that of duration restricted to the yearMonthDuration lexical space.

The regular expression '-?P([0-9]+Y)?([0-9]+M)?' has instances that are not in the lexical space—but they are not in the lexical space of duration either, so it serves as a relatively simple regular expression that extracts from the ·lexical space· of duration those representations that are instances of yearMonthDuration.

The ·canonical mapping· is that of duration restricted in its range to the ·lexical space· (which reduces its domain to omit any values not in the yearMonthDuration value space).

3.3.26.2 Constraining Facets

yearMonthDuration has the following ·constraining facets·:

• pattern
• eunmeration
• whitespace
• minInclusive
• minExclusive
• maxInclusive
• maxExclusive

3.3.27.1 The dayTimeDuration Lexical Space

The lexical space is reduced from that of duration by disallowing duYearFrag and duMonthFrag fragments in the ·lexical representations·. The ·lexical mapping·, called "·dayTimeDurationMap·" herein, is that of duration restricted to the dayTimeDuration lexical space.

The regular expression '-?P([0-9]+D)?(T([0-9]+H)?([0-9]+M)?([0-9]+(.[0-9]+)?S)?)?' has several instances that are not in the lexical space—but they are not in the lexical space of duration either, so it serves as a relatively simple regular expression that extracts from the ·lexical space· of duration those representations that are instances of dayTimeDurationLexicalRep.

The ·canonical mapping· is that of duration restricted to the ·value space· The ·canonical mapping· is that of duration restricted to the yearMonthDuration value space.

3.3.27.2 Constraining Facets

dayTimeDuration has the following ·constraining facets·:

• pattern
• eunmeration
• whitespace
• minInclusive
• minExclusive
• maxInclusive
• maxExclusive

4.1.2.1 Derivation by restriction

<simpleType name='Sku'>
    <restriction base='string'>
      <pattern value='\d{3}-[A-Z]{2}'/>
    </restriction>
</simpleType>

4.1.2.2 Derivation by list

A ·list· datatype must be ·derived· from an ·atomic· or a ·union· datatype, known as the ·itemType· of the ·list· datatype. This yields a datatype whose ·value space· is composed of finite-length sequences of values from the ·value space· of the ·itemType· and whose ·lexical space· is composed of space-separated lists of literals of the ·itemType·.

<simpleType name='listOfFloat'>
  <list itemType='float'/>
</simpleType>

As mentioned in List datatypes (§2.6.1.2), when a datatype is ·derived· from a ·list· datatype, the following ·constraining facet·s can be used:

• ·length·
• ·maxLength·
• ·minLength·
• ·enumeration·
• ·pattern·
• ·whiteSpace·

regardless of the ·constraining facet·s that are applicable to the ·atomic· datatype that serves as the ·itemType· of the ·list·.

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

4.1.2.3 Derivation by union

A ·union· datatype can be ·derived· from one or more ·atomic·, ·list· or other ·union· datatypes, known as the ·memberTypes· of that ·union· datatype.

<xsd:attribute name="size">
  <xsd:simpleType>
    <xsd:union>
      <xsd:simpleType>
        <xsd:restriction base="xsd:positiveInteger">
          <xsd:minInclusive value="8"/>
          <xsd:maxInclusive value="72"/>
        </xsd:restriction>
      </xsd:simpleType>
      <xsd:simpleType>
        <xsd:restriction base="xsd:NMTOKEN">
          <xsd:enumeration value="small"/>
          <xsd:enumeration value="medium"/>
          <xsd:enumeration value="large"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:union>
  </xsd:simpleType>
</xsd:attribute>

<p>
<font size='large'>A header</font>
</p>
<p>
<font size='12'>this is a test</font>
</p>

As mentioned in Union datatypes (§2.6.1.3), when a datatype is ·derived· from a ·union· datatype, the only following ·constraining facet·s can be used:

• ·pattern·
• ·enumeration·

regardless of the ·constraining facet·s that are applicable to the datatypes that participate in the ·union·

4.3.1.1 The ordered Schema Component

Editorial Note: The writeup here has been changed to look more like the way logic is currently presented in Part 1.  Some find it harder to understand.  The editors are trying to harmonize the two.  Until this is sorted out in "editors' committee", the other facet writeups are not going to change.  This will not occur before second working draft.

{value} depends on the ·parent's· {variety}, {facets} and {member type definitions}.

4.3.2.1 The bounded Schema Component

{value} depends on the ·parent's· {variety}, {facets} and {member type definitions}.

When the ·parent· is ·primitive·, {value} is as specified in the table in Fundamental Facets (§F.1).  Otherwise, when the ·parent's· {variety} is atomic, if one of minInclusive or minExclusive and one of maxInclusive or maxExclusive are members of the ·parent's· {facets} set, then {value} is true; otherwise {value} is false.

When the ·parent's· {variety} is list, {value} is false.

When the ·parent's· {variety} is union, if {value} is true for every member of the ·parent's· {member type definitions} set and all of these share a common ancestor, then {value} is true; otherwise {value} is false.

4.3.3.1 The cardinality Schema Component

{value} depends on the ·parent's· {variety}, {facets}, and {member type definitions}.

When the ·parent· is ·primitive·, {value} is as specified in the table in Fundamental Facets (§F.1).  Otherwise, when the ·parent's· {variety} is atomic, {value} is countably infinite unless any of the following conditions are true, in which case {value} is finite:

1. the ·parent's· {base type definition}'s cardinality {value} is finite,
2. at least one of length, maxLength, or totalDigits is a member of the ·parent's· {facets} set,
3. all of the following are true:
   1. one of minInclusive or minExclusive is a member of the ·parent's· {facets} set
   2. one of maxInclusive or maxExclusive is a member of the ·parent's· {facets} set
   3. either of the following are true:
      1. fractionDigits is a member of the ·parent's· {facets} set
      2. {primitive type definition} is one of date, gYearMonth, gYear, gMonthDay, gDay or gMonth

When the ·parent's· {variety} is list, if length or both minLength and maxLength are members of the ·parent's· {facets} set and the ·parent's· {item type definition}'s cardinality {value} is finite then {value} is finite; otherwise {value} is countably infinite.

When the ·parent's· {variety} is union, if cardinality's {value} is finite for every member of the ·parent's· {member type definitions} set then {value} is finite, otherwise {value} is countably infinite.

4.3.4.1 The numeric Schema Component

{value} depends on the ·parent's· {variety}, {facets}, {base type definition} and {member type definitions}.

When the ·parent· is ·primitive·, {value} is as specified in the table in Fundamental Facets (§F.1).  Otherwise, when the ·parent's· {variety} is atomic, {value} is inherited from the ·parent's· {base type definition}'s numeric{value}.

When the ·parent's· {variety} is list, {value} is false.

When the ·parent's· {variety} is union, if numeric's {value} is true for every member of the ·parent's· {member type definitions} set then {value} is true, otherwise {value} is false.

4.4.1.1 The length Schema Component

If {fixed} is true, then types for which the current type is the {base type definition} cannot specify a value for length other than {value}.

4.4.1.2 XML Representation of length Schema Components

The XML representation for a length schema component is a <length> element information item. The correspondences between the properties of the information item and properties of the component are as follows: