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.
Table A.1. Occurrence indicators in sequence types
Occurrence indicator | Meaning |
---|---|
Exactly one | |
| Zero or one |
| Zero or more |
| One or more |
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.
Table A.2. Type names used in simple types and sequence types
Type name | Meaning |
---|---|
A qualified name | Atomic type with that name. |
| Any item. |
| Any node kind. |
| Any atomic type. |
| Untyped atomic data. |
| Any attribute node. |
| Any attribute node with the given name. The name may be a qualified name or the wildcard * (matching any name). |
| Any attribute node with the given name and type. The node and type names may be qualified names or the wildcard * (matching any name or any type, respectively). |
| Any attribute node matching the type specified by schema context path and type name. |
| Any comment node. |
| Any document node. |
| Any document node whose content matches the given element node test. |
| Any element node. |
| Any element node with the given name. The name may be a qualified name or the wildcard * (matching any name). |
| Any element node with the given name and type. The node and type names may be qualified names or the wildcard * (matching any name or any type, respectively). |
| Any element node with the given name and type that is nillable. The name and type test may be qualified names or the wildcard *. |
| Any element node matching the type specified by schema context path and type name. |
| Any namespace node. |
| Any processing instruction node. |
| Any processing instruction node with the given target, as in |
| Any text node. |
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.
Table A.3. Constructors for each node kind
Node kind | Constructor(s) |
---|---|
attribute |
|
comment |
comment { content-expr }
<!-- content --> |
document | document { content-expr } |
element |
element name { content-expr } element { name-expr } { content-expr } <name attributes /> <name attributes>content</name> |
namespace |
|
processing instruction |
processing-instruction { target-expr } { content-expr } <?target content?> |
text | 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.
Table A.4. Node properties by node kind
| Attribute | Comment | Document | Element | Namespace | Processing Instruction | Text |
---|---|---|---|---|---|---|---|
attributes |
|
|
|
|
|
|
|
base-uri |
|
|
|
|
|
|
|
children |
|
|
|
|
|
|
|
namespaces |
|
|
|
|
|
|
|
nilled |
|
|
|
|
|
|
|
node-kind |
|
|
|
|
|
|
|
node-name |
|
|
|
|
|
|
|
parent |
|
|
|
|
|
|
|
string-value |
|
|
|
|
|
|
|
typed-value |
|
|
|
|
|
|
|
unique-id |
|
|
|
|
|
|
|
Table A.5. Expressions that access node properties
| Expression | See also |
---|---|---|
attributes |
attribute::* @* | |
base-uri |
| |
children |
child::node() node() | |
namespaces |
| |
nilled |
instance of element(*, nilled) self::*[@xsi:nil="true"] | Chapters 2 and 9 |
node-kind |
| Chapters 2 and 9 |
node-name |
fn:node-name ()fn:name() | |
parent |
| |
string-value |
| |
typed-value |
| |
unique-id |
|
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.
Table A.6. The numeric types and their ranges
Type | Meaning | Range |
---|---|---|
| Single-precision floating-point |
m*2E -224 < m < 224 -149 <= E <= 104 |
| Double-precision floating-point |
m*2E -253 < m < 253 -1075 <= E <= 970 |
| Arbitrary-precision fixed-point (base 10) |
|
| Arbitrary-precision integer |
|
| Arbitrary-precision positive integer |
|
| Arbitrary-precision non-negative integer |
|
| Arbitrary-precision negative integer |
|
| Arbitrary-precision non-positive integer |
|
| 1-byte signed integer |
-128 to 127 (-27 to 27-1) |
| 2-byte signed integer |
-32768 to 32767 (-215 to 215-1) |
| 4-byte signed integer |
-2147483648 to 2147483647 (-231 to 231-1) |
| 8-byte signed integer |
-9223372036854775808 to 9223372036854775807 (-263 to 263-1) |
| 1-byte unsigned integer |
0 to 255 (0 to 28-1) |
| 2-byte unsigned integer |
0 to 65535 (0 to 216-1) |
| 4-byte unsigned integer |
0 to 4294967295 (0 to 232-1) |
| 8-byte unsigned integer |
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.
Table A.7. XQuery numeric type conversion chart
from o | xs:bool | xs:float | xs:double | xs:integer | xs:decimal |
---|---|---|---|---|---|
xs:bool |
|
|
|
| |
xs:float |
|
|
|
| |
xs:double |
|
|
|
| |
xs:integer |
|
|
| ||
xs:decimal |
|
|
|
|
Table A.8. XQuery numeric type conversion rules
Rule | Meaning |
---|---|
| True converts to the number |
| Positive or negative zero and |
| The string representation of the number is parsed as |
| The string representation is parsed as |
| The string representation is parsed as |
| The fractional part, if any, is discarded, and the remaining value converted to |
| The number is converted to the closest decimal value that the implementation can represent (arbitrarily chosen when there is a tie). If the number is infinite or |
Table A.9. XQuery duration type conversion chart
from o | xs: duration | xdt:dayTimeDuration | xdt: yearMonthDuration |
---|---|---|---|
xs:duration |
|
| |
xdt:dayTimeDuration |
| ||
xdt:yearMonthDuration |
|
Table A.10. XQuery duration type conversion rules
Rule | Meaning |
---|---|
| Only the year and month parts of the duration are kept. |
| Only the day and time parts of the duration are kept. |
| No conversion possible (error). |
Table A.11. XQuery calendar type conversion chart
from o | xs:dateTime | xs:date | xs:time | xs:gYear | xs:gYearMonth | xs:gMonth | xs:gDay | xs:gMonthDay |
---|---|---|---|---|---|---|---|---|
xs:dateTime |
|
|
|
|
|
|
| |
xs:date |
|
|
|
|
|
|
| |
xs:time |
|
|
|
|
|
|
|
Table A.12. XQuery calendar type conversion rules
Rule | Meaning |
---|---|
| The |
| The |
| Only the date and time zone parts of the original |
| Only the time and time zone parts of the original |
| Only the year and time zone parts of the original value. |
| Only the year, month, and time zone parts of the original value. |
| Only the month and time zone parts of the original value. |
| Only the day and time zone parts of the original value. |
| Only the month, day, and time zone parts of the original value. |
| No conversion possible (error). |
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.
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.
Example A.1. xs:anyURI
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.
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.
Example A.2. xs:base64Binary
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.
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.
Example A.3. xs:boolean
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.
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.
Example A.4. xs:byte
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
.
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
).
Example A.5. xs:date
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
.
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).
Example A.6. xs:dateTime
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.
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.
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.
Example A.7. xs:decimal
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
.
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 -253 and 253 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.)
Example A.8. xs:double
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
.
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.
Example A.9. xs:duration
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
.
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
.
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 -224 and 224 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.
Example A.10. xs:float
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
.
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
.
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
.
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
.
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
.
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
.
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).
Example A.11. xs:hexBinary
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.
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.
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
.
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.
Example A.12. xs:int
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
.
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).
Example A.13. xs:integer
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
.
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.
See also: xs:string
and fn:lang()
in Appendix C.
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.
Example A.15. xs:long
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
.
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
.
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
.
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
.
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
.
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
.
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
.
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
.
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.
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
.
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
.
Example A.16. QName accessors
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.
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.
Example A.17. xs:short
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
.
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.
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
).
Example A.18. xs:time
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
.
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.
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.
Example A.19. xs:unsignedByte
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
.
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.
Example A.20. xs:unsignedInt
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
.
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.
Example A.21. xs:unsignedLong
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
.
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.
Example A.22. xs:unsignedShort
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
.
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.
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.
18.191.240.80