XML Schema Part 2: Datatypes Second Edition

2.3.1 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 ·value space· is denoted by a single literal in its ·lexical space·, this is not always the case. The example in the previous section showed two literals for the datatype float which denote the same value. Similarly, there ·may· be several literals for one of the date or time datatypes that denote the same value using different timezone indicators.

[Definition:]  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 ·value space·.

2.4.1 Fundamental facets

[Definition:]   A fundamental facet is an abstract property which serves to semantically characterize the values in a ·value space·.

All fundamental facets are fully described in Fundamental Facets (§4.2).

2.4.2 Constraining or Non-fundamental facets

[Definition:]  A constraining facet is an optional property that can be applied to a datatype to constrain its ·value space·.

Constraining the ·value space· consequently constrains the ·lexical space·. Adding ·constraining facet·s to a ·base type· is described in Derivation by restriction (§4.1.2.1).

All constraining facets are fully described in Constraining Facets (§4.3).

2.5.1 Atomic vs. list vs. union datatypes

The first distinction to be made is that between ·atomic·, ·list· and ·union· datatypes.

• [Definition:]  Atomic datatypes are those having values which are regarded by this specification as being indivisible.
• [Definition:]  List datatypes are those having values each of which consists of a finite-length (possibly empty) sequence of values of an ·atomic· datatype.
• [Definition:]  Union datatypes are those whose ·value space·s and ·lexical space·s are the union of the ·value space·s and ·lexical space·s of one or more other datatypes.

For example, a single token which ·match·es Nmtoken from [XML 1.0 (Second Edition)] could be the value of an ·atomic· datatype (NMTOKEN); while a sequence of such tokens could be the value of a ·list· datatype (NMTOKENS).

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

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

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

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

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

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

2.5.2 Primitive vs. derived datatypes

Next, we distinguish between ·primitive· and ·derived· datatypes.

• [Definition:]  Primitive datatypes are those that are not defined in terms of other datatypes; they exist ab initio.
• [Definition:]  Derived datatypes are those that are defined in terms of other datatypes.

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

[Definition:]   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 ·base type· of all ·primitive· datatypes. anySimpleType is considered to have an unconstrained lexical space and a ·value space· consisting of the union of the ·value space·s of all the ·primitive· datatypes and the set of all lists of all members of the ·value space·s of all the ·primitive· datatypes.

The datatypes defined by this specification fall into both the ·primitive· and ·derived· categories. It is felt that a judiciously chosen set of ·primitive· 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 ·derived·.

In the example above, integer is ·derived· from decimal.

As described in more detail in XML Representation of Simple Type Definition Schema Components (§4.1.2), each ·user-derived· datatype ·must· be defined in terms of another datatype in one of three ways: 1) by assigning ·constraining facet·s which serve to restrict the ·value space· of the ·user-derived· datatype to a subset of that of the ·base type·; 2) by creating a ·list· datatype whose ·value space· consists of finite-length sequences of values of its ·itemType·; or 3) by creating a ·union· datatype whose ·value space· consists of the union of the ·value space·s of its ·memberTypes·.

2.5.3 Built-in vs. user-derived datatypes

• [Definition:]  Built-in datatypes are those which are defined in this specification, and can be either ·primitive· or ·derived·;
• [Definition:]   User-derived datatypes are those ·derived· datatypes that are defined by individual schema designers.

Conceptually there is no difference between the ·built-in· ·derived· datatypes included in this specification and the ·user-derived· datatypes which will be created by individual schema designers. The ·built-in· ·derived· 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 ·derived· datatypes in this specification serves to demonstrate the mechanics and utility of the datatype generation facilities of this specification.

3.2.1 string

[Definition:]  The string datatype represents character strings in XML. The ·value space· of string is the set of finite-length sequences of characters (as defined in [XML 1.0 (Second Edition)]) that ·match· the Char production from [XML 1.0 (Second Edition)]. 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.

3.2.2 boolean

[Definition:]  boolean has the ·value space· required to support the mathematical concept of binary-valued logic: {true, false}.

3.2.3 decimal

[Definition:]  decimal represents a subset of the real numbers, which can be represented by decimal numerals. The ·value space· 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 >= 0. Precision is not reflected in this value space; the number 2.0 is not distinct from the number 2.00. The ·order-relation· on decimal is the order relation on real numbers, restricted to this subset.

3.2.4 float

[Definition:]  float is patterned after the IEEE single-precision 32-bit floating point type [IEEE 754-1985]. The basic ·value space· 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 ·value space· described above, the ·value space· of float also contains the following three special values: positive and negative infinity and not-a-number (NaN). The ·order-relation· 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 ·incomparable· with (neither greater than nor less than) any other value in the ·value space·.

A literal in the ·lexical space· representing a decimal number d maps to the normalized value in the ·value space· of float that is closest to d in the sense defined by [Clinger, WD (1990)]; if d is exactly halfway between two such values then the even value is chosen.

3.2.5 double

[Definition:]  The double datatype is patterned after the IEEE double-precision 64-bit floating point type [IEEE 754-1985]. The basic ·value space· 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 ·value space· described above, the ·value space· of double also contains the following three special values: positive and negative infinity and not-a-number (NaN). The ·order-relation· 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 ·incomparable· with (neither greater than nor less than) any other value in the ·value space·.

A literal in the ·lexical space· representing a decimal number d maps to the normalized value in the ·value space· 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 ([Clinger, WD (1990)], [Gay, DM (1990)]), which is more accurate than the mapping required by [IEEE 754-1985].

3.2.6 duration

[Definition:]   duration represents a duration of time. The ·value space· 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 [ISO 8601], respectively. These components are ordered in their significance by their order of appearance i.e. as year, month, day, hour, minute, and second.

<simpleType name='SQL-Year-Month-Interval'>
    <restriction base='duration'>
      <pattern value='P\p{Nd}{4}Y\p{Nd}{2}M'/>
    </restriction>
</simpleType>

3.2.7 dateTime

[Definition:]   dateTime values may be viewed as objects with integer-valued year, month, day, hour and minute properties, a decimal-valued second property, and a boolean timezoned property. Each such object also has one decimal-valued method or computed property, timeOnTimeline, whose value is always a decimal number; the values are dimensioned in seconds, the integer 0 is 0001-01-01T00:00:00 and the value of timeOnTimeline for other dateTime values is computed using the Gregorian algorithm as modified for leap-seconds. The timeOnTimeline values form two related "timelines", one for timezoned values and one for non-timezoned values. Each timeline is a copy of the ·value space· of decimal, with integers given units of seconds.

The ·value space· of dateTime is closely related to the dates and times described in ISO 8601. For clarity, the text above specifies a particular origin point for the timeline. It should be noted, however, that schema processors need not expose the timeOnTimeline value to schema users, and there is no requirement that a timeline-based implementation use the particular origin described here in its internal representation. Other interpretations of the ·value space· which lead to the same results (i.e., are isomorphic) are of course acceptable.

All timezoned times are Coordinated Universal Time (UTC, sometimes called "Greenwich Mean Time"). Other timezones indicated in lexical representations are converted to UTC during conversion of literals to values. "Local" or untimezoned times are presumed to be the time in the timezone of some unspecified locality as prescribed by the appropriate legal authority; currently there are no legally prescribed timezones which are durations whose magnitude is greater than 14 hours. The value of each numeric-valued property (other than timeOnTimeline) is limited to the maximum value within the interval determined by the next-higher property. For example, the day value can never be 32, and cannot even be 29 for month 02 and year 2002 (February 2002).

3.2.8 time

[Definition:]  time represents an instant of time that recurs every day. The ·value space· of time is the space of time of day values as defined in § 5.3 of [ISO 8601]. Specifically, it is a set of zero-duration daily time instances.

Since the lexical representation allows an optional time zone indicator, time values are partially ordered because it may not be able to determine the order of two values one of which has a time zone and the other does not. The order relation on time values is the Order relation on dateTime (§3.2.7.4) using an arbitrary date. See also Adding durations to dateTimes (§E). Pairs of time values with or without time zone indicators are totally ordered.

3.2.9 date

[Definition:]   The ·value space· of date consists of top-open intervals of exactly one day in length on the timelines of dateTime, beginning on the beginning moment of each day (in each timezone), i.e. '00:00:00', up to but not including '24:00:00' (which is identical with '00:00:00' of the next day). For nontimezoned values, the top-open intervals disjointly cover the nontimezoned timeline, one per day. For timezoned values, the intervals begin at every minute and therefore overlap.

A "date object" is an object with year, month, and day properties just like those of dateTime objects, plus an optional timezone-valued timezone property. (As with values of dateTime timezones are a special case of durations.) Just as a dateTime object corresponds to a point on one of the timelines, a date object corresponds to an interval on one of the two timelines as just described.

Timezoned date values track the starting moment of their day, as determined by their timezone; said timezone is generally recoverable for canonical representations. [Definition:]   The recoverable timezone is that duration which is the result of subtracting the first moment (or any moment) of the timezoned date from the first moment (or the corresponding moment) UTC on the same date. ·recoverable timezone·s are always durations between '+12:00' and '-11:59'. This "timezone normalization" (which follows automatically from the definition of the date ·value space·) is explained more in Lexical representation (§3.2.9.1).

For example: the first moment of 2002-10-10+13:00 is 2002-10-10T00:00:00+13, which is 2002-10-09T11:00:00Z, which is also the first moment of 2002-10-09-11:00. Therefore 2002-10-10+13:00 is 2002-10-09-11:00; they are the same interval.

3.2.10 gYearMonth

[Definition:]   gYearMonth represents a specific gregorian month in a specific gregorian year. The ·value space· of gYearMonth is the set of Gregorian calendar months as defined in § 5.2.1 of [ISO 8601]. Specifically, it is a set of one-month long, non-periodic instances e.g. 1999-10 to represent the whole month of 1999-10, independent of how many days this month has.

Since the lexical representation allows an optional time zone indicator, gYearMonth values are partially ordered because it may not be possible to unequivocally determine the order of two values one of which has a time zone and the other does not. If gYearMonth values are considered as periods of time, the order relation on gYearMonth values is the order relation on their starting instants. This is discussed in Order relation on dateTime (§3.2.7.4). See also Adding durations to dateTimes (§E). Pairs of gYearMonth values with or without time zone indicators are totally ordered.

3.2.11 gYear

[Definition:]   gYear represents a gregorian calendar year. The ·value space· of gYear is the set of Gregorian calendar years as defined in § 5.2.1 of [ISO 8601]. Specifically, it is a set of one-year long, non-periodic instances e.g. lexical 1999 to represent the whole year 1999, independent of how many months and days this year has.

Since the lexical representation allows an optional time zone indicator, gYear values are partially ordered because it may not be possible to unequivocally determine the order of two values one of which has a time zone and the other does not. If gYear values are considered as periods of time, the order relation on gYear values is the order relation on their starting instants. This is discussed in Order relation on dateTime (§3.2.7.4). See also Adding durations to dateTimes (§E). Pairs of gYear values with or without time zone indicators are totally ordered.

3.2.12 gMonthDay

[Definition:]   gMonthDay is a gregorian date that recurs, specifically a day of the year such as the third of May. Arbitrary recurring dates are not supported by this datatype. The ·value space· of gMonthDay is the set of calendar dates, as defined in § 3 of [ISO 8601]. Specifically, it is a set of one-day long, annually periodic instances.

Since the lexical representation allows an optional time zone indicator, gMonthDay values are partially ordered because it may not be possible to unequivocally determine the order of two values one of which has a time zone and the other does not. If gMonthDay values are considered as periods of time, in an arbitrary leap year, the order relation on gMonthDay values is the order relation on their starting instants. This is discussed in Order relation on dateTime (§3.2.7.4). See also Adding durations to dateTimes (§E). Pairs of gMonthDay values with or without time zone indicators are totally ordered.

3.2.13 gDay

[Definition:]   gDay is a gregorian day that recurs, specifically a day of the month such as the 5th of the month. Arbitrary recurring days are not supported by this datatype. The ·value space· of gDay is the space of a set of calendar dates as defined in § 3 of [ISO 8601]. Specifically, it is a set of one-day long, monthly periodic instances.

This datatype can be used to represent a specific day of the month. To say, for example, that I get my paycheck on the 15th of each month.

Since the lexical representation allows an optional time zone indicator, gDay values are partially ordered because it may not be possible to unequivocally determine the order of two values one of which has a time zone and the other does not. If gDay values are considered as periods of time, in an arbitrary month that has 31 days, the order relation on gDay values is the order relation on their starting instants. This is discussed in Order relation on dateTime (§3.2.7.4). See also Adding durations to dateTimes (§E). Pairs of gDay values with or without time zone indicators are totally ordered.

3.2.14 gMonth

[Definition:]   gMonth is a gregorian month that recurs every year. The ·value space· of gMonth is the space of a set of calendar months as defined in § 3 of [ISO 8601]. Specifically, it is a set of one-month long, yearly periodic instances.

This datatype can be used to represent a specific month. To say, for example, that Thanksgiving falls in the month of November.

Since the lexical representation allows an optional time zone indicator, gMonth values are partially ordered because it may not be possible to unequivocally determine the order of two values one of which has a time zone and the other does not. If gMonth values are considered as periods of time, the order relation on gMonth is the order relation on their starting instants. This is discussed in Order relation on dateTime (§3.2.7.4). See also Adding durations to dateTimes (§E). Pairs of gMonth values with or without time zone indicators are totally ordered.

3.2.15 hexBinary

[Definition:]   hexBinary represents arbitrary hex-encoded binary data. The ·value space· of hexBinary is the set of finite-length sequences of binary octets.

3.2.16 base64Binary

[Definition:]   base64Binary represents Base64-encoded arbitrary binary data. The ·value space· of base64Binary is the set of finite-length sequences of binary octets. For base64Binary data the entire binary stream is encoded using the Base64 Alphabet in [RFC 2045].

The lexical forms of base64Binary values are limited to the 65 characters of the Base64 Alphabet defined in [RFC 2045], i.e., a-z, A-Z, 0-9, the plus sign (+), the forward slash (/) and the equal sign (=), together with the characters defined in [XML 1.0 (Second Edition)] as white space. No other characters are allowed.

For compatibility with older mail gateways, [RFC 2045] suggests that base64 data should have lines limited to at most 76 characters in length. This line-length limitation is not mandated in the lexical forms of base64Binary data and must not be enforced by XML Schema processors.

The lexical space of base64Binary is given by the following grammar (the notation is that used in [XML 1.0 (Second Edition)]); legal lexical forms must match the Base64Binary production.

Base64Binary  ::=  ((B64S B64S B64S B64S)*
                     ((B64S B64S B64S B64) |
                      (B64S B64S B16S '=') |
                      (B64S B04S '=' #x20? '=')))?

B64S         ::= B64 #x20?

B16S         ::= B16 #x20?

B04S         ::= B04 #x20?

B04         ::=  [AQgw]
B16         ::=  [AEIMQUYcgkosw048]
B64         ::=  [A-Za-z0-9+/]

Note that this grammar requires the number of non-whitespace characters in the lexical form to be a multiple of four, and for equals signs to appear only at the end of the lexical form; strings which do not meet these constraints are not legal lexical forms of base64Binary because they cannot successfully be decoded by base64 decoders.

The canonical lexical form of a base64Binary data value is the base64 encoding of the value which matches the Canonical-base64Binary production in the following grammar:

Canonical-base64Binary  ::=  (B64 B64 B64 B64)*
                               ((B64 B64 B16 '=') | (B64 B04 '=='))?

The length of a base64Binary value is the number of octets it contains. This may be calculated from the lexical form by removing whitespace and padding characters and performing the calculation shown in the pseudo-code below:

lex2    := killwhitespace(lexform)    -- remove whitespace characters
lex3    := strip_equals(lex2)         -- strip padding characters at end
length  := floor (length(lex3) * 3 / 4)         -- calculate length

Note on encoding: [RFC 2045] explicitly references US-ASCII encoding. However, decoding of base64Binary data in an XML entity is to be performed on the Unicode characters obtained after character encoding processing as specified by [XML 1.0 (Second Edition)]

3.2.17 anyURI

[Definition:]   anyURI represents a Uniform Resource Identifier Reference (URI). An anyURI value can be absolute or relative, and may have an optional fragment identifier (i.e., it may be a URI Reference). This type should be used to specify the intention that the value fulfills the role of a URI as defined by [RFC 2396], as amended by [RFC 2732].

The mapping from anyURI values to URIs is as defined by the URI reference escaping procedure defined in Section 5.4 Locator Attribute of [XML Linking Language] (see also Section 8 Character Encoding in URI References of [Character Model]). This means that a wide range of internationalized resource identifiers can be specified when an anyURI is called for, and still be understood as URIs per [RFC 2396], as amended by [RFC 2732], where appropriate to identify resources.

3.2.18 QName

[Definition:]   QName represents XML qualified names. The ·value space· of QName is the set of tuples {namespace name, local part}, where namespace name is an anyURI and local part is an NCName. The ·lexical space· of QName is the set of strings that ·match· the QName production of [Namespaces in XML].

3.2.19 NOTATION

[Definition:]   NOTATION represents the NOTATION attribute type from [XML 1.0 (Second Edition)]. The ·value space· of NOTATION is the set of QNames of notations declared in the current schema. The ·lexical space· of NOTATION is the set of all names of notations declared in the current schema (in the form of QNames).

For compatibility (see Terminology (§1.4)) NOTATION should be used only on attributes and should only be used in schemas with no target namespace.

3.3.1 normalizedString

[Definition:]   normalizedString represents white space normalized strings. The ·value space· of normalizedString is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters. The ·lexical space· of normalizedString is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters. The ·base type· of normalizedString is string.

3.3.2 token

[Definition:]   token represents tokenized strings. The ·value space· of token is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters, that have no leading or trailing spaces (#x20) and that have no internal sequences of two or more spaces. The ·lexical space· of token is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters, that have no leading or trailing spaces (#x20) and that have no internal sequences of two or more spaces. The ·base type· of token is normalizedString.

3.3.3 language

[Definition:]   language represents natural language identifiers as defined by by [RFC 3066] . The ·value space· of language is the set of all strings that are valid language identifiers as defined [RFC 3066] . The ·lexical space· of language is the set of all strings that conform to the pattern [a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})* . The ·base type· of language is token.

3.3.4 NMTOKEN

[Definition:]   NMTOKEN represents the NMTOKEN attribute type from [XML 1.0 (Second Edition)]. The ·value space· of NMTOKEN is the set of tokens that ·match· the Nmtoken production in [XML 1.0 (Second Edition)]. The ·lexical space· of NMTOKEN is the set of strings that ·match· the Nmtoken production in [XML 1.0 (Second Edition)]. The ·base type· of NMTOKEN is token.

For compatibility (see Terminology (§1.4)) NMTOKEN should be used only on attributes.

3.3.5 NMTOKENS

[Definition:]   NMTOKENS represents the NMTOKENS attribute type from [XML 1.0 (Second Edition)]. The ·value space· of NMTOKENS is the set of finite, non-zero-length sequences of ·NMTOKEN·s. The ·lexical space· of NMTOKENS is the set of space-separated lists of tokens, of which each token is in the ·lexical space· of NMTOKEN. The ·itemType· of NMTOKENS is NMTOKEN.

For compatibility (see Terminology (§1.4)) NMTOKENS should be used only on attributes.

3.3.6 Name

[Definition:]   Name represents XML Names. The ·value space· of Name is the set of all strings which ·match· the Name production of [XML 1.0 (Second Edition)]. The ·lexical space· of Name is the set of all strings which ·match· the Name production of [XML 1.0 (Second Edition)]. The ·base type· of Name is token.

3.3.7 NCName

[Definition:]   NCName represents XML "non-colonized" Names. The ·value space· of NCName is the set of all strings which ·match· the NCName production of [Namespaces in XML]. The ·lexical space· of NCName is the set of all strings which ·match· the NCName production of [Namespaces in XML]. The ·base type· of NCName is Name.

3.3.8 ID

[Definition:]   ID represents the ID attribute type from [XML 1.0 (Second Edition)]. The ·value space· of ID is the set of all strings that ·match· the NCName production in [Namespaces in XML]. The ·lexical space· of ID is the set of all strings that ·match· the NCName production in [Namespaces in XML]. The ·base type· of ID is NCName.

For compatibility (see Terminology (§1.4)) ID should be used only on attributes.

3.3.9 IDREF

[Definition:]   IDREF represents the IDREF attribute type from [XML 1.0 (Second Edition)]. The ·value space· of IDREF is the set of all strings that ·match· the NCName production in [Namespaces in XML]. The ·lexical space· of IDREF is the set of strings that ·match· the NCName production in [Namespaces in XML]. The ·base type· of IDREF is NCName.

For compatibility (see Terminology (§1.4)) this datatype should be used only on attributes.

3.3.10 IDREFS

[Definition:]   IDREFS represents the IDREFS attribute type from [XML 1.0 (Second Edition)]. The ·value space· of IDREFS is the set of finite, non-zero-length sequences of IDREFs. The ·lexical space· of IDREFS is the set of space-separated lists of tokens, of which each token is in the ·lexical space· of IDREF. The ·itemType· of IDREFS is IDREF.

For compatibility (see Terminology (§1.4)) IDREFS should be used only on attributes.

3.3.11 ENTITY

[Definition:]   ENTITY represents the ENTITY attribute type from [XML 1.0 (Second Edition)]. The ·value space· of ENTITY is the set of all strings that ·match· the NCName production in [Namespaces in XML] and have been declared as an unparsed entity in a document type definition. The ·lexical space· of ENTITY is the set of all strings that ·match· the NCName production in [Namespaces in XML]. The ·base type· of ENTITY is NCName.

For compatibility (see Terminology (§1.4)) ENTITY should be used only on attributes.

3.3.12 ENTITIES

[Definition:]   ENTITIES represents the ENTITIES attribute type from [XML 1.0 (Second Edition)]. The ·value space· of ENTITIES is the set of finite, non-zero-length sequences of ·ENTITY·s that have been declared as unparsed entities in a document type definition. The ·lexical space· of ENTITIES is the set of space-separated lists of tokens, of which each token is in the ·lexical space· of ENTITY. The ·itemType· of ENTITIES is ENTITY.

For compatibility (see Terminology (§1.4)) ENTITIES should be used only on attributes.

3.3.13 integer

[Definition:]   integer is ·derived· from decimal by fixing the value of ·fractionDigits· to be 0and disallowing the trailing decimal point. This results in the standard mathematical concept of the integer numbers. The ·value space· of integer is the infinite set {...,-2,-1,0,1,2,...}. The ·base type· of integer is decimal.

3.3.14 nonPositiveInteger

[Definition:]   nonPositiveInteger is ·derived· from integer by setting the value of ·maxInclusive· to be 0. This results in the standard mathematical concept of the non-positive integers. The ·value space· of nonPositiveInteger is the infinite set {...,-2,-1,0}. The ·base type· of nonPositiveInteger is integer.

3.3.15 negativeInteger

[Definition:]   negativeInteger is ·derived· from nonPositiveInteger by setting the value of ·maxInclusive· to be -1. This results in the standard mathematical concept of the negative integers. The ·value space· of negativeInteger is the infinite set {...,-2,-1}. The ·base type· of negativeInteger is nonPositiveInteger.

3.3.16 long

[Definition:]   long is ·derived· from integer by setting the value of ·maxInclusive· to be 9223372036854775807 and ·minInclusive· to be -9223372036854775808. The ·base type· of long is integer.

3.3.17 int

[Definition:]   int is ·derived· from long by setting the value of ·maxInclusive· to be 2147483647 and ·minInclusive· to be -2147483648. The ·base type· of int is long.

3.3.18 short

[Definition:]   short is ·derived· from int by setting the value of ·maxInclusive· to be 32767 and ·minInclusive· to be -32768. The ·base type· of short is int.

3.3.19 byte

[Definition:]   byte is ·derived· from short by setting the value of ·maxInclusive· to be 127 and ·minInclusive· to be -128. The ·base type· of byte is short.

3.3.20 nonNegativeInteger

[Definition:]   nonNegativeInteger is ·derived· from integer by setting the value of ·minInclusive· to be 0. This results in the standard mathematical concept of the non-negative integers. The ·value space· of nonNegativeInteger is the infinite set {0,1,2,...}. The ·base type· of nonNegativeInteger is integer.

3.3.21 unsignedLong

[Definition:]   unsignedLong is ·derived· from nonNegativeInteger by setting the value of ·maxInclusive· to be 18446744073709551615. The ·base type· of unsignedLong is nonNegativeInteger.

3.3.22 unsignedInt

[Definition:]   unsignedInt is ·derived· from unsignedLong by setting the value of ·maxInclusive· to be 4294967295. The ·base type· of unsignedInt is unsignedLong.

3.3.23 unsignedShort

[Definition:]   unsignedShort is ·derived· from unsignedInt by setting the value of ·maxInclusive· to be 65535. The ·base type· of unsignedShort is unsignedInt.

3.3.24 unsignedByte

[Definition:]   unsignedByte is ·derived· from unsignedShort by setting the value of ·maxInclusive· to be 255. The ·base type· of unsignedByte is unsignedShort.

3.3.25 positiveInteger

[Definition:]   positiveInteger is ·derived· from nonNegativeInteger by setting the value of ·minInclusive· to be 1. This results in the standard mathematical concept of the positive integer numbers. The ·value space· of positiveInteger is the infinite set {1,2,...}. The ·base type· of positiveInteger is nonNegativeInteger.

4.1.1 The Simple Type Definition Schema Component

The Simple Type Definition schema component has the following properties:

Datatypes are identified by their {name} and {target namespace}. Except for anonymous datatypes (those with no {name}), datatype definitions ·must· be uniquely identified within a schema.

If {variety} is ·atomic· then the ·value space· of the datatype defined will be a subset of the ·value space· of {base type definition} (which is a subset of the ·value space· of {primitive type definition}). If {variety} is ·list· then the ·value space· of the datatype defined will be the set of finite-length sequence of values from the ·value space· of {item type definition}. If {variety} is ·union· then the ·value space· of the datatype defined will be the union of the ·value space·s of each datatype in {member type definitions}.

If {variety} is ·atomic· then the {variety} of {base type definition} must be ·atomic·. If {variety} is ·list· then the {variety} of {item type definition} must be either ·atomic· or ·union·. If {variety} is ·union· then {member type definitions} must be a list of datatype definitions.

The value of {facets} consists of the set of ·facet·s specified directly in the datatype definition unioned with the possibly empty set of {facets} of {base type definition}.

The value of {fundamental facets} consists of the set of ·fundamental facet·s and their values.

If {final} is the empty set then the type can be used in deriving other types; the explicit values restriction, list and union prevent further derivations by ·restriction·, ·list· and ·union· respectively.

4.1.2 XML Representation of Simple Type Definition Schema Components

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

A ·derived· datatype can be ·derived· from a ·primitive· datatype or another ·derived· datatype by one of three means: by restriction, by list or by union.

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

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

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

4.1.3 Constraints on XML Representation of Simple Type Definition

4.1.4 Simple Type Definition Validation Rules

4.1.5 Constraints on Simple Type Definition Schema Components

4.1.6 Simple Type Definition for anySimpleType

There is a simple type definition nearly equivalent to the simple version of the ur-type definition present in every schema by definition. It has the following properties:

4.2.1 equal

Every ·value space· supports the notion of equality, with the following rules:

• for any a and b in the ·value space·, either a is equal to b, denoted a = b, or a is not equal to b, denoted a != b
• there is no pair a and b from the ·value space· such that both a = b and a != b
• for all a in the ·value space·, a = a
• for any a and b in the ·value space·, a = b if and only if b = a
• for any a, b and c in the ·value space·, if a = b and b = c, then a = c
• for any a and b in the ·value space· if a = b, then a and b cannot be distinguished (i.e., equality is identity)
• the ·value space·s of all ·primitive· datatypes are disjoint (they do not share any values)

On every datatype, the operation Equal is defined in terms of the equality property of the ·value space·: for any values a, b drawn from the ·value space·, Equal(a,b) is true if a = b, and false otherwise.

Note that in consequence of the above:

• given ·value space· A and ·value space· B where A and B are disjoint, every pair of values a from A and b from B, a != b
• two values which are members of the ·value space· of the same ·primitive· datatype may always be compared with each other
• if a datatype T is ·derived· by ·union· from ·memberTypes· A, B, ... then the ·value space· of T is the union of ·value space·s of its ·memberTypes· A, B, .... Some values in the ·value space· of T are also values in the ·value space· of A. Other values in the ·value space· of T will be values in the ·value space· of B and so on. Values in the ·value space· of T which are also in the ·value space· of A can be compared with other values in the ·value space· of A according to the above rules. Similarly for values of type T and B and all the other ·memberTypes·.
• if a datatype T' is ·derived· by ·restriction· from an atomic datatype T then the ·value space· of T' is a subset of the ·value space· of T. Values in the ·value space·s of T and T' can be compared according to the above rules
• if datatypes T' and T'' are ·derived· by ·restriction· from a common atomic ancestor T then the ·value space·s of T' and T'' may overlap. Values in the ·value space·s of T' and T'' can be compared according to the above rules

4.2.2 ordered

[Definition:]  An order relation on a ·value space· is a mathematical relation that imposes a ·total order· or a ·partial order· on the members of the ·value space·.

[Definition:]  A ·value space·, and hence a datatype, is said to be ordered if there exists an ·order-relation· defined for that ·value space·.

[Definition:]   A partial order is an ·order-relation· that is irreflexive, asymmetric and transitive.

A ·partial order· has the following properties:

• for no a in the ·value space·, a < a (irreflexivity)
• for all a and b in the ·value space·, a < b implies not(b < a) (asymmetry)
• for all a, b and c in the ·value space·, a < b and b < c implies a < c (transitivity)

The notation a <> b is used to indicate the case when a != b and neither a < b nor b < a. For any values a and b from different ·primitive· ·value space·s, a <> b.

[Definition:]  When a <> b, a and b are incomparable,[Definition:]  otherwise they are comparable.

[Definition:]   A total order is an ·partial order· such that for no a and b is it the case that a <> b.

A ·total order· has all of the properties specified above for ·partial order·, plus the following property:

• for all a and b in the ·value space·, either a < b or b < a or a = b

·ordered· provides for:

• indicating whether an ·order-relation· is defined on a ·value space·, and if so, whether that ·order-relation· is a ·partial order· or a ·total order·

4.2.3 bounded

[Definition:]   A value u in an ·ordered·  ·value space· U is said to be an inclusive upper bound of a ·value space· V (where V is a subset of U) if for all v in V, u >= v.

[Definition:]   A value u in an ·ordered·  ·value space· U is said to be an exclusive upper bound of a ·value space· V (where V is a subset of U) if for all v in V, u > v.

[Definition:]   A value l in an ·ordered·  ·value space· L is said to be an inclusive lower bound of a ·value space· V (where V is a subset of L) if for all v in V, l <= v.

[Definition:]   A value l in an ·ordered·  ·value space· L is said to be an exclusive lower bound of a ·value space· V (where V is a subset of L) if for all v in V, l < v.

[Definition:]  A datatype is bounded if its ·value space· has either an ·inclusive upper bound· or an ·exclusive upper bound· and either an ·inclusive lower bound· or an ·exclusive lower bound·.

·bounded· provides for:

• indicating whether a ·value space· is ·bounded·

4.2.4 cardinality

[Definition:]  Every ·value space· has associated with it the concept of cardinality. Some ·value space·s are finite, some are countably infinite while still others could conceivably be uncountably infinite (although no ·value space· defined by this specification is uncountable infinite). A datatype is said to have the cardinality of its ·value space·.

It is sometimes useful to categorize ·value space·s (and hence, datatypes) as to their cardinality. There are two significant cases:

• ·value space·s that are finite
• ·value space·s that are countably infinite

·cardinality· provides for:

• indicating whether the ·cardinality· of a ·value space· is finite or countably infinite

4.2.5 numeric

[Definition:]  A datatype is said to be numeric if its values are conceptually quantities (in some mathematical number system).

[Definition:]  A datatype whose values are not ·numeric· is said to be non-numeric.

·numeric· provides for:

• indicating whether a ·value space· is ·numeric·

4.3.1 length

[Definition:]   length is the number of units of length, where units of length varies depending on the type that is being ·derived· from. The value of length ·must· be a nonNegativeInteger.

For string and datatypes ·derived· from string, length is measured in units of characters as defined in [XML 1.0 (Second Edition)]. For anyURI, length is measured in units of characters (as for string). For hexBinary and base64Binary and datatypes ·derived· from them, length is measured in octets (8 bits) of binary data. For datatypes ·derived· by ·list·, length is measured in number of list items.

·length· provides for:

• Constraining a ·value space· to values with a specific number of units of length, where units of length varies depending on {base type definition}.

<simpleType name='productCode'>
   <restriction base='string'>
     <length value='8' fixed='true'/>
   </restriction>
</simpleType>

4.3.2 minLength

[Definition:]   minLength is the minimum number of units of length, where units of length varies depending on the type that is being ·derived· from. The value of minLength  ·must· be a nonNegativeInteger.

For string and datatypes ·derived· from string, minLength is measured in units of characters as defined in [XML 1.0 (Second Edition)]. For hexBinary and base64Binary and datatypes ·derived· from them, minLength is measured in octets (8 bits) of binary data. For datatypes ·derived· by ·list·, minLength is measured in number of list items.

·minLength· provides for:

• Constraining a ·value space· to values with at least a specific number of units of length, where units of length varies depending on {base type definition}.

<simpleType name='non-empty-string'>
  <restriction base='string'>
    <minLength value='1'/>
  </restriction>
</simpleType>

4.3.3 maxLength

[Definition:]   maxLength is the maximum number of units of length, where units of length varies depending on the type that is being ·derived· from. The value of maxLength  ·must· be a nonNegativeInteger.

For string and datatypes ·derived· from string, maxLength is measured in units of characters as defined in [XML 1.0 (Second Edition)]. For hexBinary and base64Binary and datatypes ·derived· from them, maxLength is measured in octets (8 bits) of binary data. For datatypes ·derived· by ·list·, maxLength is measured in number of list items.

·maxLength· provides for:

• Constraining a ·value space· to values with at most a specific number of units of length, where units of length varies depending on {base type definition}.

<simpleType name='form-input'>
  <restriction base='string'>
    <maxLength value='50'/>
  </restriction>
</simpleType>

4.3.4 pattern

[Definition:]   pattern is a constraint on the ·value space· of a datatype which is achieved by constraining the ·lexical space· to literals which match a specific pattern. The value of pattern  ·must· be a ·regular expression·.