This appendix lists features of the XQuery Data Model and type system, sorted alphabetically and cross-referenced for convenience. See Chapter 2 for an introduction to these topics. This appendix also summarizes the sequence type syntax used by XQuery expressions such as function definitions, typeswitch, and cast as. Most of these operators are described in Chapter 9. Section A.5 covers all of the built-in atomic types, including value ranges and lexical forms.

The XQuery Data Model consists of sequences of items (including the empty sequence). Items are nodes or atomic values. XQuery defines 7 node kinds and 50 atomic types.

XQuery provides two different ways to refer to types: single type and sequence type. The single type syntax is used only in cast as and castable as expressions. The sequence type syntax is used in all other expressions: typeswitch, instance of, treat as, function definitions, and variable types.

A sequence type consists of either the empty() type test (which matches only the empty sequence) or else a single type together with an optional occurrence indicator. A single type is a subset of sequence type, consisting of a type test with either no occurrence indicator or else the question mark (?). The occurrence modifiers are listed in Table A.1.

The item type can be an atomic type name (any QName), or a node kind type test. It can also be the special type test item(), which matches any item, or the type test node(), which matches any node.

XQuery defines one type test for each node kind: attribute(), comment(), document-node(), element(), processing-instruction(), and text(). Without arguments, these node kind tests match any node of the corresponding kind. Additionally, the attribute(), element(), and processing-instruction() node kind tests accept optional arguments. Table A.2 lists all of these. See Chapter 9 for additional examples.

XQuery supports all seven XML node kinds and uses the XML syntax to construct them; for some node kinds, XQuery also provides an alternate syntax. Table A.3 summarizes both constructor styles. See Chapter 7 for additional examples and construction rules.

comment { content-expr }
<!-- content -->

document { content-expr }

element name { content-expr }
element { name-expr } { content-expr }
<name attributes />
<name attributes>content</name>

processing-instruction { target-expr }
{ content-expr } <?target content?>

text { content-expr }

Every node belongs to a tree (possibly containing only that node). If the root node of the tree is an element, then the tree is a fragment; otherwise, the root node is a document node, and the tree is a document. Every node has a unique node identity, and all nodes are ordered relative to one another (document order). Nodes in the same tree are ordered in left-depth-first order; nodes from different trees may have any order, but the order doesn't change within the execution of a query.

Table A.4 lists the built-in node properties. For some node kinds, the property value is always the empty list. For some properties, the value is always a constant (such as node kind). Otherwise, the sequence type of the property is listed.

attribute::*
@*

child::node()
node()

instance of element(*, nilled)
self::*[@xsi:nil="true"]

fn:node-name
()fn:name()

The XQuery Data Model is an abstraction and not all of its properties are directly accessible in XQuery. For example, node identity and node order aren't directly accessible as values. Expressions that access values in the data model are summarized in Table A.5. See Chapter 2 for more information.

Figure A.1 shows the entire XQuery atomic type hierarchy, and Table A.6 lists the meaning of every type. Arrows indicate inheritance (also known as derivation). Type names in bold are the “types you need to know” from Chapter 2. Grey boxes indicate built-in types that cannot be constructed (because they derive by list). All other types derive by restriction, and can be cast to and constructed.

Figure A.1. The XQuery atomic type hierarchy

m*2E
-224 < m < 224
-149 <= E <= 104

m*2E
-253 < m < 253
-1075 <= E <= 970

-128 to 127
(-27 to 27-1)

-32768 to 32767
(-215 to 215-1)

-2147483648 to 2147483647
(-231 to 231-1)

-9223372036854775808 to
9223372036854775807
(-263 to 263-1)

0 to 255
(0 to 28-1)

0 to 65535
(0 to 216-1)

0 to 4294967295
(0 to 232-1)

0 to 18446744073709551615
(0 to 264-1)

The prefix xs is bound to the namespace http://www.w3.org/2001/XMLSchema and the prefix xdt is bound to the namespace http://www.w3.org/2003/11/xpath-datatypes.

This section summarizes all of the XQuery type conversions used by the cast as expression when converting to atomic types. Each table shows the conversions used from the row type (source type) to the column type (target type). The letters used in Tables A.7, A.9, and A.11 correspond to the rules listed in Tables A.8, A. 10, and A.12, respectively. A blank entry means the value is unchanged by the conversion (only its type changes).

All other type conversions not mentioned below or shown in Tables A.9 – A.12 result in errors. Some implementations detect these as compile-time (static) errors, and others as run-time (dynamic) errors.

Converting to the three types xs:anySimpleType or xdt:untypedAtomic is the same as converting to xs:string, except that list types cannot be converted to xdt:untypedAtomic.

Except for xs:NOTATION, every type can be converted to one of these three types without error, by taking its canonical representation. These three types can also be converted to any other type except xs:NOTATION (possibly resulting in an error), by attempting to parse according to other type's lexical format. See the individual entries for each type in Section A.5 for canonical and lexical representations.

The two binary types, xs:base64Binary and xs:hexBinary, can be converted to xs:boolean; see their descriptions in Section A.5 for details.

Of course, every type can be converted to itself or any of its supertypes without changing value. Types can also be converted to derived types, provided that they satisfy the additional restrictions of the derived type (otherwise an error is raised).

In this section there is a one-line description of each concrete type followed by its type constructor, its lexical format, and its canonical form (when it differs from the lexical one). The lexical form is a regular expression describing the formats that are accepted when converting from string to this type. The canonical form describes the format used when converting to string. Except for the xs:NOTATION type, every type has a lexical and canonical form. These forms are described using the XQuery regular expression syntax (see Appendix D).

The three types xdt:anyAtomicType, xs:anySimpleType, and xs:anyType are abstract and so are not listed here. No atomic value has exactly one of these types, although every atomic type is derived from one of them. See Chapter 2 for details.

xs:anyURI(xdt:anyAtomicType) as xs:anyURI

[a-zA-Z][a-zA-Z0-9+-.]*:([[#x20-#xFF]-[#x7F<>"'|^{}\])*

The xs:anyURI type represents a Uniform Resource Identifier (URI) Reference, as defined by RFC 2396 and RFC 2732 (see the Bibliography for complete references). In XQuery, the xs:anyURI type is used to name collations, collections, and documents.

xs:anyURI('http://www.awprofessional.com/')
xs:anyURI('ftp://ftp.w3.org/')
xs:anyURI('urn:relative/path')

An xs:anyURI value can be constructed from any string value that contains only ASCII characters, except for the following excluded characters: the special punctuation characters <>"{}|^` and control characters (U+0000 through U+001F and U+007F). Whitespace (U+0020) is allowed but recommended to be escaped as %20. In addition, the punctuation characters ;/?:@&=+$, are reserved, so it is recommended to escape them also.

The sequence %HH where H is a hexadecimal digit is used to encode the character U+00HH. Disallowed characters (including non-ASCII characters) must be first converted to UTF-8, then hex-encoded as necessary to be represented as xs:anyURI values.

Note that xs:anyURI is a distinct type from xs:string, and isn't a subtype of it. A cast or constructor function must be used to convert one to the other.

Unfortunately, URI values are notoriously difficult to work with; for example, on some systems file system paths are case-sensitive while on others they are not. In general, it isn't possible to determine whether two URI values point to the same resource or not. Consequently, implementations are given some latitude in how they handle URI values. For example, some implementations may disallow xs:anyURI("foo") but allow xs:anyURI("urn:foo"), while others may allow both.

For more information, see RFC 2396 and RFC 2732 (complete references are provided in the Bibliography).

See also: fn:base-uri(), fn:collection(), fn:default-collation(), fn:doc(), fn:escape-uri(), and fn:resolve-uri()in Appendix C.

xs:base64Binary(xdt:anyAtomicType) as xs:base64Binary

S?([A-Za-z0-9+/]S?){4}*
([A-Za-z0-9+/]S?[AQgw]S?=S?=S?|
([A-Za-z0-9+/]S?){2}[AEIMQUYcgkosw048]S?=S?))?

([A-Za-z0-9+/]{76}#xA)*([A-Za-z0-9+/]{4}){0,18}
(([A-Za-z0-9+/]{4})|
([A-Za-z0-9+/]{2}[AEIMQUYcgkosw048]=)|
([A-Za-z0-9+/] [AQgw]==))?

The xs:base64Binary type represents base64-encoded binary data, as defined by RFC 2045. It consists of a sequence of ASCII characters A-Z, a-z, 0-9, the punctuation characters +/ and possibly one or two trailing = characters for padding; all other characters are ignored. Base64-encoding is a popular format for embedding arbitrary binary data in XML (among other things).

Each character represents 6 bits of data (most significant bit first); four consecutive characters thus encode 3 bytes of binary data. When the original input data has a length not divisible by three, trailing = symbols are used to pad the base64 encoding of the data. Trailing bits are zero-padded as necessary.

xs:base64Binary("ABBA")     (: encodes the three bytes 0, 16, 64 :)
xs:base64Binary("+XQuerY=") (: encodes 249, 116, 46, 122, 182 :)

XQuery doesn't provide any functions for working with base64- or hex-encoded binary data, but Chapter 10 includes a few user-defined functions that do so.

See also: xs:hexBinary and Chapter 10.

xs:boolean(xdt:anyAtomicType) as xs:boolean

(true)|(false)|1|0

(true)|(false)

The xs:boolean type represents a single boolean value (true or false).

In addition to the numeric and string type conversions summarized in Table A.7, values of type xs:hexBinary and xs:base64Binary can also be converted to xs:boolean. They convert to true if their string value is "1", false if their string value is "0", and otherwise result in an error.

xs:boolean("true")    => true
xs:boolean("1")       => true
xs:boolean(0)         => false
xs:boolean(0.0)       => error
xs:boolean(42)        => error
xs:boolean("ja")      => error
xs:boolean("")        => error

Casting to xs:boolean or using the xs:boolean() constructor differs from using the fn:boolean() function. Casting to xs:boolean converts "0" and "false" to false, "1" and "true" to true, and all other string values result in an error. In contrast, the built-in boolean() function returns true for all non-empty strings and false for the empty string. (The boolean() function can also be applied to non-singleton and non-atomic values, such as the empty sequence or nodes, while xs:boolean() cannot.)

See also: fn:boolean() in Appendix C.

xs:byte(xdt:anyAtomicType) as xs:byte

[+-]?[0-9]+

-?[1-9][0-9]*

The xs:byte type represents a signed, single-byte integer, which can range in value from -128 to 127. It is a derived type.

Because all XQuery arithmetic using xs:byte values takes place using its supertype, xs:integer, this type is useful only for validation and for constraining function parameters. Some implementations may also optimize values with this type to occupy less space, or may optimize the performance of certain query expressions to exploit the properties of this type.

xs:byte("0")     => 0
xs:byte("127")   => 127
xs:byte("128")   => error (: out of range :)
xs:byte("-1")    => -1
xs:byte("2.5")   => error (: invalid format :)
xs:byte(2.5)     => 2

See also: xs:int, xs:integer, xs:long, xs:short, and xs:unsignedByte.

xs:date(xdt:anyAtomicType) as xs:date

-?[1-9]*[0-9]{4}-[0-9]{2}-[0-9]{2}(Z|([+-][0-9]{2}:[0-9]{2}))?

[1-9]*[0-9]{4}-[0-9]{2}-[0-9]{2}Z?

The xs:date type represents a single point on the calendar. It consists of the same year, month, day, and time zone parts as the xs:dateTime type (but it isn't derived from xs:dateTime).

xs:date("2004-08-24")       (: September 8, 2004 :)
xs:date("0001-01-01")       (: January 1, year 1 :)
xs:date("-0001-01-01")      (: January 1, year -1 :)
xs:date("2004-08-24Z")      (: September 8, 2004 in UTC :)
xs:date("2004-08-24-08:00") (: same date in PST :)

See also: xs:dateTime.

xs:dateTime(xdt:anyAtomicType) as xs:dateTime

-?[1-9]*[0-9]{4}-[0-9]{2}-[0-9]{2}
T[0-9]{2}:[0-9]{2}:[0-9]{2}(.[0-9]*)?(Z|([+-][0-9]{2}:[0-9]{2}))?

-?[1-9]*[0-9]{4}-[0-9]{2}-[0-9]{2}
T[0-9]{2}:[0-9]{2}:[0-9]{2}(.[0-9]*)?Z?

The xs:dateTime type represents a single point in time, and consists of seven parts: year, month, day, hour, minute, second, and time zone. The first five of these are integer values; the second part is a decimal value, and the time zone is either the empty sequence or else an hour and minute value (both integers). All of these must satisfy certain constraints, described next.

Often the first half (year, month, and day) is called the date part; the second half (hour, minute, and second) is called the time part. This is further encouraged by the T character that separates the two halves.

The year part always contains at least four digits (padded with leading zeros if necessary), but doesn't contain leading zeros beyond the fourth digit. It can be any integer value other than 0000, including negative integers. Most implementations support only a limited range of year values, but conformant implementations are required to support at least four digits.

The month part always contains exactly two digits, and must be an integer between 01 and 12.

The day part always contains exactly two digits, and must be an integer valid for the given month and year. For month 2, it must be between 01 and 28 except in leap years when it may also be 29. For months 4, 6, 9, and 11, it must be between 01 and 30 inclusive. And in all remaining months, it must be between 01 and 31 inclusive.

The hour part must be a two-digit integer between 00 and 23 inclusive. The minute part must be a two-digit integer between 00 and 59, inclusive. The second part is a decimal value with exactly two digits before the decimal point. The decimal point and fractional digits are optional. Most implementations support only a limited number of digits after the decimal point (nanosecond precision is common). This decimal value is allowed to be greater than or equal to 60 only for leap seconds.

The time zone part is optional; when not specified, it is the empty sequence. It can also be specified using Z (meaning UTC) or a positive or negative number of hours and minutes subject to the same constraints as above (meaning that offset from UTC).

xs:dateTime("2004-09-08T00:00:00")       (: September 8, 2004 :)
xs:dateTime("2004-01-04T03:05:06")       (: Jan 4, 2004, 3:05:06 am :)
xs:dateTime("2004-09-08T00:00:00Z")      (: September 8, 2004 in UTC :)
xs:dateTime("2004-09-08T00:00:00-08:00") (: same date in PST :)

See also: xs:date and xs:dateTime, and fn:get-year-from-dateTime(), fn:implicit-timezone(), and related functions in Appendix C.

xdt:dayTimeDuration(xdt:anyAtomicType) as xdt:dayTimeDuration

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

This type has been introduced by XQuery to allow durations to be compared. As its name suggests, it represents the day and time parts only from a duration. Its lexical and canonical forms are the same as those for xs:duration, including only the day and time parts.

See also: xs:duration and xdt:yearMonthDuration, and fn:get-days-from-dayTimeDuration(), fn:get-hours-from-dayTimeDuration(), fn:get-minutes-from-dayTimeDuration(), fn:get-seconds-from-dayTimeDuration(), and fn:subtract-dateTimes-yielding-dayTimeDuration()in Appendix C.

xs:decimal(xdt:anyAtomicType) as xs:decimal

[+-]?(([0-9]+(.[0-9]*)?)|(.[0-9]+))

-?[0-9]+.[0-9]+

The xs:decimal represents an arbitrary-precision fixed-point decimal number; in other words, all numbers of the form m*10^-n where m is any xs:integer value and n is any non-negative integer. This type is commonly used in financial and scientific applications, where a fixed number of decimal digits are required, or when rounding is unacceptable.

In practice, most implementations limit the precision of this type by representing it using 64 or 128 bits (often a pair of integers, one for the value and one for the exponent).

In XQuery, decimal is the default type for all number literals that contain a decimal point. To use a floating-point number, use E notation after the number.

The decimal point and fractional digits are optional when casting from string (lexical format). When writing as a literal, the decimal point is required (although either the digits before or after the decimal point may be omitted). When casting to string (canonical format), the decimal point is required and digits must appear on either side of it.

1.0             => 1.0   (: decimal :)
1               => 1     (: integer :)
xs:decimal("1") => 1.0   (: decimal :)
1.0E0           => 1.0E0 (: double :)
1.0 div 0.0     => error (: division by zero :)

See also: xs:double, xs:float, and xs:integer.

xs:double(xdt:anyAtomicType) as xs:double

[+-]?(([0-9]+(.[0-9]*)?)|(.[0-9]+))((E|e)[+-]?[0-9]+)?
|[+-]?[iI][nN][fF]|[nN][aA][nN]

-?[0-9]+.[0-9]+E-?[0-9]+|INF|-INF|NaN

The xs:double type represents a double-precision (8-byte) floating-point value. Doubles are used to approximate real numbers, including the special values positive and negative infinity, positive and negative zero, and NaN (not a number). Except for these special values, every double value is a number m*2E, where m is the mantissa, an integer between -2⁵³ and 2⁵³ exclusive, and E is the exponent, an integer between -1075 and 970, inclusive. The range of xs:double is thus considerably larger than that of xs:float.

The lexical format for xs:double is the same as that for xs:float: It consists of a decimal optionally followed by an exponent sign (E or e) and an integer. In other words, the double format consists of an optional sign (+ or -), any number of digits (possibly containing a decimal point), and an optional exponent consisting of an exponent sign (E or e), an optional sign (+ or -), and one or more digits. It is parsed into the closest possible double representation, using what is known as Clinger's algorithm.

If the string isn't in this format, then it is uppercased and if equal to +INF or INF results in positive infinity; -INF results in negative infinity, and NaN results in not-a-number. All other strings result in an error when converted to xs:double.

The canonical format for xs:double omits the + sign, always uses E for the exponent, always contains a decimal point with at least one digit before and at least one digit after the decimal point, and (except for these digits) omits leading and trailing zeros. Double values are converted to string using exactly as many but no more digits required to round-trip the value. The special values positive infinity, negative infinity, and not-a-number are converted to the strings "INF", "-INF", and "NaN", respectively. Implementations may omit the minus sign when converting negative zero to string.

Values of type xs:double can be written using the type constructor syntax, or using a double literal, which is a number followed by an exponent. (Numbers without exponents are xs:decimal values.)

xs:double("1")      => 1.0E0
xs:double("1.0")    => 1.0E0
xs:double("010.00") => 1.0E1
xs:double("1E1")    => 1.0E1
xs:double("0.1")    => 1.0E-1
xs:double("INF")    => INF
xs:double("+iNf")   => INF
xs:double("NAN")    => NaN
1.0E0               => 1.0E0
1E-1                => 1.0E-1
1E0 div 0E0         => INF
0E0 div 0E0         => NaN

See also: xs:decimal, xs:float, and xs:integer.

xs:duration(xdt:anyAtomicType) as xs:duration

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

The xs:duration type represents an interval of dates and/or times. Every xs:duration value has six parts: year, month, day, hour, minute, and second. As with the xs:dateTime type, the first five of these are integers, and the second part is a decimal value. The entire duration can be negative.

Each duration is constructed from a string that contains any or all of these parts, in the order given. When a part is omitted, it has the value 0. When a time part (hour, minute, or second) is included, then the T is required; when no time part is present, then the T must not appear.

xs:duration("P")          (: 0 length duration :)
xs:duration("P1Y")        (: 1 year :)
xs:duration("P1M")        (: 1 month :)
xs:duration("P1D")        (: 1 day :)
xs:duration("PT1H")       (: 1 hour :)
xs:duration("PT1M")       (: 1 minute :)
xs:duration("PT1S")       (: 1 second :)
xs:duration("P2Y3MT5.6S") (: 2 years, 3 months, 5.6 seconds :)
xs:duration("-P2MT3M")    (: negative 2 months, 3 minutes :)

See also: xs:dateTime, xdt:dayTimeDuration, and xdt:yearMonthDuration.

The xs:ENTITIES type doesn't have a constructor because it derives by list from xs:ENTITY. In XQuery, a list of xs:ENTITY values has type xs:ENTITY*. Consequently, this type is useful only for validation.

See also: xs:ENTITY.

xs:ENTITY(xdt:anyAtomicType) as xs:ENTITY

ic*

The xs:ENTITY type is used to represent a reference to an XML unparsed entity, in association with the xs:NOTATION type. In XQuery, this type behaves the same way as xs:NCName. It is unlikely you will ever need the xs:ENTITY type.

See also: xs:ENTITIES and xs:NCName.

xs:float(xdt:anyAtomicType) as xs:string?

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

-?[0-9]+.[0-9]+E-?[0-9]+

The xs:float type represents a single-precision (4-byte) floating-point value. Floats are used to approximate real numbers, including the special values positive and negative infinity, positive and negative zero, and NaN (not a number). Except for these special values, every float value is a number m*2E, where m is the mantissa, an integer between -2²⁴ and 2²⁴ exclusive, and E is the exponent, an integer between -149 and 104, inclusive.

The lexical format for xs:float is the same as that for xs:double: It consists of a decimal optionally followed by an exponent sign (E or e) and an integer. In other words, the float format consists of an optional sign (+ or -), any number of digits (possibly containing a decimal point), and an optional exponent consisting of an exponent sign (E or e), an optional sign (+ or -), and one or more digits. It is parsed into the closest possible float representation, using what is known as Clinger's algorithm.

If the string isn't in this format, then it is uppercased and if equal to +INF or INF results in positive infinity; -INF results in negative infinity, and NaN results in not-a-number. All other strings result in an error when converted to xs:float.

The canonical format for float omits the + sign, always uses E for the exponent, always contains a decimal point with at least one digit before and at least one digit after the decimal point, and (except for these digits) omits leading and trailing zeros. Float values are converted to string using exactly as many but no more digits required to round-trip the value. The special values positive infinity, negative infinity, and not-a-number are converted to the strings "INF", "-INF", and "NaN", respectively. Implementations may omit the minus sign when converting negative zero to string.

Although xs:float is a common type, it doesn't have a literal expression in XQuery. In other words, xs:float values must always be constructed using the type constructor syntax or a cast.

xs:float("1")      => 1.0E0
xs:float("1.0")    => 1.0E0
xs:float("010.00") => 1.0E1
xs:float("1E1")    => 1.0E1
xs:float("0.1")    => 1.0E-1
xs:float("INF")    => INF
xs:float("+iNf")   => INF
xs:float("NAN")    => NaN
1E0 div 0E0         => INF
0E0 div 0E0         => NaN

See also: xs:decimal, xs:double, and xs:integer.

xs:gDay(xdt:anyAtomicType) as xs:gDay

--[0-9]{2}(Z|([+-][0-9]{2}:[0-9]{2}))?

The xs:gDay type represents a recurring day in the Gregorian calendar. It is written using two leading hyphens followed by two digits, and an optional time zone.

Unlike the date/time types (xs:date, xs:time, and xs:dateTime), the Gregorian types are relative. For example, xs:gDay("--30") means the thirtieth day of each month.

See also: xs:gMonth, xs:gMonthDay, xs:gYear, and xs:gYearMonth.

xs:gMonth(xdt:anyAtomicType) as xs:gMonth

-[0-9]{2}-(Z|([+-][0-9]{2}:[0-9]{2}))?

The xs:gMonth type represents a recurring month in the Gregorian calendar. It is written using a hyphen followed by two digits and another hyphen, and an optional time zone.

Unlike the date/time types (xs:date, xs:time, and xs:dateTime), the Gregorian types are relative. For example, xs:gMonth("-02-") means the second month of each year.

See also: xs:gDay, xs:gMonthDay, xs:gYear, and xs:gYearMonth.

xs:gMonthDay(xdt:anyAtomicType) as xs:gMonthDay

-[0-9]{2}-[0-9]{2}(Z|([+-][0-9]{2}:[0-9]{2}))?

The xs:gMonthDay type represents a recurring day of a month in the Gregorian calendar. It is written using a hyphen followed by two digits (the month, another hyphen and another two digits (the day), and an optional time zone.

Unlike the date/time types (xs:date, xs:time, and xs:dateTime), the Gregorian types are relative. For example, xs:gMonthDay("-02-14") means the fourteenth day of the second month of each year.

See also: xs:gDay, xs:gMonth, xs:gYear, and xs:gYearMonth.

xs:gYear(xdt:anyAtomicType) as xs:gYear

[0-9]{4}--(Z|([+-][0-9]{2}:[0-9]{2}))?

The xs:gYear type represents a single year in the Gregorian calendar. It is written using four digits followed by two hyphens and an optional time zone.

Unlike the date/time types (xs:date, xs:time, and xs:dateTime), the Gregorian types are relative. For example, xs:gYear("2004--") means the entire year 2004.

See also: xs:gDay, xs:gMonth, xs:gMonthDay, and xs:gYearMonth.

xs:gYearMonth(xdt:anyAtomicType) as xs:gYearMonth

[0-9]{4}-[0-9]{2}-(Z|([+-][0-9]{2}:[0-9]{2}))?

The xs:gYearMonth type represents the entire month of a particular year in the Gregorian calendar. It is written using four digits (the year) followed by a hyphen, followed by two digits (the month), another hyphen, and an optional time zone.

Unlike the date/time types (xs:date, xs:time, and xs:dateTime), the Gregorian types are relative. For example, xs:gYearMonth("2004-05") means the fifth month of the year 2004.

See also: xs:gDay, xs:gMonth, xs:gMonthDay, and xs:gYear.

xs:hexBinary(xdt:anyAtomicType) as xs:hexBinary

[A-Fa-f0-9]{2}+

[A-F0-9]{2}+

The xs:hexBinary type represents hex-encoded binary data. It consists of a sequence of pairs of hexadecimal digits A-F, a-f, 0-9; all other characters are errors. Hex-encoding is a popular format for embedding arbitrary binary data in XML (among other things). Each pair of hexadecimal characters encodes a single byte of data (the byte with that hexadecimal value).

xs:hexBinary("ABBA")     (: encodes the two bytes 171, 186 :)
xs:hexBinary("012345")   (: encodes the bytes 1, 35, 69 :)

XQuery doesn't provide any functions for working with base64- or hex-encoded binary data; however, Chapter 10 includes a few examples of user-defined functions that do so.

See also: xs:base64Binary and Chapter 10.

xs:ID(xdt:anyAtomicType) as xs:ID

ic*

The xs:ID type represents an XML ID value (an attribute or element value that uniquely identifies an element). This derived type satisfies the same lexical constraints as the xs:NCName type.

See also: xs:NCName, and fn:id() in Appendix C.

xs:IDREF(xdt:anyAtomicType) as xs:IDREF

ic*

The xs:IDREF type represents a reference to an xs:ID value.

See also: xs:ID and fn:idref() in Appendix C.

The xs:IDREFS type doesn't have a constructor because it derives by list from xs:IDREF. In XQuery, a list of xs:IDREF values has type xs:IDREF*. Consequently, this type is useful only for validation.

See also: xs:IDREF.

xs:int(xdt:anyAtomicType) as xs:int

[+-]?[0-9]+

-?[1-9][0-9]*

The xs:int type represents a signed, 4-byte integer, which can range in value from -2147483648 to 2147483647. It is a derived type.

Because all XQuery arithmetic using xs:int values takes place using its supertype, xs:integer, this type is primarily useful only for validation purposes and for placing constraints on function parameters. Some implementations may also optimize values with this type to occupy less space, or may optimize the performance of certain query expressions to exploit the properties of this type.

xs:int("0")           => 0
xs:int("2147483647")  => 2147483647
xs:int("2147483648")  => error (: out of range :)
xs:int("-1")          => -1
xs:int("2.5")         => error (: invalid format :)
xs:int(2.5)           => 2

See also: xs:byte, xs:integer, xs:long, xs:short, and xs:unsignedInt.

xs:integer(xdt:anyAtomicType) as xs:integer

[+-]?[0-9]+

-?[1-9][0-9]*

The xs:integer type represents a signed, arbitrary-precision integer. However, some implementations may choose to implement this type using a limited-precision type, such as 4- or 8-bytes. In that case, it behaves more like xs:int or xs:long, respectively.

Because the xs:integer type is so important in XQuery, its type constructor can be omitted. Any sequence of digits without a decimal point represents an xs:integer literal with that value.

This type is derived from xs:decimal, although in many cases it behaves more like a primitive type. For example, the type conversion rules for xs:integer are slightly different from those for other types derived from xs:decimal.

When converting from string, all signed integers allow an optional sign (+ or -) followed by one or more decimal digits. When converting to string, the + sign is always omitted, as are any leading zeros. Other numeric types can be converted to xs:integer, as described in Table A.7; values with digits after the decimal point have their fraction digits removed (truncation).

xs:integer("0")   => 0
xs:integer("-1")  => -1
0                 => 0
-1                => -1

(: on some implementations, this will error or overflow :)
xs:integer("18446744073709551617") => 18446744073709551617

See also: xs:byte, xs:decimal, xs:int, xs:long, xs:nonNegativeInteger, xs:nonPositiveInteger, and xs:short.

xs:language(xdt:anyAtomicType) as xs:language

[a-ZA-Z]{2}[-_][a-zA-Z]{2}

The xs:language type represents a value of the xml:lang attribute of XML. It specifies a language identifier as defined by RFC 1766, using two-letter country and language codes such as en-US (for U.S. English) and en_GB (Great Britain English). The separator may be either a hyphen or an underscore (RFC 1766 allows both), although some implementations may support only one or the other.

This derived type generally behaves like its supertype xs:string. Its only real use is to validate that a string is a valid language identifier.

xs:language("en-US")

See also: xs:string and fn:lang() in Appendix C.

xs:long(xdt:anyAtomicType) as xs:long

[+-]?[0-9]+

-?[1-9][0-9]*

The xs:long type represents a signed, 8-byte integer, which can range in value from -9223372036854775808 to 9223372036854775807. It is a derived type.

Because all XQuery arithmetic using xs:long values takes place using its supertype, xs:integer, this type is primarily useful only for validation purposes and for placing constraints on function parameters. Some implementations may also optimize values with this type to occupy less space, or may optimize the performance of certain query expressions to exploit the properties of this type.

xs:long("0")                    => 0
xs:long("9223372036854775807")  => 9223372036854775808
xs:long("9223372036854775808")  => error (: out of range :)
xs:long("-1")                   => -1
xs:long("2.5")                  => error (: invalid format :)
xs:long(2.5)                    => 2

Implementations that represent xs:integer using a signed, 4-byte integer instead of using arbitrary-precision arithmetic have problems with this type, because it's a subtype of xs:integer but covers a larger range than xs:integer can represent.

See also: xs:byte, xs:int, xs:integer, xs:short, and xs:unsignedLong.

xs:Name(xdt:anyAtomicType) as xs:Name

(ic*:)ic*

The xs:Name type represents a valid XML name (including possibly the colon character). It consists of an optional prefix and colon separator, and a required local-name part. (Contrast this with the xs:QName type, which consists of the namespace and local-name parts, or the xs:NCName type, which represents unprefixed names).

See also: xs:NCName and xs:QName.

xs:NCName(xdt:anyAtomicType) as xs:NCName

ic*

The xs:NCName type is derived from and similar to xs:Name, except that it cannot contain any colons (NCName stands for “Non-Colonized Name”). An XML prefix is an xs:NCName, and an XML local-name is an xs:NCName.

Values of this type must start with a letter, underscore (_), and then contain any number of subsequent letters, digits, hyphens (-), periods (.), underscores (_), and certain special Unicode characters (combining characters and extenders).

See also: xs:Name and xs:QName.

xs:negativeInteger(xdt:anyAtomicType) as xs:negativeInteger

-[0-9]+

-[1-9][0-9]*

The xs:negativeInteger type represents an arbitrary-precision integer with a negative value. It is a derived type.

Because all XQuery arithmetic using xs:negativeInteger values takes place using its supertype, xs:integer, this type is primarily useful only for validation purposes and for placing constraints on function parameters. Some implementations may also optimize the performance of certain query expressions to exploit the properties of this type.

See also: xs:integer and xs:positiveInteger.

xs:NMTOKEN(xdt:anyAtomicType) as xs:NMTOKEN

(c:)+

The xs:NMTOKEN type is similar to xs:Name, except that its first character can be any name character (not just name start characters). It is rarely used in XQuery.

See also: xs:Name.

The xs:NMTOKENS type doesn't have a constructor because it derives by list from xs:NMTOKEN. In XQuery, a list of xs:NMTOKEN values has type xs:NMTOKEN*. Consequently, this type is useful only for validation.

See also: xs:NMTOKEN.

xs:nonNegativeInteger(xdt:anyAtomicType) as xs:nonNegativeInteger

+?[0-9]+

+?[1-9][0-9]*

The xs:nonNegativeInteger type represents an arbitrary-precision integer with non-negative value. It is a derived type.

Because all XQuery arithmetic using xs:nonNegativeInteger values takes place using its supertype, xs:integer, this type is primarily useful only for validation purposes and for placing constraints on function parameters. Some implementations may also optimize the performance of certain query expressions to exploit the properties of this type.

See also: xs:integer, xs:nonPositiveInteger, and xs:positiveInteger.

xs:nonPositiveInteger(xdt:anyAtomicType) as xs:nonPositiveInteger

-?[0-9]+

-?[1-9][0-9]*

The xs:nonPositiveInteger type represents an arbitrary-precision integer with non-positive value. It is a derived type.

Because all XQuery arithmetic using xs:nonPositiveInteger values takes place using its supertype, xs:integer, this type is primarily useful only for validation purposes and for placing constraints on function parameters. Some implementations may also optimize the performance of certain query expressions to exploit the properties of this type.

See also: xs:integer, xs:negativeInteger, and xs:nonNegativeInteger.

xs:anyURI(xdt:anyAtomicType) as xs:anyURI

[^	
]*

The xs:normalizedString type represents strings that contains no tab (U+0009), new line (U+000A), or carriage return (U+000D) characters. It is a derived type that behaves like its supertype xs:string except for validation purposes.

See also: xs:string.

xs:NOTATION(xdt:anyAtomicType) as xs:NOTATION

The xs:NOTATION type is a special type from XML 1.0 that is used to name an externally defined entity format or to describe the application targeted by processing instructions.

Note that xs:NOTATION is a distinct type from xs:string, and isn't a subtype of it. Although XQuery defines a constructor for it, the constructor will always result in an error because no other type can be cast to xs:NOTATION.

In XML, the xs:NOTATION type is sometimes used to represent enumeration values. However, XML Schema requires that xs:NOTATION not be used directly (only derived types of it), and also recommends that xs:NOTATION only be used to type attribute nodes, not elements.

XQuery doesn't have any expressions that use the xs:NOTATION type other than equality comparison (eq, =, ne, and !=), which performs a code point comparison on the underlying string values without respect to collation.

xs:positiveInteger(xdt:anyAtomicType) as xs:positiveInteger

+?[0-9]+

[1-9][0-9]*

The xs:positiveInteger type represents an arbitrary-precision integer with a positive value. It is a derived type.

Because all XQuery arithmetic using xs:positiveInteger values takes place using its supertype, xs:integer, this type is primarily useful only for validation purposes and for placing constraints on function parameters. Some implementations may also optimize the performance of certain query expressions to exploit the properties of this type.

See also: xs:integer and xs:negativeInteger.

xs:QName(xdt:anyAtomicType) as xs:QName

(ic*:)ic*

The xs:QName type represents an XML qualified name (that is, a local name and a possibly empty namespace URI). It is written exactly like an xs:Name, but the namespace prefix isn't part of the value; it is used only to look up the namespace uri part of the QName.

The xs:QName type is special in that it cannot be constructed using the usual type constructor syntax, but instead it has its own special constructor functions, fn:expanded-QName() and fn:resolve-QName(), that take either the namespace and local name parts or else a prefixed name string and a namespace context (respectively), and return the corresponding xs:QName value.

As with the calendar types, XQuery provides functions for accessing the individual parts of an xs:QName value: get-local-name-from-QName() and get-namespace-from-QName(). Each of these takes an xs:QName value and returns the corresponding part as an xs:string.

get-local-name-from-QName(expanded-QName("", "x"))
=> "x"

get-namespace-uri-from-QName(expanded-QName("urn:foo", "x"))
=> "urn:foo"

See also: xs:Name, and fn:expanded-QName(), fn:get-local-name-from-QName(), fn:get-namespace-uri-from-QName(), and fn:resolve-QName() in Appendix C.

xs:short(xdt:anyAtomicType) as xs:short

[+-]?[0-9]+

-?[1-9][0-9]*

The xs:short type represents a signed, 2-byte integer, which can range in value from -32768 to 32767. It is a derived type.

Because all XQuery arithmetic using xs:short values takes place using its supertype, xs:integer, this type is primarily useful only for validation purposes and for placing constraints on function parameters. Some implementations may also optimize values with this type to occupy less space, or may optimize the performance of certain query expressions to exploit the properties of this type.

xs:short("0")     => 0
xs:short("32767") => 32767
xs:short("32768") => error (: out of range :)
xs:short("-1")    => -1
xs:short("2.5")   => error (: invalid format :)
xs:short(2.5)     => 2

See also: xs:byte, xs:int, xs:integer, xs:long, and xs:unsignedShort.

xs:string(xdt:anyAtomicType) as xs:string

.*

The xs:string type represents any string value. XQuery strings are sequences of Unicode code point values, without respect to any particular encoding or character representation. XQuery strings can theoretically be of any length, although in practice most implementations limit string values to some maximum size (often determined by available memory).

See also: fn:codepoints-to-string() and fn:string-to-codepoints() in Appendix C, and Chapter 8.

xs:time(xdt:anyAtomicType) as xs:time

[0-9]{2}:[0-9]{2}:[0-9]{2}(.[0-9]*)?(Z|([+-][0-9]{2}:[0-9]{2}))?

[0-9]{2}:[0-9]{2}:[0-9]{2}(.[0-9]*)?Z?

The xs:time type represents a single point on the calendar. It consists of the same hour, minute, second, and time zone parts as the xs:dateTime type (but it isn't derived from xs:dateTime).

xs:time("08:05:01")       (: 8 hours, 5 minutes, 1 second :)
xs:time("23:59:59.99")    (: 23 hours, 59 minutes, 59.99 seconds :)
xs:time("08:05:01Z")      (: 8 hours, 5 minutes, 1 second in UTC :)
xs:time("08:05:01-08:00") (: same time in PST :)

See also: xs:dateTime.

xs:token(xdt:anyAtomicType) as xs:token

^$|[^	
 ]|[^	
 ]([^	
 ]|( [^	
 ]))*[^	
 ]

The xs:token type is a normalized string that doesn't contain any leading or trailing space characters or any sequence of adjacent spaces. The normalize-space() and tokenize() functions can be used to convert any string value into a valid xs:token or to split an xs:token value into separate values not containing spaces.

This type can be used in XQuery type conversions to normalize space characters and can also be useful for constraining function parameters.

See also: xs:normalizedString, and fn:normalize-space() and fn:tokenize in Appendix C.

xs:unsignedByte(xdt:anyAtomicType) as xs:unsignedByte

[0-9]+

[1-9][0-9]*

The xs:unsignedByte type represents an unsigned, single-byte integer that can range in value from 0 to 255. It is a derived type.

Because all XQuery arithmetic using xs:unsignedByte values takes place using its supertype, xs:integer, this type is primarily useful only for validation purposes and for placing constraints on function parameters. Some implementations may also optimize values with this type to occupy less space than xs:integer, or may optimize the performance of certain query expressions to exploit the properties of this type.

xs:unsignedByte("0") => 0
xs:unsignedByte("255") => 255
xs:unsignedByte("256") => error (: out of range :)
xs:unsignedByte("-1")  => error (: invalid format :)
xs:unsignedByte("2.5") => error (: invalid format :)
xs:unsignedByte(2.5)   => 2

See also: xs:byte, xs:nonNegativeInteger, xs:unsignedInt, xs:unsignedLong, and xs:unsignedShort.

xs:unsignedInt(xdt:anyAtomicType) as xs:unsignedInt

[0-9]+

[1-9][0-9]*

The xs:unsignedInt type represents an unsigned, 4-byte integer, which can range in value from 0 to 4294967295. It is a derived type.

Because all XQuery arithmetic using xs:unsignedInt values takes place using its supertype, xs:integer, this type is primarily useful only for validation purposes and for placing constraints on function parameters. Some implementations may also optimize values with this type to occupy less space than xs:integer, or may optimize the performance of certain query expressions to exploit the properties of this type.

xs:unsignedInt("0")          => 0
xs:unsignedInt("4294967295") => 4294967295
xs:unsignedInt("4294967296") => error (: out of range :)
xs:unsignedInt("-1")         => error (: invalid format :)
xs:unsignedInt("2.5")        => error (: invalid format :)
xs:unsignedInt(2.5)          => 2

Implementations that represent xs:integer using a signed, 4-byte integer instead of using arbitrary-precision arithmetic have problems with this type, because it's a subtype of xs:integer yet in that case covers a larger range.

See also: xs:int, xs:nonNegativeInteger, xs:unsignedByte, xs:unsignedLong, and xs:unsignedShort.

xs:unsignedLong(xdt:anyAtomicType) as xs:unsignedLong

[0-9]+

[1-9][0-9]*

The xs:unsignedLong type represents an unsigned, 8-byte integer that can range in value from 0 to 18446744073709551615. It is a derived type.

Because all XQuery arithmetic using xs:unsignedLong values takes place using its supertype, xs:integer, this type is primarily useful only for validation purposes and for placing constraints on function parameters. Some implementations may also optimize values with this type to occupy less space than xs:integer, or may optimize the performance of certain query expressions to exploit the properties of this type.

xs:unsignedLong("0")                    => 0
xs:unsignedLong("18446744073709551615") => 18446744073709551615
xs:unsignedLong("18446744073709551616") => error (: out of range :)
xs:unsignedLong("-1")                => error (: invalid format :)
xs:unsignedLong("2.5")               => error (: invalid format :)
xs:unsignedLong(2.5)                 => 2

Implementations that represent xs:integer using a signed, 4-byte integer or a signed, 8-byte integer instead of using arbitrary-precision arithmetic have problems with this type, because it's a subtype of xs:integer yet in that case covers a larger range than xs:integer can represent.

See also: xs:long, xs:nonNegativeInteger, xs:unsignedByte, xs:unsignedInt, and xs:unsignedShort.

xs:unsignedShort(xdt:anyAtomicType) as xs:unsignedShort

[0-9]+

[1-9][0-9]*

The xs:unsignedShort type represents an unsigned, 2-byte integer that can range in value from 0 to 65535. It is a derived type.

Because all XQuery arithmetic using xs:unsignedShort values takes place using its supertype, xs:integer, this type is primarily useful only for validation purposes and for placing constraints on function parameters. Some implementations may also optimize values with this type to occupy less space than xs:integer, or may optimize the performance of certain query expressions to exploit the properties of this type.

xs:unsignedShort("0")     => 0
xs:unsignedShort("65535") => 65535
xs:unsignedShort("65536") => error (: out of range :)
xs:unsignedShort("-1")    => error (: invalid format :)
xs:unsignedShort("2.5")   => error (: invalid format :)
xs:unsignedShort(2.5)     => 2

See also: xs:nonNegativeInteger, xs:short, xs:unsignedByte, xs:unsignedInt, and xs:unsignedLong.

xdt:untypedAtomic(xdt:anyAtomicType) as xdt:untypedAtomic

.*

The xdt:untypedAtomic type is a pseudo-type given to all untyped XML data (XML data without a schema), including XML attributes constructed in an XQuery when there isn't any schema type for that attribute in scope. Consequently, despite the name, untyped data actually is typed.

In practice, untyped values behave like weakly-typed xs:string values. For type conversion purposes, xdt:untypedAtomic behaves exactly like xs:string; however, for other operators, it often behaves more like XPath 1.0 than XQuery 1.0. For example, adding two xs:string values is a type error in XQuery. Adding two xdt:untypedAtomic values first converts both values to xs:double, and then performs the addition on those numeric values, just like in XPath 1.0.

See also: xdt:anyAtomicType, xs:anySimpleType, and xs:string, and Chapter 2.

xdt:yearMonthDuration(xdt:anyAtomicType) as xdt:yearMonthDuration

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

This type has been introduced by XQuery to allow durations to be compared. As its name suggests, it represents the year and month parts only from a duration. It has the expected lexical and canonical forms (the subset of the forms for xs:duration that includes only the year and month parts).

See also: xdt:dayTimeDuration and xs:duration, and fn:get-months-from-yearMonthDuration(), fn:get-years-from-yearMonthDuration(), and fn:subtract-dateTimes-yielding-yearMonthDuration()in Appendix C.