W3C

XPath and XQuery Functions and Operators 4.0

W3C Editor's Draft 18 October 2024

This version:
https://qt4cg.org/pr/1513/xpath-functions-40/
Latest version of XPath and XQuery Functions and Operators 4.0:
https://qt4cg.org/specifications/xpath-functions-40/
Most recent Recommendation of XPath and XQuery Functions and Operators:
https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/
Editor:
Michael Kay, Saxonica <http://www.saxonica.com/>

Please check the errata for any errors or issues reported since publication.

See also translations.

This document is also available in these non-normative formats: Specification in XML format using HTML5 vocabulary, XML function catalog, and HTML with change markings relative to version 3.0.


Abstract

This document defines constructor functions, operators, and functions on the datatypes defined in [XML Schema Part 2: Datatypes Second Edition] and the datatypes defined in [XQuery and XPath Data Model (XDM) 3.1]. It also defines functions and operators on nodes and node sequences as defined in the [XQuery and XPath Data Model (XDM) 3.1]. These functions and operators are defined for use in [XML Path Language (XPath) 4.0] and [XQuery 4.1: An XML Query Language] and [XSL Transformations (XSLT) Version 4.0] and other related XML standards. The signatures and summaries of functions defined in this document are available at: http://www.w3.org/2005/xpath-functions/.

A summary of changes since version 3.1 is provided at G Changes since version 3.1.

Status of this Document

This version of the specification is work in progress. It is produced by the QT4 Working Group, officially the W3C XSLT 4.0 Extensions Community Group. Individual functions specified in the document may be at different stages of review, reflected in their History notes. Comments are invited, in the form of GitHub issues at https://github.com/qt4cg/qtspecs.


1 Introduction

Changes in 4.0 

  1. Use the arrows to browse significant changes since the 3.1 version of this specification.

  2. Sections with significant changes are marked Δ in the table of contents.

The purpose of this document is to define functions and operators for inclusion in XPath 4.0, XQuery 4.0, and XSLT 4.0. The exact syntax used to call these functions and operators is specified in [XML Path Language (XPath) 4.0], [XQuery 4.1: An XML Query Language] and [XSL Transformations (XSLT) Version 4.0].

This document defines three classes of functions:

[XML Schema Part 2: Datatypes Second Edition] defines a number of primitive and derived datatypes, collectively known as built-in datatypes. This document defines functions and operations on these datatypes as well as the other types (for example, nodes and sequences of nodes) defined in Section 2.7 Schema Information DM31 of the [XQuery and XPath Data Model (XDM) 3.1]. These functions and operations are available for use in [XML Path Language (XPath) 4.0], [XQuery 4.1: An XML Query Language] and any other host language that chooses to reference them. In particular, they may be referenced in future versions of XSLT and related XML standards.

[Schema 1.1 Part 2] adds to the datatypes defined in [XML Schema Part 2: Datatypes Second Edition]. It introduces a new derived type xs:dateTimeStamp, and it incorporates as built-in types the two types xs:yearMonthDuration and xs:dayTimeDuration which were previously XDM additions to the type system. In addition, XSD 1.1 clarifies and updates many aspects of the definitions of the existing datatypes: for example, it extends the value space of xs:double to allow both positive and negative zero, and extends the lexical space to allow +INF; it modifies the value space of xs:Name to permit additional Unicode characters; it allows year zero and disallows leap seconds in xs:dateTime values; and it allows any character string to appear as the value of an xs:anyURI item. Implementations of this specification may support either XSD 1.0 or XSD 1.1 or both.

In some cases, this specification references XSD for the semantics of operations such as the effect of matching using regular expressions, or conversion of atomic items to strings. In most such cases there is no intended technical difference between the XSD 1.0 and XSD 1.1 specifications, but the 1.1 version often provides clearer explanations and sometimes also corrects technical errors. In such cases this specification often chooses to reference the XSD 1.1 specification. This should not be taken as implying that it is necessary to invoke an XSD 1.1 processor.

References to specific sections of some of the above documents are indicated by cross-document links in this document. Each such link consists of a pointer to a specific section followed a superscript specifying the linked document. The superscripts have the following meanings: XQ [XQuery 4.1: An XML Query Language], XT [XSL Transformations (XSLT) Version 4.0], XP [XML Path Language (XPath) 4.0], and DM [XQuery and XPath Data Model (XDM) 3.1].

1.1 Operators

Despite its title, this document does not attempt to define the semantics of all the operators available in the [XML Path Language (XPath) 4.0] language; indeed, in the interests of avoiding duplication, the majority of operators (including all higher-order operators such as x/y, x!y, and x[y], as well simple operators such as x,y, x and y, x or y, x<<y, x>>y, x is y, x||y, x|y, x union y, x except y, x intersect y, x to y and x otherwise y) are now defined entirely within [XML Path Language (XPath) 4.0].

The remaining operators that are described in this publication are those where the semantics of the operator depend on the types of the arguments. For these operators, the language specification describes rules for selecting an internal function defined in this specification to underpin the operator. For example, when the operator x+y is applied to two operands of type xs:double, the function op:numeric-add is selected.

XPath defines a range of comparison operators x=y, x!=y, x<y, x>y, x<=y, x>=y, x eq y, x ne y, x lt y, x gt y, x le y, x ge y, which apply to a variety of operand types including for example numeric values, strings, dates and times, and durations. For each relevant data type, two functions are defined in this specification, for example op:date-equal and op:date-less-than. These define the semantics of the eq and lt operators applied to operands of that data type. The operators x ne y, x gt y, x le y, and x ge y are defined by reference to these two; and the general comparison operators =, !=, <, >, <=, and >= are defined by reference to eq, ne, lt, gt, le, and ge respectively.

Note:

Previous versions of this specification also defined a third comparison function of the form op:date-greater-than. This has been dropped, as it is always the inverse of the -less-than form.

1.2 Conformance

Changes in 4.0  

  1. Higher-order functions are no longer an optional feature.  [Issue 205 PR 326 1 February 2023]

This recommendation contains a set of function specifications. It defines conformance at the level of individual functions. An implementation of a function conforms to a function specification in this recommendation if all the following conditions are satisfied:

  • For all combinations of valid inputs to the function (both explicit arguments and implicit context dependencies), the result of the function meets the mandatory requirements of this specification.

  • For all invalid inputs to the function, the implementation raises (in some way appropriate to the calling environment) a dynamic error.

  • For a sequence of calls within the same ·execution scope·, the requirements of this recommendation regarding the ·determinism· of results are satisfied (see 1.9.5 Properties of functions).

Other recommendations (“host languages”) that reference this document may dictate:

  • Subsets or supersets of this set of functions to be available in particular environments;

  • Mechanisms for invoking functions, supplying arguments, initializing the static and dynamic context, receiving results, and handling errors;

  • A concrete realization of concepts such as ·execution scope·;

  • Which versions of other specifications referenced herein (for example, XML, XSD, or Unicode) are to be used.

Any behavior that is discretionary (implementation-defined or implementation-dependent) in this specification may be constrained by a host language.

Note:

Adding such constraints in a host language, however, is discouraged because it makes it difficult to reuse implementations of the function library across host languages.

This specification allows flexibility in the choice of versions of specifications on which it depends:

  • It is ·implementation-defined· which version of Unicode is supported, but it is recommended that the most recent version of Unicode be used.

  • It is ·implementation-defined· whether the type system is based on XML Schema 1.0 or XML Schema 1.1.

  • It is ·implementation-defined· whether definitions that rely on XML (for example, the set of valid XML characters) should use the definitions in XML 1.0 or XML 1.1.

Note:

The XML Schema 1.1 recommendation introduces one new concrete datatype: xs:dateTimeStamp; it also incorporates the types xs:dayTimeDuration, xs:yearMonthDuration, and xs:anyAtomicType which were previously defined in earlier versions of [XQuery and XPath Data Model (XDM) 3.1]. Furthermore, XSD 1.1 includes the option of supporting revised definitions of types such as xs:NCName based on the rules in XML 1.1 rather than 1.0.

The [XQuery and XPath Data Model (XDM) 4.0] allows flexibility in the repertoire of characters permitted during processing that goes beyond even what version of XML is supported. A processor may allow the user to construct nodes and atomic items that contain characters not allowed by any version of XML. [Definition] A permitted character is one within the repertoire accepted by the implementation.

In this document, text labeled as an example or as a note is provided for explanatory purposes and is not normative.

1.3 Namespaces and prefixes

The functions and operators defined in this document are contained in one of several namespaces (see [Namespaces in XML]) and referenced using an xs:QName.

This document uses conventional prefixes to refer to these namespaces. User-written applications can choose a different prefix to refer to the namespace, so long as it is bound to the correct URI. The host language may also define a default namespace for function calls, in which case function names in that namespace need not be prefixed at all. In many cases the default namespace will be http://www.w3.org/2005/xpath-functions, allowing a call on the fn:name function (for example) to be written as name() rather than fn:name(); in this document, however, all example function calls are explicitly prefixed.

The URIs of the namespaces and the conventional prefixes associated with them are:

  • http://www.w3.org/2001/XMLSchema for constructors — associated with xs.

    The section 19 Constructor functions defines constructor functions for the built-in datatypes defined in [XML Schema Part 2: Datatypes Second Edition] and in Section 2.7 Schema Information DM31 of [XQuery and XPath Data Model (XDM) 3.1]. These datatypes and the corresponding constructor functions are in the XML Schema namespace, http://www.w3.org/2001/XMLSchema, and are named in this document using the xs prefix.

  • http://www.w3.org/2005/xpath-functions for functions — associated with fn.

    The namespace prefix used in this document for most functions that are available to users is fn.

  • http://www.w3.org/2005/xpath-functions/math for functions — associated with math.

    This namespace is used for some mathematical functions. The namespace prefix used in this document for these functions is math. These functions are available to users in exactly the same way as those in the fn namespace.

  • http://www.w3.org/2005/xpath-functions/map for functions — associated with map.

    This namespace is used for some functions that manipulate maps (see 17.3 Functions that Operate on Maps). The namespace prefix used in this document for these functions is map. These functions are available to users in exactly the same way as those in the fn namespace.

  • http://www.w3.org/2005/xpath-functions/array for functions — associated with array.

    This namespace is used for some functions that manipulate maps (see 18.2 Functions that Operate on Arrays). The namespace prefix used in this document for these functions is array. These functions are available to users in exactly the same way as those in the fn namespace.

  • http://www.w3.org/2005/xqt-errors — associated with err.

    There are no functions in this namespace; it is used for error codes.

    This document uses the prefix err to represent the namespace URI http://www.w3.org/2005/xqt-errors, which is the namespace for all XPath and XQuery error codes and messages. This namespace prefix is not predeclared and its use in this document is not normative.

  • http://www.w3.org/2010/xslt-xquery-serialization — associated with output.

    There are no functions in this namespace: it is used for serialization parameters, as described in [XSLT and XQuery Serialization 3.1]

  • Functions defined with the op prefix are described here to underpin the definitions of the operators in [XML Path Language (XPath) 4.0], [XQuery 4.1: An XML Query Language] and [XSL Transformations (XSLT) Version 4.0]. These functions are not available directly to users, and there is no requirement that implementations should actually provide these functions. For this reason, no namespace is associated with the op prefix. For example, multiplication is generally associated with the * operator, but it is described as a function in this document:

    op:numeric-multiply(
    $arg1 as xs:numeric,
    $arg2 as xs:numeric
    ) as xs:numeric

    Sometimes there is a need to use an operator as a function. To meet this requirement, the function fn:op takes any simple binary operator as its argument, and returns a corresponding function. So for example fn:for-each-pair($seq1, $seq2, op("+")) performs a pairwise addition of the values in two input sequences.

Note:

The above namespace URIs are not expected to change from one version of this document to another. The contents of these namespaces may be extended to allow additional functions (and errors, and serialization parameters) to be defined.

1.4 Function overloading

A function is uniquely defined by its name and arity (number of arguments); it is therefore not possible to have two different functions that have the same name and arity, but different types in their signature. That is, function overloading in this sense of the term is not permitted. Consequently, functions such as fn:string which accept arguments of many different types have a signature that defines a very general argument type, in this case item()? which accepts any single item; supplying an inappropriate item (such as a function item) causes a dynamic error.

Some functions on numeric types include the type xs:numeric in their signature as an argument or result type. In this version of the specification, xs:numeric has been redefined as a built-in union type representing the union of xs:decimal, xs:float, xs:double (and thus automatically accepting types derived from these, including xs:integer).

Operators such as + may be overloaded: they map to different underlying functions depending on the dynamic types of the supplied operands.

It is possible for two functions to have the same name provided they have different arity (number of arguments). For the functions defined in this specification, where two functions have the same name and different arity, they also have closely related behavior, so they are defined in the same section of this document.

1.5 Function signatures and descriptions

Each function (or group of functions having the same name) is defined in this specification using a standard proforma. This has the following sections:

1.5.1 Function name

The function name is a QName as defined in [XML Schema Part 2: Datatypes Second Edition] and must adhere to its syntactic conventions. Following the precedent set by [XML Path Language (XPath) Version 1.0], function names are generally composed of English words separated by hyphens: specifically U+002D (HYPHEN-MINUS, -) . Abbreviations are used only where there is a strong precedent in other programming languages (as with math:sin and math:cos for sine and cosine). If a function name contains a [XML Schema Part 2: Datatypes Second Edition] datatype name, it may have intercapitalized spelling and is used in the function name as such. An example is fn:timezone-from-dateTime.

1.5.2 Function summary

The first section in the proforma is a short summary of what the function does. This is intended to be informative rather than normative.

1.5.3 Function signature

Each function is then defined by specifying its signature(s), which define the types of the parameters and of the result value.

Where functions take a variable number of arguments, two conventions are used:

  • Wherever possible, a single function signature is used giving default values for those parameters that can be omitted.

  • If this is not possible, because the effect of omitting a parameter cannot be specified by giving a default value, multiple signatures are given for the function.

Each function signature is presented in a form like this:

fn:function-name(
$parameter-name as parameter-type,
$... as 
) as return-type

In this notation, function-name, in bold-face, is the local name of the function whose signature is being specified. The prefix fn indicates that the function is in the namespace http://www.w3.org/2005/xpath-functions: this is one of the conventional prefixes listed in 1.3 Namespaces and prefixes. If the function takes no parameters, then the name is followed by an empty parameter list: (); otherwise, the name is followed by a parenthesized list of parameter declarations. Each parameter declaration includes:

  • The name of the parameter (which in 4.0 is significant because it can be used as a keyword in a function call)

  • The static type of the parameter (in italics)

  • If this is the last parameter of a ·variadic· function, an ellipsis (...)

  • If the parameter is optional, then an expression giving the default value (preceded by the symbol :=).

    The default value expression is evaluated using the static and dynamic context of the function caller (or of a named function reference). For example, if the default value is given as ., then it evaluates to the context value from the dynamic context of the function caller; if it is given as default-collation, then its value is the default collation from the static context of the function caller; if it is given as deep-equal#2, then the third argument supplied to deep-equal is the default collation from the static context of the caller.

If there are two or more parameter declarations, they are separated by a comma.

The return-type, also in italics, specifies the static type of the value returned by the function. The dynamic type of the value returned by the function is the same as its static type or derived from the static type. All parameter types and return types are specified using the SequenceType notation defined in Section 2.5.4 SequenceType Syntax XP31.

If a function is ·variadic·, it has a variable number of arguments (zero or more). More strictly, there is an infinite set of functions having the same name and different arities.

1.5.4 Function rules

The next section in the proforma defines the semantics of the function as a set of rules. The order in which the rules appear is significant; they are to be applied in the order in which they are written. Error conditions, however, are generally listed in a separate section that follows the main rules, and take precedence over non-error rules except where otherwise stated. The principles outlined in Section 2.3.4 Errors and Optimization XP31 apply by default: to paraphrase, if the result of the function can be determined without evaluating all its arguments, then it is not necessary to evaluate the remaining arguments merely in order to determine whether any error conditions apply.

1.5.5 Formal Specification

Some functions supplement the prose rules with a formal specification that describes the effect of the function in terms of an equivalent XPath or XQuery implementation. This is intended to take precedence over the prose rules in the event of any conflict; however, both sections are intended to be complete and not to rely on each other.

In writing the formal specifications, a number of guidelines have been followed:

  1. Where the equivalent code calls other functions, these should either be primitives defined in the data model specification (see [XQuery and XPath Data Model (XDM) 3.1]), or functions that themselves have a formal specification; and the dependencies should not be circular.

  2. There should be minimal reliance on XPath or XQuery language features. Although no attempt has been made to precisely define a core set of language constructs, the specifications try to avoid relying on features other than function calls and a few basic operators including the comma operator, equality testing, and simple integer arithmetic.

Editorial note  
This worthy intent is not yet fully achieved; for example there are formal specifications that invoke fn:atomic-equal.

There is no attempt to write formal specifications for functions that have complex logic (such as fn:format-number) or dependencies (such as fn:doc); the aim of the formal specifications is to define as rigorously as possible a platform of basic functionality that can be used as a solid foundation for more complex features.

1.5.6 Notes

Where the proforma includes a section headed Notes, these are non-normative.

1.5.7 Examples

Where the proforma includes a section headed Examples, these are non-normative.

Many of the examples are given in structured form, showing example expressions and their expected results. These published examples are derived from executable test cases, so they follow a standard format. In general, the actual result of the expression is expected to be deep-equal to the presented result, under the rules of the fn:deep-equal function with default options. In some cases the result is qualified to indicate that the order of items in the result is implementation-dependent, or that numeric results are approximate.

For more complex functions, examples may be given using informal narrative prose.

1.6 Function calls

Rules for passing parameters to operators are described in the relevant sections of [XQuery 4.1: An XML Query Language] and [XML Path Language (XPath) 4.0]. For example, the rules for passing parameters to arithmetic operators are described in Section 3.5 Arithmetic Expressions XP31. Specifically, rules for parameters of type xs:untypedAtomic and the empty sequence are specified in this section.

As is customary, the parameter type name indicates that the function or operator accepts arguments of that type, or types derived from it, in that position. This is called subtype substitution (See Section 2.5.5 SequenceType Matching XP31). In addition, numeric type instances and instances of type xs:anyURI can be promoted to produce an argument of the required type. (See Section B.1 Type Promotion XP31).

  1. Subtype Substitution: A derived type may substitute for its base type. In particular, xs:integer may be used where xs:decimal is expected.

  2. Numeric Type Promotion: xs:decimal may be promoted to xs:float or xs:double. Promotion to xs:double should be done directly, not via xs:float, to avoid loss of precision.

  3. anyURI Type Promotion: A value of type xs:anyURI can be promoted to the type xs:string.

Some functions accept a single value or the empty sequence as an argument and some may return a single value or the empty sequence. This is indicated in the function signature by following the parameter or return type name with a question mark: ?, indicating that either a single value or the empty sequence must appear. See below.

fn:function-name(
$parameter-name as parameter-type
) as return-type?

Note that this function signature is different from a signature in which the parameter is omitted. See, for example, the two signatures for fn:string. In the first signature, the parameter is omitted and the argument defaults to the context value, referred to as .. In the second signature, the argument must be present but may be the empty sequence, written as ().

Some functions accept a sequence of zero or more values as an argument. This is indicated by following the name of the type of the items in the sequence with *. The sequence may contain zero or more items of the named type. For example, the function below accepts a sequence of xs:double and returns a xs:double or the empty sequence.

fn:median(
$arg as xs:double*
) as xs:double?

In XPath 4.0, the arguments in a function call can be supplied by keyword as an alternative to supplying them positionally. For example the call resolve-uri(@href, static-base-uri()) can now be written resolve-uri(base: static-base-uri(), relative: @href). The order in which arguments are supplied can therefore differ from the order in which they are declared. The specification, however, continues to use phrases such as “the second argument” as a convenient shorthand for "the value of the argument that is bound to the second parameter declaration".

1.7 Options

Changes in 4.0  

  1. Use of an option keyword that is not defined in the specification and is not known to the implementation now results in a dynamic error; previously it was ignored.   [Issue 1019 PR 1059 26 March 2024]

As a matter of convention, a number of functions defined in this document take a parameter whose value is a map, defining options controlling the detail of how the function is evaluated. Maps are a new datatype introduced in XPath 3.1.

For example, the function fn:xml-to-json has an options parameter allowing specification of whether the output is to be indented. A call might be written:

xml-to-json($input, { 'indent': true() })

[Definition] Functions that take an options parameter adopt common conventions on how the options are used. These are referred to as the option parameter conventions. These rules apply only to functions that explicitly refer to them.

Where a function adopts the ·option parameter conventions·, the following rules apply:

  1. The value of the relevant argument must be a map. The entries in the map are referred to as options: the key of the entry is called the option name, and the associated value is the option value. Option names defined in this specification are always strings (single xs:string values). Option values may be of any type.

  2. The type of the options parameter in the function signature is always given as map(*).

  3. Although option names are described above as strings, the actual key may be any value that compares equal to the required string (using the eq operator with Unicode codepoint collation; or equivalently, the fn:atomic-equal relation). For example, instances of xs:untypedAtomic or xs:anyURI are equally acceptable.

    Note:

    This means that the implementation of the function can check for the presence and value of particular options using the functions map:contains and/or map:get.

  4. Implementations may attach an ·implementation-defined· meaning to options in the map that are not described in this specification. These options should use values of type xs:QName as the option names, using an appropriate namespace.

  5. If an option is present whose key is not described in the specification, then a type error [err:XPTY0004]XP must be raised unless either (a) the key is recognized by the implementation, or (b) the key is a value of type xs:QName with a non-absent namespace.

  6. All entries in the options map are optional, and supplying an empty map has the same effect as omitting the relevant argument in the function call, assuming this is permitted.

  7. For each named option, the function specification defines a required type for the option value. The value that is actually supplied in the map is converted to this required type using the coercion rulesXP40. This will result in an error (typically [err:XPTY0004]XP or [err:FORG0001]FO) if conversion of the supplied value to the required type is not possible. A type error also occurs if this conversion delivers a coerced function whose invocation fails with a type error. A dynamic error occurs if the supplied value after conversion is not one of the permitted values for the option in question: the error codes for this error are defined in the specification of each function.

    Note:

    It is the responsibility of each function implementation to invoke this conversion; it does not happen automatically as a consequence of the function-calling rules.

  8. In cases where an option is list-valued, by convention the function should accept either a sequence or an array: but this rule applies only if the specification of the option explicitly accepts either. Accepting a sequence is convenient if the value is generated programmatically using an XPath expression; while accepting an array allows the options to be held in an external file in JSON format, to be read using a call on the fn:json-doc function.

  9. In cases where the value of an option is itself a map, the specification of the particular function must indicate whether or not these rules apply recursively to the contents of that map.

1.8 Type System

The diagrams in this section show how nodes, functions, primitive simple types, and user defined types fit together into a type system. This type system comprises two distinct subsystems that both include the primitive atomic types. In the diagrams, connecting lines represent relationships between derived types and the types from which they are derived; the former are always below and to the right of the latter.

The xs:IDREFS, xs:NMTOKENS, xs:ENTITIES types, and xs:numeric and both the user-defined list types and user-defined union types are special types in that these types are lists or unions rather than types derived by extension or restriction.

1.8.1 Item Types

The first diagram illustrates the relationship of various item types.

Item types are used to characterize the various types of item that can appear in a sequence (nodes, atomic items, and functions), and they are therefore used in declaring the types of variables or the argument types and result types of functions.

Item types in the data model form a directed graph, rather than a hierarchy or lattice: in the relationship defined by the derived-from(A, B) function, some types are derived from more than one other type. Examples include functions (function(xs:string) as xs:int is substitutable for function(xs:NCName) as xs:int and also for function(xs:string) as xs:decimal), and union types (A is substitutable for the union type (A | B) and also for (A | C). In XDM, item types include node types, function types, and built-in atomic types. The diagram, which shows only hierarchic relationships, is therefore a simplification of the full model.

  • item (abstract)

    • anyAtomicType (built-in atomic)

    • node (node)

      • attribute (node)

        • user-defined attribute types (user-defined)

      • document (node)

        • user-defined document types (user-defined)

      • element (node)

        • user-defined element types (user-defined)

      • text (node)

      • comment (node)

      • processing-instruction (node)

      • namespace (node)

    • function(*) (function item)

      • array(*) (function item)

      • map(*) (function item)

Legend:

  • Supertype

    • subtype

  • Abstract types (abstract)

  • Built-in atomic types (built-in atomic)

  • Node types (node)

  • Function item types (function item)

  • User-defined types (user-defined)

1.8.2 Schema Type Hierarchy

The next diagram illustrate the schema type subsystem, in which all types are derived from xs:anyType.

Schema types include built-in types defined in the XML Schema specification, and user-defined types defined using mechanisms described in the XML Schema specification. Schema types define the permitted contents of nodes. The main categories are complex types, which define the permitted content of elements, and simple types, which can be used to constrain the values of both elements and attributes.

  • XML Schema types (abstract)

    • anyType (built-in complex)

      • Simple types (abstract)

        • anySimpleType (built-inlist)

          • Atomic types (abstract)

          • list types (abstract)

            • ENTITIES (built-in list)

            • IDREFS (built-in list)

            • NMTOKENS (built-in list)

            • user-defined list types (user-defined)

          • union types (abstract)

            • numeric (built-in complex)

            • user-defined union types (user-defined)

        • complex types (complex)

          • untyped (built-in complex)

          • user-defined complex types (user-defined)

Legend:

  • Supertype

    • subtype

  • Abstract types (abstract)

  • Built-in atomic types (built-in atomic)

  • Built-in complex types (built-in complex)

  • Built-in list types (built-in list)

  • User-defined types (user-defined)

1.8.3 Atomic Type Hierarchy

The final diagram shows all of the atomic types, including the primitive simple types and the built-in types derived from the primitive simple types. This includes all the built-in datatypes defined in [XML Schema Part 2: Datatypes Second Edition].

Atomic types are both item types and schema types, so the root type xs:anyAtomicType may be found in both the previous diagrams.

  • anyAtomicType

    • anyURI

    • base64Binary

    • boolean

    • date

    • dateTime

      • dateTimeStamp

    • decimal

      • integer

        • long

          • int

            • short

              • byte

        • nonNegativeInteger

          • positiveInteger

          • unsignedLong

            • unsignedInt

              • unsignedShort

                • unsignedByte

        • nonPositiveInteger

          • negativeInteger

    • double

    • duration

      • dayTimeDuration

      • yearMonthDuration

    • float

    • gDay

    • gMonth

    • gMonthDay

    • gYear

    • gYearMonth

    • hexBinary

    • NOTATION

    • QName

    • string

      • normalizedString

        • token

          • NMTOKEN

          • Name

            • NCName

              • ENTITY

              • ID

              • IDREF

          • language

    • time

Legend:

  • Supertype

    • subtype

  • Built-in atomic types

1.9 Terminology

Changes in 4.0  

  1. The term atomic value has been replaced by atomic item.   [Issue 1337 PR 1361 2 August 2024]

The terminology used to describe the functions and operators on types defined in [XML Schema Part 2: Datatypes Second Edition] is defined in the body of this specification. The terms defined in this section are used in building those definitions.

Note:

Following in the tradition of [XML Schema Part 2: Datatypes Second Edition], the terms type and datatype are used interchangeably.

1.9.1 Atomic items

The following definitions are adopted from [XQuery and XPath Data Model (XDM) 4.0].

  • [Definition] An atomic item is a pair (T, D) where T (the ·type annotation·) is an atomic type, and D (the ·datum·) is a point in the value space of T.

  • [Definition] A primitive type is one of the 19 primitive atomic types defined in Section 3.2 Primitive datatypesXS2 of [XML Schema Part 2: Datatypes Second Edition], or the type xs:untypedAtomic defined in [XQuery and XPath Data Model (XDM) 4.0].

  • [Definition] The datum of an ·atomic item· is a point in the value space of its type, which is also a point in the value space of the primitive type from which that type is derived. There are 20 primitive atomic types (19 defined in XSD, plus xs:untypedAtomic), and these have non-overlapping value spaces, so each datum belongs to exactly one primitive atomic type.

  • [Definition] The type annotation of an atomic item is the most specific atomic type that it is an instance of (it is also an instance of every type from which that type is derived).

Note:

The term value space is defined in [Schema 1.1 Part 2] as a set of values. The term datum is used here in preference to value, because value has a different meaning in this data model.

1.9.2 Strings, characters, and codepoints

This document uses the terms string, character, and codepoint with meanings that are normatively defined in [XQuery and XPath Data Model (XDM) 3.1], and which are paraphrased here for ease of reference:

[Definition] A character is an instance of the CharXML production of [Extensible Markup Language (XML) 1.0 (Fifth Edition)].

Note:

This definition excludes Unicode characters in the surrogate blocks as well as U+FFFE and U+FFFF, while including characters with codepoints greater than U+FFFF which some programming languages treat as two characters. The valid characters are defined by their codepoints, and include some whose codepoints have not been assigned by the Unicode consortium to any character.

[Definition] A string is a sequence of zero or more ·characters·, or equivalently, a value in the value space of the xs:string datatype.

[Definition] A codepoint is an integer assigned to a ·character· by the Unicode consortium, or reserved for future assignment to a character.

Note:

The set of codepoints is thus wider than the set of characters.

This specification spells “codepoint” as one word; the Unicode specification spells it as “code point”. Equivalent terms found in other specifications are “character number” or “code position”. See [Character Model for the World Wide Web 1.0: Fundamentals]

Because these terms appear so frequently, they are hyperlinked to the definition only when there is a particular desire to draw the reader’s attention to the definition; the absence of a hyperlink does not mean that the term is being used in some other sense.

It is ·implementation-defined· which version of [The Unicode Standard] is supported, but it is recommended that the most recent version of Unicode be used.

This specification adopts the Unicode notation U+xxxx to refer to a codepoint by its hexadecimal value (always four to six hexadecimal digits). This is followed where appropriate by the official Unicode character name and its graphical representation: for example U+20AC (EURO SIGN, ) .

Unless explicitly stated, the functions in this document do not ensure that any returned xs:string values are normalized in the sense of [Character Model for the World Wide Web 1.0: Fundamentals].

Note:

In functions that involve character counting such as fn:substring, fn:string-length and fn:translate, what is counted is the number of XML ·characters· in the string (or equivalently, the number of Unicode codepoints). Some implementations may represent a codepoint above U+FFFF using two 16-bit values known as a surrogate pair. A surrogate pair counts as one character, not two.

1.9.3 Namespaces and URIs

This document uses the phrase “namespace URI” to identify the concept identified in [Namespaces in XML] as “namespace name”, and the phrase “local name” to identify the concept identified in [Namespaces in XML] as “local part”.

It also uses the term “expanded-QName” defined below.

[Definition] An expanded-QName is a value in the value space of the xs:QName datatype as defined in the XDM data model (see [XQuery and XPath Data Model (XDM) 4.0]): that is, a triple containing namespace prefix (optional), namespace URI (optional), and local name. Two expanded QNames are equal if the namespace URIs are the same (or both absent) and the local names are the same. The prefix plays no part in the comparison, but is used only if the expanded QName needs to be converted back to a string.

The term URI is used as follows:

[Definition] Within this specification, the term URI refers to Universal Resource Identifiers as defined in [RFC 3986] and extended in [RFC 3987] with a new name IRI. The term URI Reference, unless otherwise stated, refers to a string in the lexical space of the xs:anyURI datatype as defined in [XML Schema Part 2: Datatypes Second Edition].

Note:

This means, in practice, that where this specification requires a “URI Reference”, an IRI as defined in [RFC 3987] will be accepted, provided that other relevant specifications also permit an IRI. The term URI has been retained in preference to IRI to avoid introducing new names for concepts such as “Base URI” that are defined or referenced across the whole family of XML specifications. Note also that the definition of xs:anyURI is a wider definition than the definition in [RFC 3987]; for example it does not require non-ASCII characters to be escaped.

1.9.4 Conformance terminology

In this specification:

  • The auxiliary verb must, when rendered in small capitals, indicates a precondition for conformance.

    • When the sentence relates to an implementation of a function (for example "All implementations must recognize URIs of the form ...") then an implementation is not conformant unless it behaves as stated.

    • When the sentence relates to the result of a function (for example "The result must have the same type as $arg") then the implementation is not conformant unless it delivers a result as stated.

    • When the sentence relates to the arguments to a function (for example "The value of $arg must be a valid regular expression") then the implementation is not conformant unless it enforces the condition by raising a dynamic error whenever the condition is not satisfied.

  • The auxiliary verb may, when rendered in small capitals, indicates optional or discretionary behavior. The statement “An implementation may do X” implies that it is implementation-dependent whether or not it does X.

  • The auxiliary verb should, when rendered in small capitals, indicates desirable or recommended behavior. The statement “An implementation should do X” implies that it is desirable to do X, but implementations may choose to do otherwise if this is judged appropriate.

[Definition] Where behavior is described as implementation-defined, variations between processors are permitted, but a conformant implementation must document the choices it has made.

[Definition] Where behavior is described as implementation-dependent, variations between processors are permitted, and conformant implementations are not required to document the choices they have made.

Note:

Where this specification states that something is implementation-defined or implementation-dependent, it is open to host languages to place further constraints on the behavior.

1.9.5 Properties of functions

This section is concerned with the question of whether two calls on a function, with the same arguments, may produce different results.

In this section the term function, unless otherwise specified, applies equally to function definitionsXP40 (which can be the target of a static function call) and function itemsDM40 (which can be the target of a dynamic function call).

[Definition] An execution scope is a sequence of calls to the function library during which certain aspects of the state are required to remain invariant. For example, two calls to fn:current-dateTime within the same execution scope will return the same result. The execution scope is defined by the host language that invokes the function library. In XSLT, for example, any two function calls executed during the same transformation are in the same execution scope (except that static expressions, such as those used in use-when attributes, are in a separate execution scope).

The following definition explains more precisely what it means for two function calls to return the same result:

[Definition] Two values $V1 and $V2 are defined to be identical if they contain the same number of items and the items are pairwise identical. Two items are identical if and only if one of the following conditions applies:

  1. Both items are atomic items, of precisely the same type, and the values are equal as defined using the eq operator, using the Unicode codepoint collation when comparing strings.

  2. Both items are nodes, and represent the same node.

  3. Both items are maps, both maps have the same number of entries, and for every entry E1 in the first map there is an entry E2 in the second map such that the keys of E1 and E2 are ·the same key·, and the corresponding values V1 and V2 are ·identical·.

  4. Both items are arrays, both arrays have the same number of members, and the members are pairwise ·identical·.

  5. Both items are function items, neither item is a map or array, and the two function items have the same function identity. The concept of function identity is explained in Section 2.9.4 Function ItemsDM40.

Some functions produce results that depend not only on their explicit arguments, but also on the static and dynamic context.

[Definition] A function definitionXP40 may have the property of being context-dependent: the result of such a function depends on the values of properties in the static and dynamic evaluation context of the caller as well as on the actual supplied arguments (if any). A function definition may be context-dependent for some arities in its arity range, and context-independent for others: for example fn:name#0 is context-dependent while fn:name#1 is context-independent.

[Definition] A function definitionXP40 that is not ·context-dependent· is called context-independent.

The main categories of context-dependent functions are:

  • Functions that explicitly deliver the value of a component of the static or dynamic context, for example fn:static-base-uri, fn:default-collation, fn:position, or fn:last.

  • Functions with an optional parameter whose default value is taken from the static or dynamic context of the caller, usually either the context value (for example, fn:node-name) or the default collation (for example, fn:index-of).

  • Functions that use the static context of the caller to expand or disambiguate the values of supplied arguments: for example fn:doc expands its first argument using the static base URI of the caller, and xs:QName expands its first argument using the in-scope namespaces of the caller.

[Definition] A function is focus-dependent if its result depends on the focusXP31 (that is, the context item, position, or size) of the caller.

[Definition] A function that is not ·focus-dependent· is called focus-independent.

Notes:

Note:

Some functions depend on aspects of the dynamic context that remain invariant within an ·execution scope·, such as the implicit timezone. Formally this is treated in the same way as any other context dependency, but internally, the implementation may be able to take advantage of the fact that the value is invariant.

Note:

User-defined functions in XQuery and XSLT may depend on the static context of the function definition (for example, the in-scope namespaces) and also in a limited way on the dynamic context (for example, the values of global variables). However, the only way they can depend on the static or dynamic context of the caller — which is what concerns us here — is by defining optional parameters whose default values are context-dependent.

Note:

Because the focus is a specific part of the dynamic context, all ·focus-dependent· functions are also ·context-dependent·. A ·context-dependent· function, however, may be either ·focus-dependent· or ·focus-independent·.

A function definition that is context-dependent can be used as the target of a named function reference, can be partially applied, and can be found using fn:function-lookup. The principle in such cases is that the static context used for the function evaluation is taken from the static context of the named function reference, partial function application, or the call on fn:function-lookup; and the dynamic context for the function evaluation is taken from the dynamic context of the evaluation of the named function reference, partial function application, or the call of fn:function-lookup. These constructs all deliver a function itemDM40 having a captured context based on the static and dynamic context of the construct that created the function item. This captured context forms part of the closure of the function item.

The result of a dynamic call to a function item never depends on the static or dynamic context of the dynamic function call, only (where relevant) on the the captured context held within the function item itself.

The fn:function-lookup function is a special case because it is potentially dependent on everything in the static and dynamic context. This is because the static and dynamic context of the call to fn:function-lookup form the captured context of the function item that fn:function-lookup returns.

[Definition] A function that is guaranteed to produce ·identical· results from repeated calls within a single ·execution scope· if the explicit and ·implicit· arguments are identical is referred to as deterministic.

[Definition] A function that is not ·deterministic· is referred to as nondeterministic.

All functions defined in this specification are ·deterministic· unless otherwise stated. Exceptions include the following:

Where the results of a function are described as being (to a greater or lesser extent) ·implementation-defined· or ·implementation-dependent·, this does not by itself remove the requirement that the results should be deterministic: that is, that repeated calls with the same explicit and implicit arguments must return identical results.

[Definition] If a variadic function is called, several arguments in the function call are sequence-concatenated to supply the value of a single parameter in the function definition.

2 Functions on nodes and node sequences

2.1 Accessors

Accessors and their semantics are described in [XQuery and XPath Data Model (XDM) 3.1]. Some of these accessors are exposed to the user through the functions described below.

Each of these functions has an arity-zero signature which is equivalent to the arity-one form, with the context value supplied as the implicit first argument. In addition, each of the arity-one functions accepts an empty sequence as the argument, in which case it generally delivers an empty sequence as the result: the exception is fn:string, which delivers a zero-length string.

Function Accessor Accepts Returns
fn:node-name node-name node (optional) xs:QName (optional)
fn:nilled nilled node (optional) xs:boolean (optional)
fn:string string-value item (optional) xs:string
fn:data typed-value zero or more items a sequence of atomic items
fn:base-uri base-uri node (optional) xs:anyURI (optional)
fn:document-uri document-uri node (optional) xs:anyURI (optional)
Function Meaning
fn:node-name Returns the name of a node, as an xs:QName.
fn:nilled Returns true for an element that is nilled.
fn:string Returns the value of $value represented as an xs:string.
fn:data Returns the result of atomizing a sequence. This process flattens arrays, and replaces nodes by their typed values.
fn:base-uri Returns the base URI of a node.
fn:document-uri Returns the URI of a resource where a document can be found, if available.

2.1.1 fn:node-name

Summary

Returns the name of a node, as an xs:QName.

Signature
fn:node-name(
$node as node()? := .
) as xs:QName?
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If the argument is omitted, it defaults to the context value (.).

If $node is the empty sequence, the empty sequence is returned.

Otherwise, the function returns the result of the dm:node-name accessor as defined in [XQuery and XPath Data Model (XDM) 3.1] (see Section 4.10 node-name AccessorDM40).

Error Conditions

The following errors may be raised when $node is omitted:

Notes

For element and attribute nodes, the name of the node is returned as an xs:QName, retaining the prefix, namespace URI, and local part.

For processing instructions, the name of the node is returned as an xs:QName in which the prefix and namespace URI are absentDM40.

For a namespace node, the function returns an empty sequence if the node represents the default namespace; otherwise it returns an xs:QName in which prefix and namespace URI are absentDM40 and the local part is the namespace prefix being bound.

For all other kinds of node, the function returns the empty sequence.

Examples
Variables
let $e := <doc>
  <p id="alpha" xml:id="beta">One</p>
  <p id="gamma" xmlns="http://example.com/ns">Two</p>
  <ex:p id="delta" xmlns:ex="http://example.com/ns">Three</ex:p>
  <?pi 3.14159?>
</doc>
Expression Result
node-name($e//*[@id = 'alpha'])
QName("", "p")
node-name($e//*[@id = 'gamma'])
QName("http://example.com/ns", "p")
node-name($e//*[@id = 'delta'])
QName("http://example.com/ns", "ex:p")
node-name($e//processing-instruction())
QName("", "pi")
node-name($e//*[@id = 'alpha']/text())
()
node-name($e//*[@id = 'alpha']/@id)
QName("", "id")
node-name($e//*[@id = 'alpha']/@xml:id)
xs:QName("xml:id")

2.1.2 fn:nilled

Summary

Returns true for an element that is nilled.

Signature
fn:nilled(
$node as node()? := .
) as xs:boolean?
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If the argument is omitted, it defaults to the context value (.).

If $node is the empty sequence, the function returns the empty sequence.

Otherwise the function returns the result of the dm:nilled accessor as defined in [XQuery and XPath Data Model (XDM) 3.1] (see Section 4.8 nilled AccessorDM40).

Error Conditions

The following errors may be raised when $node is omitted:

Notes

If $node is not an element node, the function returns the empty sequence.

If $node is an untyped element node, the function returns false.

In practice, the function returns true only for an element node that has the attribute xsi:nil="true" and that is successfully validated against a schema that defines the element to be nillable; the detailed rules, however, are defined in [XQuery and XPath Data Model (XDM) 3.1].

2.1.3 fn:string

Summary

Returns the value of $value represented as an xs:string.

Signature
fn:string(
$value as item()? := .
) as xs:string
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

In the zero-argument version of the function, $value defaults to the context value. That is, calling fn:string() is equivalent to calling fn:string(.).

If $value is the empty sequence, the function returns the zero-length string.

If $value is a node, the function returns the string value of the node, as obtained using the dm:string-value accessor defined in [XQuery and XPath Data Model (XDM) 3.1] (see Section 4.12 string-value AccessorDM40).

If $value is an atomic item, the function returns the result of the expression $value cast as xs:string (see 20 Casting).

In all other cases, a dynamic error occurs (see below).

Error Conditions

The following errors may be raised when $value is omitted:

A type error is raised [err:FOTY0014] if $value is a function item (this includes maps and arrays).

Notes

Every node has a string value, even an element with element-only content (which has no typed value). Moreover, casting an atomic item to a string always succeeds. Functions, maps, and arrays have no string value, so these are the only arguments that satisfy the type signature but cause failure.

Examples
Variables
let $para := <para>There lived a <term author="Tolkien">hobbit</term>.</para>
Expression Result
string(23)
"23"
string(false())
"false"
string("Paris")
"Paris"
string((1, 2, 3))

Raises error XPTY0004.

string([ [ 1, 2 ], [ 3, 4 ] ])

Raises error FOTY0014.

string(abs#1)

Raises error FOTY0014.

string($para)
"There lived a hobbit."

2.1.4 fn:data

Summary

Returns the result of atomizing a sequence. This process flattens arrays, and replaces nodes by their typed values.

Signature
fn:data(
$input as item()* := .
) as xs:anyAtomicType*
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If the argument is omitted, it defaults to the context value (.).

The result of fn:data is the sequence of atomic items produced by applying the following rules to each item in $input:

  • If the item is an atomic item, it is appended to the result sequence.

  • If the item is a node, the typed value of the node is appended to the result sequence. The typed value is a sequence of zero or more atomic items: specifically, the result of the dm:typed-value accessor as defined in [XQuery and XPath Data Model (XDM) 3.1] (See Section 4.14 typed-value AccessorDM40).

  • If the item is an array, the result of applying fn:data to each member of the array, in order, is appended to the result sequence.

Error Conditions

A type error is raised [err:FOTY0012] if an item in the sequence $input is a node that does not have a typed value.

A type error is raised [err:FOTY0013] if an item in the sequence $input is a function item other than an array.

A type error is raised [err:XPDY0002]XP if $input is omitted and the context value is absentDM40.

Notes

The process of applying the fn:data function to a sequence is referred to as atomization. In many cases an explicit call on fn:data is not required, because atomization is invoked implicitly when a node or sequence of nodes is supplied in a context where an atomic item or sequence of atomic items is required.

The result of atomizing an empty sequence is an empty sequence.

The result of atomizing an empty array is an empty sequence.

Examples
Variables
let $para := <para>There lived a <term author="Tolkien">hobbit</term>.</para>
Expression Result
data(123)
123
data((123, 456))
123, 456
data([ [ 1, 2 ], [ 3, 4 ] ])
1, 2, 3, 4
data($para)
xs:untypedAtomic("There lived a hobbit.")
data($para/term/@author)
xs:untypedAtomic("Tolkien")
data(abs#1)

Raises error FOTY0013.

2.1.5 fn:base-uri

Summary

Returns the base URI of a node.

Signature
fn:base-uri(
$node as node()? := .
) as xs:anyURI?
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

The zero-argument version of the function returns the base URI of the context node: it is equivalent to calling fn:base-uri(.).

The single-argument version of the function behaves as follows:

  1. If $node is the empty sequence, the function returns the empty sequence.

  2. Otherwise, the function returns the value of the dm:base-uri accessor applied to the node $node. This accessor is defined, for each kind of node, in the XDM specification (See Section 4.2 base-uri AccessorDM40).

Note:

As explained in XDM, document, element and processing-instruction nodes have a base-uri property which may be empty. The base-uri property for all other node kinds is the empty sequence. The dm:base-uri accessor returns the base-uri property of a node if it exists and is non-empty; otherwise it returns the result of applying the dm:base-uri accessor to its parent, recursively. If the node does not have a parent, or if the recursive ascent up the ancestor chain encounters a parentless node whose base-uri property is empty, the empty sequence is returned. In the case of namespace nodes, however, the result is always an empty sequence — it does not depend on the base URI of the parent element.

See also fn:static-base-uri.

Error Conditions

The following errors may be raised when $node is omitted:

2.1.6 fn:document-uri

Changes in 4.0  

  1. The constraints on the result of the function have been relaxed.  [Issues 898 1161 PR 1265 2 July 2024]

Summary

Returns the URI of a resource where a document can be found, if available.

Signature
fn:document-uri(
$node as node()? := .
) as xs:anyURI?
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If the argument is omitted, it defaults to the context value (.).

If $node is the empty sequence, the function returns the empty sequence.

If $node is not a document node, the function returns the empty sequence.

Otherwise, the function returns the value of the document-uri accessor applied to $node, as defined in [XQuery and XPath Data Model (XDM) 3.1] (See Section 5.1.2 AccessorsDM40).

Error Conditions

The following errors may be raised when $node is omitted:

Notes

In the 3.1 version of this specification, it was mandated that two distinct documents could not have the same document-uri property: more specifically, it was guaranteed that for any document node $D, either document-uri($D) would be absent, or doc(document-uri($D)) would return $D.

For various reasons, this constraint has proved impractical. Different parts of an application may read the same external resource in different ways, for example with or without validation or whitespace stripping, leading to different document nodes derived from the same external resource having the same document-uri property. In addition, the specification explicitly allows implementations, at user request, to relax the requirements for determinism of resource access functions, which makes it possible for multiple calls of functions such as fn:doc, fn:json-doc, or fn:collection to return different results for the same supplied URI.

Although the uniqueness of the document-uri property is no longer an absolute constraint, it is still desirable that implementations should where possible respect the principle that URIs are usable as identifiers for resources.

In the case of a document node $D returned by the fn:doc function, it will generally be the case that fn:document-uri($D) returns a URI $U such that a call on fn:doc($U) in the same dynamic context will return the same document node $D. The URI $U will not necessarily be the same URI that was originally passed to the fn:doc function, since several URIs may identify the same resource.

It is recommended that implementations of fn:collection should ensure that any documents included in the returned collection, if they have a non-empty fn:document-uri property, should be such that a call on fn:doc supplying this URI returns the same document node.

2.2 Other functions on nodes

This section specifies further functions on nodes. Nodes are formally defined in Section 6 Nodes DM31.

Function Meaning
fn:name Returns the name of a node, as an xs:string that is either the zero-length string, or has the lexical form of an xs:QName.
fn:local-name Returns the local part of the name of $node as an xs:string that is either the zero-length string, or has the lexical form of an xs:NCName.
fn:namespace-uri Returns the namespace URI part of the name of $node, as an xs:anyURI value.
fn:lang This function tests whether the language of $node, or the context value if the second argument is omitted, as specified by xml:lang attributes is the same as, or is a sublanguage of, the language specified by $language.
fn:root Returns the root of the tree to which $node belongs. This will usually, but not necessarily, be a document node.
fn:path Returns a path expression that can be used to select the supplied node relative to the root of its containing document.
fn:has-children Returns true if the supplied node has one or more child nodes (of any kind).

2.2.1 fn:name

Summary

Returns the name of a node, as an xs:string that is either the zero-length string, or has the lexical form of an xs:QName.

Signature
fn:name(
$node as node()? := .
) as xs:string
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If the argument is omitted, it defaults to the context value (.).

If the argument is supplied and is the empty sequence, the function returns the zero-length string.

If the node identified by $node has no name (that is, if it is a document node, a comment, a text node, or a namespace node having no name), the function returns the zero-length string.

Otherwise, the function returns the value of the expression fn:string(fn:node-name($node)).

Error Conditions

The following errors may be raised when $node is omitted:

Notes

Because the result depends on the choice of namespace prefixes in the source document, it is not good practice to use the result of this function for anything other than display purposes. For example, the test name(.) = 'my:profile' will fail if the source document uses an unexpected namespace prefix. Such a test (assuming it relates to an element node) is better written as boolean(self::my:profile).

Examples
Variables
let $e := <doc>
  <p id="alpha" xml:id="beta">One</p>
  <p id="gamma" xmlns="http://example.com/ns">Two</p>
  <ex:p id="delta" xmlns:ex="http://example.com/ns">Three</ex:p>
  <?pi 3.14159?>
</doc>
Expression Result
name($e//*[@id = 'alpha'])
"p"
name($e//*[@id = 'gamma'])
"p"
name($e//*[@id = 'delta'])
"ex:p"
name($e//processing-instruction())
"pi"
name($e//*[@id = 'alpha']/text())
""
name($e//*[@id = 'alpha']/@id)
"id"
name($e//*[@id = 'alpha']/@xml:id)
"xml:id"

2.2.2 fn:local-name

Summary

Returns the local part of the name of $node as an xs:string that is either the zero-length string, or has the lexical form of an xs:NCName.

Signature
fn:local-name(
$node as node()? := .
) as xs:string
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If the argument is omitted, it defaults to the context value (.).

If the argument is supplied and is the empty sequence, the function returns the zero-length string.

If the node identified by $node has no name (that is, if it is a document node, a comment, a text node, or a namespace node having no name), the function returns the zero-length string.

Otherwise, the function returns the local part of the expanded-QName of the node identified by $node, as determined by the dm:node-name accessor defined in Section 4.10 node-name AccessorDM40. This will be an xs:string whose lexical form is an xs:NCName.

Error Conditions

The following errors may be raised when $node is omitted:

Examples
Variables
let $e := <doc>
  <p id="alpha" xml:id="beta">One</p>
  <p id="gamma" xmlns="http://example.com/ns">Two</p>
  <ex:p id="delta" xmlns:ex="http://example.com/ns">Three</ex:p>
  <?pi 3.14159?>
</doc>
Expression Result
local-name($e//*[@id = 'alpha'])
"p"
local-name($e//*[@id = 'gamma'])
"p"
local-name($e//*[@id = 'delta'])
"p"
local-name($e//processing-instruction())
"pi"
local-name($e//*[@id = 'alpha']/text())
""
local-name($e//*[@id = 'alpha']/@id)
"id"
local-name($e//*[@id = 'alpha']/@xml:id)
"id"

2.2.3 fn:namespace-uri

Summary

Returns the namespace URI part of the name of $node, as an xs:anyURI value.

Signature
fn:namespace-uri(
$node as node()? := .
) as xs:anyURI
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If the argument is omitted, it defaults to the context node (.).

If the node identified by $node is neither an element nor an attribute node, or if it is an element or attribute node whose expanded-QName (as determined by the dm:node-name accessor in the Section 4.10 node-name AccessorDM40) is in no namespace, then the function returns the zero-length xs:anyURI value.

Otherwise, the result will be the namespace URI part of the expanded-QName of the node identified by $node, as determined by the dm:node-name accessor defined in Section 4.10 node-name AccessorDM40), returned as an xs:anyURI value.

Error Conditions

The following errors may be raised when $node is omitted:

Examples
Variables
let $e := <doc>
  <p id="alpha" xml:id="beta">One</p>
  <p id="gamma" xmlns="http://example.com/ns">Two</p>
  <ex:p id="delta" xmlns:ex="http://example.com/ns">Three</ex:p>
  <?pi 3.14159?>
</doc>
Expression Result
namespace-uri($e//*[@id = 'alpha'])
""
namespace-uri($e//*[@id = 'gamma'])
"http://example.com/ns"
namespace-uri($e//*[@id = 'delta'])
"http://example.com/ns"
namespace-uri($e//processing-instruction())
""
namespace-uri($e//*[@id = 'alpha']/text())
""
namespace-uri($e//*[@id = 'alpha']/@id)
""
namespace-uri($e//*[@id = 'alpha']/@xml:id)
"http://www.w3.org/XML/1998/namespace"

2.2.4 fn:lang

Summary

This function tests whether the language of $node, or the context value if the second argument is omitted, as specified by xml:lang attributes is the same as, or is a sublanguage of, the language specified by $language.

Signature
fn:lang(
$language as xs:string?,
$node as node() := .
) as xs:boolean
Properties

The one-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The two-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

The behavior of the function if the second argument is omitted is exactly the same as if the context value (.) had been passed as the second argument.

The language of the argument $node, or the context value if the second argument is omitted, is determined by the value of the xml:lang attribute on the node, or, if the node has no such attribute, by the value of the xml:lang attribute on the nearest ancestor of the node that has an xml:lang attribute. If there is no such ancestor, then the function returns false.

If $language is the empty sequence it is interpreted as the zero-length string.

The relevant xml:lang attribute is determined by the value of the XPath expression:

(ancestor-or-self::*/@xml:lang)[last()]

If this expression returns an empty sequence, the function returns false.

Otherwise, the function returns true if and only if, based on a caseless default match as specified in section 3.13 of [The Unicode Standard], either:

  1. $language is equal to the string-value of the relevant xml:lang attribute, or

  2. $language is equal to some substring of the string-value of the relevant xml:lang attribute that starts at the start of the string-value and ends immediately before a hyphen, - (HYPHEN-MINUS, #x002D).

Error Conditions

The following errors may be raised when $node is omitted:

Examples

The expression fn:lang("en") would return true if the context node were any of the following four elements:

  • <para xml:lang="en"/>

  • <div xml:lang="en"><para>And now, and forever!</para></div>

  • <para xml:lang="EN"/>

  • <para xml:lang="en-us"/>

The expression fn:lang("fr") would return false if the context node were <para xml:lang="EN"/>

2.2.5 fn:root

Summary

Returns the root of the tree to which $node belongs. This will usually, but not necessarily, be a document node.

Signature
fn:root(
$node as node()? := .
) as node()?
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If the function is called without an argument, the context value (.) is used as the default argument.

The function returns the value of the expression ($arg/ancestor-or-self::node())[1].

Error Conditions

The following errors may be raised when $node is omitted:

Examples

These examples use some variables which could be defined in [XQuery 4.1: An XML Query Language] as:

let $i := <tool>wrench</tool>
let $o := <order>{ $i }<quantity>5</quantity></order>
let $odoc := document { $o }
let $newi := $o/tool

Or they could be defined in [XSL Transformations (XSLT) Version 4.0] as:

<xsl:variable name="i" as="element()">
  <tool>wrench</tool>
</xsl:variable>

<xsl:variable name="o" as="element()">
  <order>
    <xsl:copy-of select="$i"/>
    <quantity>5</quantity>
  </order>
</xsl:variable>

<xsl:variable name="odoc">
  <xsl:copy-of select="$o"/>
</xsl:variable>

<xsl:variable name="newi" select="$o/tool"/>

root($i) returns the element node $i

root($o/quantity) returns the element node $o

root($odoc//quantity) returns the document node $odoc

root($newi) returns the element node $o

The final three examples could be made type-safe by wrapping their operands with exactly-one().

2.2.6 fn:path

Summary

Returns a path expression that can be used to select the supplied node relative to the root of its containing document.

Signature
fn:path(
$node as node()? := .
) as xs:string?
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

The behavior of the function if the argument is omitted is exactly the same as if the context value (.) had been passed as the argument.

If $node is the empty sequence, the function returns the empty sequence.

If $node is a document node, the function returns the string "/".

Otherwise, the function returns a string that consists of a sequence of steps, one for each ancestor-or-self of $node other than the root node. This string is prefixed by "Q{http://www.w3.org/2005/xpath-functions}root()" if the root node is not a document node. Each step consists of the character "/" followed by a string whose form depends on the kind of node selected by that step, as follows:

  1. For an element node, Q{uri}local[position], where uri is the namespace URI of the node name or the empty string if the node is in no namespace, local is the local part of the node name, and position is an integer representing the position of the selected node among its like-named siblings.

  2. For an attribute node:

    1. if the node is in no namespace, @local, where local is the local part of the node name

    2. otherwise, @Q{uri}local, where uri is the namespace URI of the node name, and local is the local part of the node name

  3. For a text node: text()[position] where position is an integer representing the position of the selected node among its text node siblings

  4. For a comment node: comment()[position] where position is an integer representing the position of the selected node among its comment node siblings

  5. For a processing-instruction node: processing-instruction(local)[position] where local is the name of the processing instruction node and position is an integer representing the position of the selected node among its like-named processing-instruction node siblings

  6. For a namespace node:

    1. If the namespace node has a name: namespace::prefix, where prefix is the local part of the name of the namespace node (which represents the namespace prefix).

    2. If the namespace node has no name (that is, it represents the default namespace): namespace::*[Q{http://www.w3.org/2005/xpath-functions}local-name() = ""]

Error Conditions

The following errors may be raised when $node is omitted:

Examples
Variables
let $e := document {            
  <p xmlns="http://example.com/one" xml:lang="de" author="Friedrich von Schiller">
Freude, schöner Götterfunken,<br/>
Tochter aus Elysium,<br/>
Wir betreten feuertrunken,<br/>
Himmlische, dein Heiligtum.
</p>}
let $emp := 
  <employee xml:id="ID21256">
     <empnr>E21256</empnr>
     <first>John</first>
     <last>Brown</last>
  </employee>
Expression:

path($e)

Result:
'/'
Expression:

path($e/*:p)

Result:
'/Q{http://example.com/one}p[1]'
Expression:

path($e/*:p/@xml:lang)

Result:
'/Q{http://example.com/one}p[1]/@Q{http://www.w3.org/XML/1998/namespace}lang'
Expression:

path($e/*:p/@author)

Result:
'/Q{http://example.com/one}p[1]/@author'
Expression:

path($e/*:p/*:br[2])

Result:
'/Q{http://example.com/one}p[1]/Q{http://example.com/one}br[2]'
Expression:
path(
  $e//text()[
    starts-with(normalize-space(), 'Tochter')
  ]
)
Result:
'/Q{http://example.com/one}p[1]/text()[2]'
Expression:

path($emp)

Result:
'Q{http://www.w3.org/2005/xpath-functions}root()'
Expression:

path($emp/@xml:id)

Result:
'Q{http://www.w3.org/2005/xpath-functions}root()/@Q{http://www.w3.org/XML/1998/namespace}id'
Expression:

path($emp/empnr)

Result:
'Q{http://www.w3.org/2005/xpath-functions}root()/Q{}empnr[1]'

2.2.7 fn:has-children

Summary

Returns true if the supplied node has one or more child nodes (of any kind).

Signature
fn:has-children(
$node as node()? := .
) as xs:boolean
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If the argument is omitted, it defaults to the context value (.).

Provided that the supplied argument $node matches the expected type node()?, the result of the function call fn:has-children($node) is defined to be the same as the result of the expression fn:exists($node/child::node()).

Error Conditions

The following errors may be raised when $node is omitted:

Notes

If $node is an empty sequence the result is false.

The motivation for this function is to support streamed evaluation. According to the streaming rules in [XSL Transformations (XSLT) Version 4.0], the following construct is not streamable:

<xsl:if test="exists(row)">
  <ulist>
    <xsl:for-each select="row">
      <item><xsl:value-of select="."/></item>
    </xsl:for-each>
  </ulist>
</xsl:if>

This is because it makes two downward selections to read the child row elements. The use of fn:has-children in the xsl:if conditional is intended to circumvent this restriction.

Although the function was introduced to support streaming use cases, it has general utility as a convenience function.

Examples
Variables
let $e := <doc>
  <p id="alpha">One</p>
  <p/>
  <p>Three</p>
  <?pi 3.14159?>
</doc>
Expression Result
has-children($e)
true()
has-children($e//p[1])
true()
has-children($e//p[2])
false()
has-children($e//p[3])
true()
has-children($e//processing-instruction())
false()
has-children($e//p[1]/text())
false()
has-children($e//p[1]/@id)
false()

2.3 Functions on sequences of nodes

This section specifies functions on sequences of nodes.

Function Meaning
fn:distinct-ordered-nodes Removes duplicate nodes and sorts the input into document order.
fn:innermost Returns every node within the input sequence that is not an ancestor of another member of the input sequence; the nodes are returned in document order with duplicates eliminated.
fn:outermost Returns every node within the input sequence that has no ancestor that is itself a member of the input sequence; the nodes are returned in document order with duplicates eliminated.

2.3.1 fn:distinct-ordered-nodes

Changes in 4.0  

  1. New in 4.0  [Issue 1189 PR 1191 14 May 2024]

Summary

Removes duplicate nodes and sorts the input into document order.

Signature
fn:distinct-ordered-nodes(
$nodes as node()*
) as node()*
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

Any duplicate nodes in the input (based on node identity) are discarded. The remaining nodes are returned in document orderXP40.

Notes

Document order is ·implementation-dependent· (but stable) for nodes in different documents. If some node in document A precedes some node in document B, then every node in A precedes every node in B.

Examples
Expression:
let $x := parse-xml('<doc><a/><b/><c/><d/><c/><e/></doc>')
return distinct-ordered-nodes(($x//c, $x//b, $x//a, $x//b)) ! name()
Result:
"a", "b", "c", "c"

(The two $x//b expressions select the same node; one of these is eliminated as a duplicate. The $x//c expression selects two nodes that have distinct identity, so both are retained.)

2.3.2 fn:innermost

Summary

Returns every node within the input sequence that is not an ancestor of another member of the input sequence; the nodes are returned in document order with duplicates eliminated.

Signature
fn:innermost(
$nodes as node()*
) as node()*
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

The effect of the function call fn:innermost($nodes) is defined to be equivalent to the result of the expression:

$nodes except $nodes/ancestor::node()

That is, the function takes as input a sequence of nodes, and returns every node within the sequence that is not an ancestor of another node within the sequence; the nodes are returned in document order with duplicates eliminated.

Examples

If the source document contains nested sections represented by div elements, the expression innermost(//div) returns those div elements that do not contain further div elements.

2.3.3 fn:outermost

Summary

Returns every node within the input sequence that has no ancestor that is itself a member of the input sequence; the nodes are returned in document order with duplicates eliminated.

Signature
fn:outermost(
$nodes as node()*
) as node()*
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

The effect of the function call fn:outermost($nodes) is defined to be equivalent to the result of the expression:

$nodes[not(ancestor::node() intersect $nodes)]/.

That is, the function takes as input a sequence of nodes, and returns every node within the sequence that does not have another node within the sequence as an ancestor; the nodes are returned in document order with duplicates eliminated.

Notes

The formulation $nodes except $nodes/descendant::node() might appear to be simpler, but does not correctly account for attribute nodes, as these are not descendants of their parent element.

The motivation for the function was based on XSLT streaming use cases. There are cases where the [XSL Transformations (XSLT) Version 4.0] streaming rules allow the construct outermost(//section) but do not allow //section; the function can therefore be useful in cases where it is known that sections will not be nested, as well as cases where the application actually wishes to process all sections except those that are nested within another.

Examples

If the source document contains nested sections represented by div elements, the expression outermost(//div) returns those div elements that are not contained within further div elements.

3 Errors and diagnostics

3.1 Raising errors

In this document, as well as in [XQuery 4.1: An XML Query Language] and [XML Path Language (XPath) 4.0], the phrase “an error is raised” is used. Raising an error is equivalent to calling the fn:error function defined in this section with the provided error code. Except where otherwise specified, errors defined in this specification are dynamic errors. Some errors, however, are classified as type errors. Type errors are typically used where the presence of the error can be inferred from knowledge of the type of the actual arguments to a function, for example with a call such as fn:string(fn:abs#1). Host languages may allow type errors to be reported statically if they are discovered during static analysis.

When function specifications indicate that an error is to be raised, the notation “[error code ]” is used to specify an error code. Each error defined in this document is identified by an xs:QName that is in the http://www.w3.org/2005/xqt-errors namespace, represented in this document by the err prefix. It is this xs:QName that is actually passed as an argument to the fn:error function. Calling this function raises an error. For a more detailed treatment of error handing, see Section 2.3.3 Handling Dynamic Errors XP31.

The fn:error function is a general function that may be called as above but may also be called from [XQuery 4.1: An XML Query Language] or [XML Path Language (XPath) 4.0] applications with, for example, an xs:QName argument.

3.1.1 fn:error

Changes in 4.0  

  1. All three arguments are now optional, and each argument can be set to an empty sequence. Previously if $description was supplied, it could not be empty.  [Issue 895 PR 901 16 December 2023]

Summary

Calling the fn:error function raises an application-defined error.

Signature
fn:error(
$code as xs:QName? := (),
$description as xs:string? := (),
$value as item()* := .
) as item()*
Properties

This function is ·nondeterministic·, ·context-independent·, and ·focus-independent·.

Rules

This function never returns a value. Instead it always raises an error. The effect of the error is identical to the effect of dynamic errors raised implicitly, for example when an incorrect argument is supplied to a function.

The parameters to the fn:error function supply information that is associated with the error condition and that is made available to a caller that asks for information about the error. The error may be caught either by the host language (using a try/catch construct in XSLT or XQuery, for example), or by the calling application or external processing environment. The way in which error information is returned to the external processing environment is ·implementation-dependent·.

There are three pieces of information that may be associated with an error.

  • The $code is an error code that distinguishes this error from others. It is an xs:QName; the namespace URI conventionally identifies the component, subsystem, or authority responsible for defining the meaning of the error code, while the local part identifies the specific error condition. The namespace URI http://www.w3.org/2005/xqt-errors is used for errors defined in this specification; other namespace URIs may be used for errors defined by the application.

    If the external processing environment expects the error code to be returned as a URI or a string rather than as an xs:QName, then an error code with namespace URI NS and local part LP will be returned in the form NS#LP. The namespace URI part of the error code should therefore not include a fragment identifier.

    If no value is supplied for the $code argument, or if the value supplied is an empty sequence, the effective value of the error code is fn:QName('http://www.w3.org/2005/xqt-errors', 'err:FOER0000').

  • The $description is a natural-language description of the error condition.

    If no value is supplied for the $description argument, or if the value supplied is an empty sequence, then the effective value of the description is ·implementation-dependent·.

  • The $value is an arbitrary value used to convey additional information about the error, and may be used in any way the application chooses.

    If no value is supplied for the $value argument or if the value supplied is an empty sequence, then the effective value of the error object is ·implementation-dependent·.

Error Conditions

This function always raises a dynamic error. By default, it raises [err:FOER0000]

Notes

The value of the $description parameter may need to be localized.

Since the function never returns a value, the declared return type of item()* is a convenient fiction. It is relevant insofar as a function item such as error#1 may (as a consequence of function coercion) be supplied in contexts where a function with a more specific return type is required.

Any QName may be used as an error code; there are no reserved names or namespaces. The error is always classified as a dynamic error, even if the error code used is one that is normally used for static errors or type errors.

Examples
Expression:

error()

Result:

Raises error FOER0000.

(This returns the URI http://www.w3.org/2005/xqt-errors#FOER0000 (or the corresponding xs:QName) to the external processing environment, unless the error is caught using a try/catch construct in the host language.)

Expression:
error(
  QName('http://www.example.com/HR', 'myerr:toohighsal'),
  'Salary is too high'
)
Result:

Raises error myerr:toohighsal.

(This returns http://www.example.com/HR#toohighsal and the xs:string "Salary is too high" (or the corresponding xs:QName) to the external processing environment, unless the error is caught using a try/catch construct in the host language.)

3.2 Diagnostic tracing

3.2.1 fn:trace

Changes in 4.0  

  1. The $label argument can now be set to an empty sequence. Previously if $label was supplied, it could not be empty.  [Issue 895 PR 901 16 December 2023]

Summary

Provides an execution trace intended to be used in debugging queries.

Signature
fn:trace(
$input as item()*,
$label as xs:string? := ()
) as item()*
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

The function returns $input, unchanged.

In addition, the values of $input, typically serialized and converted to an xs:string, and $label (if supplied and non-empty) may be output to an ·implementation-defined· destination.

Any serialization of the implementation's trace output must not raise an error. This can be achieved (for example) by using a serialization method that can handle arbitrary input, such as the adaptive output method (see Section 10 Adaptive Output Method SER31).

The format of the trace output and its order are ·implementation-dependent·. Therefore, the order in which the output appears is not predictable. This also means that if dynamic errors occur (whether or not they are caught using try/catch), it may be unpredictable whether any output is reported before the error occurs.

Notes

If the trace information is unrelated to a specific value, fn:message can be used instead.

Examples

Consider a situation in which a user wants to investigate the actual value passed to a function. Assume that in a particular execution, $v is an xs:decimal with value 124.84. Writing fn:trace($v, 'the value of $v is:') will return $v. The processor may output "124.84" and "the value of $v is:" to an ·implementation-defined· destination.

The following two XPath expressions are identical, but only the second provides trace feedback to the user:

  • //book[xs:decimal(@price) gt 100]

  • //book[xs:decimal(@price) gt 100] => trace('books more expensive than €100:')

3.2.2 fn:message

Changes in 4.0  

  1. New in 4.0  [Issues 574 651 PRs 629 803 7 November 2023]

Summary

Outputs trace information and discards the result.

Signature
fn:message(
$input as item()*,
$label as xs:string? := ()
) as empty-sequence()
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

Similar to fn:trace, the values of $input, typically serialized and converted to an xs:string, and $label (if supplied and non-empty) may be output to an ·implementation-defined· destination.

In contrast to fn:trace, the function returns an empty sequence.

Any serialization of the implementation’s log output must not raise an error. This can e.g. be achieved by using a serialization method that can handle arbitrary input, such as the Section 10 Adaptive Output Method SER31.

The format of the log output and its order are ·implementation-dependent·. Therefore, the order in which the output appears is not predictable. This also means that if dynamic errors occur (whether or not they are caught using try/catch), it may be unpredictable whether any output is logged before the error occurs.

Notes

The function can be used for debugging. It can also be helpful in productive environments, e.g. to store dynamic input and evaluations to log files.

Examples

The following two XPath expressions are identical, but only the second logs any feedback:

  • //book[xs:decimal(@price) lt 1000]

  • //book[if (xs:decimal(@price) lt 1000) then true() else message(@price, @title || ' is unexpectedly expensive: ')]

3.2.3 fn:stack-trace

Changes in 4.0  

  1. New in 4.0  [ PR 1074 26 March 2024]

Summary

Returns implementation-dependent information about the current state of execution.

Signature
fn:stack-trace() as xs:string
Properties

This function is ·nondeterministic·, ·context-independent·, and ·focus-independent·.

Rules

The result of the function is an ·implementation-dependent· string containing diagnostic information about the current state of execution.

The function is nondeterministic: multiple calls will typically produce different results.

Notes

The function will typically be called to assist in diagnosing dynamic errors.

4 Functions and operators on numerics

This section specifies arithmetic operators on the numeric datatypes defined in [XML Schema Part 2: Datatypes Second Edition].

4.1 Numeric types

The operators described in this section are defined on the following atomic types.

    • decimal

      • integer

    • double

    • float

Legend:

  • Supertype

    • subtype

  • Built-in atomic types

They also apply to types derived by restriction from the above types.

The type xs:numeric is defined as a union type whose member types are (in order) xs:double, xs:float, and xs:decimal. This type is implicitly imported into the static context, so it can also be used in defining the signature of user-written functions. Apart from the fact that it is implicitly imported, it behaves exactly like a user-defined type with the same definition. This means, for example:

  • If the expected type of a function parameter is given as xs:numeric, the actual value supplied can be an instance of any of these three types, or any type derived from these three by restriction (this includes the built-in type xs:integer, which is derived from xs:decimal).

  • If the expected type of a function parameter is given as xs:numeric, and the actual value supplied is xs:untypedAtomic (or a node whose atomized value is xs:untypedAtomic), then it will be cast to the union type xs:numeric using the rules in 20.3.7 Casting to union types. Because the lexical space of xs:double subsumes the lexical space of the other member types, and xs:double is listed first, the effect is that if the untyped atomic item is in the lexical space of xs:double, it will be converted to an xs:double, and if not, a dynamic error occurs.

  • When the return type of a function is given as xs:numeric, the actual value returned will be an instance of one of the three member types (and perhaps also of types derived from these by restriction). The rules for the particular function will specify how the type of the result depends on the values supplied as arguments. In many cases, for the functions in this specification, the result is defined to be the same type as the first argument.

Note:

This specification uses [IEEE 754-2019] arithmetic for xs:float and xs:double values. One consequence of this is that some operations result in the value NaN (not a number), which has the unusual property that it is not equal to itself. Another consequence is that some operations return the value negative zero. This differs from [XML Schema Part 2: Datatypes Second Edition], which defines NaN as being equal to itself and defines only a single zero in the value space. The text accompanying several functions defines behavior for both positive and negative zero inputs and outputs in the interest of alignment with [IEEE 754-2019]. A conformant implementation must respect these semantics. In consequence, the expression -0.0e0 (which is actually a unary minus operator applied to an xs:double value) will always return negative zero: see 4.2.8 op:numeric-unary-minus. As a concession to implementations that rely on implementations of XSD 1.0, however, when casting from string to double the lexical form -0 may be converted to positive zero, though negative zero is recommended.

XML Schema 1.1 introduces support for positive and negative zero as distinct values, and also uses the [IEEE 754-2019] semantics for comparisons involving NaN.

4.2 Arithmetic operators on numeric values

The following functions define the semantics of arithmetic operators defined in [XQuery 4.1: An XML Query Language] and [XML Path Language (XPath) 4.0] on these numeric types.

Operator Meaning
op:numeric-add Addition
op:numeric-subtract Subtraction
op:numeric-multiply Multiplication
op:numeric-divide Division
op:numeric-integer-divide Integer division
op:numeric-mod Modulus
op:numeric-unary-plus Unary plus
op:numeric-unary-minus Unary minus (negation)

The parameters and return types for the above operators are in most cases declared to be of type xs:numeric, which permits the basic numeric types: xs:integer, xs:decimal, xs:float and xs:double, and types derived from them. In general the two-argument functions require that both arguments are of the same primitive type, and they return a value of this same type. The exceptions are op:numeric-divide, which returns an xs:decimal if called with two xs:integer operands, and op:numeric-integer-divide which always returns an xs:integer.

If the two operands of an arithmetic expression are not of the same type, subtype substitution and numeric type promotion are used to obtain two operands of the same type. Section B.1 Type Promotion XP31 and Section B.2 Operator Mapping XP31 describe the semantics of these operations in detail.

The result type of operations depends on their argument datatypes and is defined in the following table:

Operator Returns
op:operation(xs:integer, xs:integer) xs:integer (except for op:numeric-divide(integer, integer), which returns xs:decimal)
op:operation(xs:decimal, xs:decimal) xs:decimal
op:operation(xs:float, xs:float) xs:float
op:operation(xs:double, xs:double) xs:double
op:operation(xs:integer) xs:integer
op:operation(xs:decimal) xs:decimal
op:operation(xs:float) xs:float
op:operation(xs:double) xs:double

These rules define any operation on any pair of arithmetic types. Consider the following example:

op:operation(xs:int, xs:double) => op:operation(xs:double, xs:double)

For this operation, xs:int must be converted to xs:double. This can be done, since by the rules above: xs:int can be substituted for xs:integer, xs:integer can be substituted for xs:decimal, xs:decimal can be promoted to xs:double. As far as possible, the promotions should be done in a single step. Specifically, when an xs:decimal is promoted to an xs:double, it should not be converted to an xs:float and then to xs:double, as this risks loss of precision.

As another example, a user may define height as a derived type of xs:integer with a minimum value of 20 and a maximum value of 100. They may then derive fenceHeight using an enumeration to restrict the permitted set of values to, say, 36, 48 and 60.

op:operation(fenceHeight, xs:integer) => op:operation(xs:integer, xs:integer)

fenceHeight can be substituted for its base type height and height can be substituted for its base type xs:integer.

The basic rules for addition, subtraction, and multiplication of ordinary numbers are not set out in this specification; they are taken as given. In the case of xs:double and xs:float the rules are as defined in [IEEE 754-2019]. The rules for handling division and modulus operations, as well as the rules for handling special values such as infinity and NaN, and exception conditions such as overflow and underflow, are described more explicitly since they are not necessarily obvious.

On overflow and underflow situations during arithmetic operations, conforming implementations must behave as follows:

  • For xs:float and xs:double operations, overflow behavior must be conformant with [IEEE 754-2019]. This specification allows the following options:

    • Raising a dynamic error [err:FOAR0002] via an overflow trap.

    • Returning INF or -INF.

    • Returning the largest (positive or negative) non-infinite number.

  • For xs:float and xs:double operations, underflow behavior must be conformant with [IEEE 754-2019]. This specification allows the following options:

    • Raising a dynamic error [err:FOAR0002] via an underflow trap.

    • Returning 0.0E0 or +/- 2**Emin or a denormalized value; where Emin is the smallest possible xs:float or xs:double exponent.

  • For xs:decimal operations, overflow behavior must raise a dynamic error [err:FOAR0002]. On underflow, 0.0 must be returned.

  • For xs:integer operations, implementations that support limited-precision integer operations must select from the following options:

    • They may choose to always raise a dynamic error [err:FOAR0002].

    • They may provide an ·implementation-defined· mechanism that allows users to choose between raising an error and returning a result that is modulo the largest representable integer value. See [ISO 10967].

The functions op:numeric-add, op:numeric-subtract, op:numeric-multiply, op:numeric-divide, op:numeric-integer-divide and op:numeric-mod are each defined for pairs of numeric operands, each of which has the same type:xs:integer, xs:decimal, xs:float, or xs:double. The functions op:numeric-unary-plus and op:numeric-unary-minus are defined for a single operand whose type is one of those same numeric types.

For xs:float and xs:double arguments, if either argument is NaN, the result is NaN.

For xs:decimal values, let N be the number of digits of precision supported by the implementation, and let M (M <= N) be the minimum limit on the number of digits required for conformance (18 digits for XSD 1.0, 16 digits for XSD 1.1). Then for addition, subtraction, and multiplication operations, the returned result should be accurate to N digits of precision, and for division and modulus operations, the returned result should be accurate to at least M digits of precision. The actual precision is ·implementation-defined·. If the number of digits in the mathematical result exceeds the number of digits that the implementation retains for that operation, the result is truncated or rounded in an ·implementation-defined· manner.

Note:

This specification does not determine whether xs:decimal operations are fixed point or floating point. In an implementation using floating point it is possible for very simple operations to require more digits of precision than are available; for example, adding 1e100 to 1e-100 requires 200 digits of precision for an accurate representation of the result.

The [IEEE 754-2019] specification also describes handling of two exception conditions called divideByZero and invalidOperation. The IEEE divideByZero exception is raised not only by a direct attempt to divide by zero, but also by operations such as log(0). The IEEE invalidOperation exception is raised by attempts to call a function with an argument that is outside the function’s domain (for example, sqrt(-1) or log(-1)). Although IEEE defines these as exceptions, it also defines “default non-stop exception handling” in which the operation returns a defined result, typically positive or negative infinity, or NaN. With this function library, these IEEE exceptions do not cause a dynamic error at the application level; rather they result in the relevant function or operator returning the defined non-error result. The underlying IEEE exception may be notified to the application or to the user by some ·implementation-defined· warning condition, but the observable effect on an application using the functions and operators defined in this specification is simply to return the defined result (typically -INF, +INF, or NaN) with no error.

The [IEEE 754-2019] specification distinguishes two NaN values: a quiet NaN and a signaling NaN. These two values are not distinguishable in the XDM model: the value spaces of xs:float and xs:double each include only a single NaN value. This does not prevent the implementation distinguishing them internally, and triggering different ·implementation-defined· warning conditions, but such distinctions do not affect the observable behavior of an application using the functions and operators defined in this specification.

4.2.1 op:numeric-add

Summary

Returns the arithmetic sum of its operands: ($arg1 + $arg2).

Operator Mapping

Defines the semantics of the + operator when applied to two numeric values

Signature
op:numeric-add(
$arg1 as xs:numeric,
$arg2 as xs:numeric
) as xs:numeric
Rules

General rules: see 4.2 Arithmetic operators on numeric values.

Notes

For xs:float or xs:double values, if one of the operands is a zero or a finite number and the other is INF or -INF, INF or -INF is returned. If both operands are INF, INF is returned. If both operands are -INF, -INF is returned. If one of the operands is INF and the other is -INF, NaN is returned.

4.2.2 op:numeric-subtract

Summary

Returns the arithmetic difference of its operands: ($arg1 - $arg2).

Operator Mapping

Defines the semantics of the - operator when applied to two numeric values.

Signature
op:numeric-subtract(
$arg1 as xs:numeric,
$arg2 as xs:numeric
) as xs:numeric
Rules

General rules: see 4.2 Arithmetic operators on numeric values.

Notes

For xs:float or xs:double values, if one of the operands is a zero or a finite number and the other is INF or -INF, an infinity of the appropriate sign is returned. If both operands are INF or -INF, NaN is returned. If one of the operands is INF and the other is -INF, an infinity of the appropriate sign is returned.

4.2.3 op:numeric-multiply

Summary

Returns the arithmetic product of its operands: ($arg1 * $arg2).

Operator Mapping

Defines the semantics of the * operator when applied to two numeric values.

Signature
op:numeric-multiply(
$arg1 as xs:numeric,
$arg2 as xs:numeric
) as xs:numeric
Rules

General rules: see 4.2 Arithmetic operators on numeric values.

Notes

For xs:float or xs:double values, if one of the operands is a zero and the other is an infinity, NaN is returned. If one of the operands is a non-zero number and the other is an infinity, an infinity with the appropriate sign is returned.

4.2.4 op:numeric-divide

Summary

Returns the arithmetic quotient of its operands: ($arg1 div $arg2).

Operator Mapping

Defines the semantics of the div operator when applied to two numeric values.

Signature
op:numeric-divide(
$arg1 as xs:numeric,
$arg2 as xs:numeric
) as xs:numeric
Rules

General rules: see 4.2 Arithmetic operators on numeric values.

As a special case, if the types of both $arg1 and $arg2 are xs:integer, then the return type is xs:decimal.

Error Conditions

A dynamic error is raised [err:FOAR0001] for xs:decimal and xs:integer operands, if the divisor is (positive or negative) zero.

Notes

For xs:float and xs:double operands, floating point division is performed as specified in [IEEE 754-2019]. A positive number divided by positive zero returns INF. A negative number divided by positive zero returns -INF. Division by negative zero returns -INF and INF, respectively. Positive or negative zero divided by positive or negative zero returns NaN. Also, INF or -INF divided by INF or -INF returns NaN.

4.2.5 op:numeric-integer-divide

Summary

Performs an integer division.

Operator Mapping

Defines the semantics of the idiv operator when applied to two numeric values.

Signature
op:numeric-integer-divide(
$arg1 as xs:numeric,
$arg2 as xs:numeric
) as xs:integer
Rules

General rules: see 4.2 Arithmetic operators on numeric values.

If $arg2 is INF or -INF, and $arg1 is not INF or -INF, then the result is zero.

Otherwise, subject to limits of precision and overflow/underflow conditions, the result is the largest (furthest from zero) xs:integer value $N such that the following expression is true:

abs($N * $arg2) le abs($arg1) and
compare($N * $arg2, 0) eq compare($arg1, 0).

Note:

The second term in this condition ensures that the result has the correct sign.

The implementation may adopt a different algorithm provided that it is equivalent to this formulation in all cases where ·implementation-dependent· or ·implementation-defined· behavior does not affect the outcome, for example, the implementation-defined precision of the result of xs:decimal division.

Error Conditions

A dynamic error is raised [err:FOAR0001] if the divisor is (positive or negative) zero.

A dynamic error is raised [err:FOAR0002] if either operand is NaN or if $arg1 is INF or -INF.

Notes

Except in situations involving errors, loss of precision, or overflow/underflow, the result of $a idiv $b is the same as ($a div $b) cast as xs:integer.

The semantics of this function are different from integer division as defined in programming languages such as Java and C++.

Examples
Expression Result
op:numeric-integer-divide(10, 3)
3
op:numeric-integer-divide(3, -2)
-1
op:numeric-integer-divide(-3, 2)
-1
op:numeric-integer-divide(-3, -2)
1
op:numeric-integer-divide(9.0, 3)
3
op:numeric-integer-divide(-3.5, 3)
-1
op:numeric-integer-divide(3.0, 4)
0
op:numeric-integer-divide(3.1E1, 6)
5
op:numeric-integer-divide(3.1E1, 7)
4

4.2.6 op:numeric-mod

Summary

Returns the remainder resulting from dividing $arg1, the dividend, by $arg2, the divisor.

Operator Mapping

Defines the semantics of the mod operator when applied to two numeric values.

Signature
op:numeric-mod(
$arg1 as xs:numeric,
$arg2 as xs:numeric
) as xs:numeric
Rules

General rules: see 4.2 Arithmetic operators on numeric values.

The operation a mod b for operands that are xs:integer or xs:decimal, or types derived from them, produces a result such that (a idiv b) * b + (a mod b) is equal to a and the magnitude of the result is always less than the magnitude of b. This identity holds even in the special case that the dividend is the negative integer of largest possible magnitude for its type and the divisor is -1 (the remainder is 0). It follows from this rule that the sign of the result is the sign of the dividend.

For xs:float and xs:double operands the following rules apply:

  • If either operand is NaN, the result is NaN.

  • If the dividend is positive or negative infinity, or the divisor is positive or negative zero (0), or both, the result is NaN.

  • If the dividend is finite and the divisor is an infinity, the result equals the dividend.

  • If the dividend is positive or negative zero and the divisor is finite, the result is the same as the dividend.

  • In the remaining cases, where neither positive or negative infinity, nor positive or negative zero, nor NaN is involved, the result obeys (a idiv b)*b+(a mod b) = a. Division is truncating division, analogous to integer division, not [IEEE 754-2019] rounding division i.e. additional digits are truncated, not rounded to the required precision.

Error Conditions

A dynamic error is raised [err:FOAR0001] for xs:integer and xs:decimal operands, if $arg2 is zero.

Examples
Expression Result
op:numeric-mod(10, 3)
1
op:numeric-mod(6, -2)
0
op:numeric-mod(4.5, 1.2)
0.9
op:numeric-mod(1.23E2, 0.6E1)
3.0E0

4.2.7 op:numeric-unary-plus

Summary

Returns its operand with the sign unchanged: (+ $arg).

Operator Mapping

Defines the semantics of the unary + operator applied to a numeric value.

Signature
op:numeric-unary-plus(
$arg as xs:numeric
) as xs:numeric
Rules

General rules: see 4.2 Arithmetic operators on numeric values.

The returned value is equal to $arg, and is an instance of xs:integer, xs:decimal, xs:double, or xs:float depending on the type of $arg.

Notes

Because coercion rules are applied in the normal way, the unary + operator can be used to force conversion of an untyped node to a number: the result of +@price is the same as xs:double(@price) if the type of @price is xs:untypedAtomic.

4.2.8 op:numeric-unary-minus

Summary

Returns its operand with the sign reversed: -$arg.

Operator Mapping

Defines the semantics of the unary - operator when applied to a numeric value.

Signature
op:numeric-unary-minus(
$arg as xs:numeric
) as xs:numeric
Rules

General rules: see 4.2 Arithmetic operators on numeric values.

The returned value is an instance of xs:integer, xs:decimal, xs:double, or xs:float depending on the type of $arg.

For xs:integer and xs:decimal arguments, 0 and 0.0 return 0 and 0.0, respectively. For xs:float and xs:double arguments, NaN returns NaN, 0.0E0 returns -0.0E0 and vice versa. INF returns -INF. -INF returns INF.

4.3 Comparison operators on numeric values

Changes in 4.0  

  1. Deleted an inaccurate statement concerning the behavior of NaN.  [Issue 473 PR 482]

The six value comparison operators eq, ne, lt, le, gt, and ge are defined in terms of two underlying functions: op:numeric-equal and op:numeric-less-than. These functions are defined to operate on values of the same type.

If the arguments are of different types, one argument is promoted to the type of the other as described above in 4.2 Arithmetic operators on numeric values. Each comparison operator returns a boolean value.

Note:

For a description of the different ways of comparing numeric values using the operators = and eq and the functions fn:deep-equal and fn:atomic-equal, see Section H Atomic Comparisons: An Overview (Non-Normative)XP40.

Note:

See also the function fn:compare.

Function Meaning
op:numeric-equal Returns true if and only if the value of $arg1 is equal to the value of $arg2.
op:numeric-less-than Returns true if and only if $arg1 is numerically less than $arg2.

4.3.1 op:numeric-equal

Summary

Returns true if and only if the value of $arg1 is equal to the value of $arg2.

Operator Mapping

Defines the semantics of the eq operator when applied to two numeric values, and is also used in defining the semantics of ne, le and ge.

Signature
op:numeric-equal(
$arg1 as xs:numeric,
$arg2 as xs:numeric
) as xs:boolean
Rules

General rules: see 4.2 Arithmetic operators on numeric values and 4.3 Comparison operators on numeric values.

Notes

For xs:float and xs:double values, positive zero and negative zero compare equal. INF equals INF and -INF equals -INF. If $arg1 or $arg2 is NaN, the function returns false.

4.3.2 op:numeric-less-than

Summary

Returns true if and only if $arg1 is numerically less than $arg2.

Operator Mapping

Defines the semantics of the lt operator when applied to two numeric values, and is also used in defining the semantics of le, gt, and ge.

Signature
op:numeric-less-than(
$arg1 as xs:numeric,
$arg2 as xs:numeric
) as xs:boolean
Rules

General rules: see 4.2 Arithmetic operators on numeric values and 4.3 Comparison operators on numeric values.

Notes

For xs:float and xs:double values, positive infinity is greater than all other non-NaN values; negative infinity is less than all other non-NaN values. Positive and negative zero compare equal. If $arg1 or $arg2 is NaN, the function returns false.

4.4 Functions on numeric values

The following functions are defined on numeric types. Each function returns a value of the same type as the type of its argument.

  • If the argument is the empty sequence, the empty sequence is returned.

  • For xs:float and xs:double arguments, if the argument is NaN, NaN is returned.

  • With the exception of fn:abs, functions with arguments of type xs:float and xs:double that are positive or negative infinity return positive or negative infinity.

Function Meaning
fn:abs Returns the absolute value of $value.
fn:ceiling Rounds $value upwards to a whole number.
fn:floor Rounds $value downwards to a whole number.
fn:round Rounds a value to a specified number of decimal places, with control over how the rounding takes place.
fn:round-half-to-even Rounds a value to a specified number of decimal places, rounding to make the last digit even if two such values are equally near.
fn:is-NaN Returns true if the argument is the xs:float or xs:double value NaN.

Note:

The fn:round function has been extended with a third argument in version 4.0 of this specification; this means that the fn:ceiling, fn:floor, and fn:round-half-to-even functions are now technically redundant. They are retained, however, both for backwards compatibility and for convenience.

4.4.1 fn:abs

Summary

Returns the absolute value of $value.

Signature
fn:abs(
$value as xs:numeric?
) as xs:numeric?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

General rules: see 4.4 Functions on numeric values.

If $value is negative the function returns -$value, otherwise it returns $value.

For the four types xs:float, xs:double, xs:decimal and xs:integer, it is guaranteed that if the type of $value is an instance of type T then the result will also be an instance of T. The result may also be an instance of a type derived from one of these four by restriction. For example, if $value is an instance of xs:positiveInteger then the value of $value may be returned unchanged.

For xs:float and xs:double arguments, if the argument is positive zero or negative zero, then positive zero is returned. If the argument is positive or negative infinity, positive infinity is returned.

Examples
Expression Result
abs(10.5)
10.5
abs(-10.5)
10.5
abs(-math:log(0))
xs:double('INF')

4.4.2 fn:ceiling

Summary

Rounds $value upwards to a whole number.

Signature
fn:ceiling(
$value as xs:numeric?
) as xs:numeric?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

General rules: see 4.4 Functions on numeric values.

The function returns the smallest (closest to negative infinity) number with no fractional part that is not less than $value.

For the four types xs:float, xs:double, xs:decimal and xs:integer, it is guaranteed that if the type of $value is an instance of type T then the result will also be an instance of T. The result may also be an instance of a type derived from one of these four by restriction. For example, if $value is an instance of xs:decimal then the result may be an instance of xs:integer.

For xs:float and xs:double arguments, if the argument is positive zero, then positive zero is returned. If the argument is negative zero, then negative zero is returned. If the argument is less than zero and greater than -1, negative zero is returned. If the argument is positive or negative infinity, the value of the argument is returned.

Examples
Expression Result
ceiling(10.5)
11
ceiling(-10.5)
-10
ceiling(math:log(0))
-xs:double('INF')

4.4.3 fn:floor

Summary

Rounds $value downwards to a whole number.

Signature
fn:floor(
$value as xs:numeric?
) as xs:numeric?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

General rules: see 4.4 Functions on numeric values.

The function returns the largest (closest to positive infinity) number with no fractional part that is not greater than $value.

For the four types xs:float, xs:double, xs:decimal and xs:integer, it is guaranteed that if the type of $value is an instance of type T then the result will also be an instance of T. The result may also be an instance of a type derived from one of these four by restriction. For example, if $value is an instance of xs:decimal then the result may be an instance of xs:integer.

For xs:float and xs:double arguments, if the argument is positive zero, then positive zero is returned. If the argument is negative zero, then negative zero is returned. If the argument is positive or negative infinity, the value of the argument is returned.

Examples
Expression Result
floor(10.5)
10
floor(-10.5)
-11
math:log(0) => floor()
-xs:double('INF')

4.4.4 fn:round

Changes in 4.0  

  1. A third argument has been added, providing control over the rounding mode.  [Issues 1187 1274 PRs 1260 1275 11 June 2024]

Summary

Rounds a value to a specified number of decimal places, with control over how the rounding takes place.

Signature
fn:round(
$value as xs:numeric?,
$precision as xs:integer? := 0,
$mode as enum('floor', 'ceiling', 'toward-zero', 'away-from-zero', 'half-to-floor', 'half-to-ceiling', 'half-toward-zero', 'half-away-from-zero', 'half-to-even')? := 'half-to-ceiling'
) as xs:numeric?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

General rules: see 4.4 Functions on numeric values.

The function returns a value that is close to $value and that is a multiple of ten to the power of minus $precision. The default value of $precision is zero, in which case the function returns a whole number (but not necessarily an xs:integer).

The detailed way in which rounding is performed depends on the value of $mode, as follows. Here L means the highest multiple of ten to the power of minus $precision that is less than or equal to $value, U means the lowest multiple of ten to the power of minus $precision that is greater than or equal to $value, N means the multiple of ten to the power of minus $precision that is numerically closest to $value, and midway means that $value is equal to the arithmetic mean of L and U.

Rounding Modes
Rounding Mode Meaning

'floor'

Returns L.

'ceiling'

Returns U.

'toward-zero'

Returns L if $value is positive, otherwise U.

'away-from-zero'

Returns U if $value is positive, otherwise L

'half-to-floor'

Returns N, unless midway, in which case L.

'half-to-ceiling'

Returns N, unless midway, in which case U. This is the default.

'half-toward-zero'

Returns N, unless midway, in which case it returns L if $value is positive, otherwise U.

'half-away-from-zero'

Returns N, unless midway, in which case it returns U if $value is positive, otherwise L.

'half-to-even'

Returns N, unless midway, in which case it returns whichever of L and U has a last significant digit that is even.

For the four types xs:float, xs:double, xs:decimal and xs:integer, it is guaranteed that if the type of $value is an instance of type T then the result will also be an instance of T. The result may also be an instance of a type derived from one of these four by restriction. For example, if $value is an instance of xs:decimal and $precision is less than one, then the result may be an instance of xs:integer.

If the second argument is omitted or is an empty sequence, the function produces the same result as when $precision = 0 (that is, it rounds to a whole number).

When $value is of type xs:float and xs:double:

  1. If $value is NaN, positive or negative zero, or positive or negative infinity, then the result is the same as the argument.

  2. For other values, the argument is cast to xs:decimal using an implementation of xs:decimal that imposes no limits on the number of digits that can be represented. The function is applied to this xs:decimal value, and the resulting xs:decimal is cast back to xs:float or xs:double as appropriate to form the function result. If the resulting xs:decimal value is zero, then positive or negative zero is returned according to the sign of $value.

Notes

This function is typically used with a non-zero $precision in financial applications where the argument is of type xs:decimal. For arguments of type xs:float and xs:double the results may be counter-intuitive. For example, consider round(35.425e0, 2). The result is not 35.43, as might be expected, but 35.42. This is because the xs:double written as 35.425e0 has an exact value equal to 35.42499999999..., which is closer to 35.42 than to 35.43.

The call round($v, 0, "floor") is equivalent to floor($v).

The call round($v, 0, "ceiling") is equivalent to ceiling($v).

The call round($v, $p, "half-to-even") is equivalent to round-half-to-even($v, $p).

Examples
Expression Result
round(2.5)
3.0
round(2.4999)
2.0
round(-2.5)
-2.0
round(1.125, 2)
1.13
round(8452, -2)
8500
round(3.1415e0, 2)
3.14e0
math:log(0) => round()
-xs:double('INF')
round(1.7, 0, "floor")
1
round(-1.7, 0, "floor")
-2
round(1.7, 0, "ceiling")
2
round(-1.7, 0, "ceiling")
-1
round(1.7, 0, "toward-zero")
1
round(-1.7, 0, "toward-zero")
-1
round(1.7, 0, "away-from-zero")
2
round(-1.7, 0, "away-from-zero")
-2
round(1.125, 2, "half-to-floor")
1.12
round(-1.125, 2, "half-to-floor")
-1.13
round(1.125, 2, "half-to-ceiling")
1.13
round(-1.125, 2, "half-to-ceiling")
-1.12
round(1.125, 2, "half-toward-zero")
1.12
round(-1.125, 2, "half-toward-zero")
-1.12
round(1.125, 2, "half-away-from-zero")
1.13
round(-1.125, 2, "half-away-from-zero")
-1.13
round(1.125, 2, "half-to-even")
1.12
round(-1.125, 2, "half-to-even")
-1.12

4.4.5 fn:round-half-to-even

Summary

Rounds a value to a specified number of decimal places, rounding to make the last digit even if two such values are equally near.

Signature
fn:round-half-to-even(
$value as xs:numeric?,
$precision as xs:integer? := 0
) as xs:numeric?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

General rules: see 4.4 Functions on numeric values.

The function returns the nearest (that is, numerically closest) value to $value that is a multiple of ten to the power of minus $precision. If two such values are equally near (e.g. if the fractional part in $value is exactly .500...), the function returns the one whose least significant digit is even.

For the four types xs:float, xs:double, xs:decimal and xs:integer, it is guaranteed that if the type of $value is an instance of type T then the result will also be an instance of T. The result may also be an instance of a type derived from one of these four by restriction. For example, if $value is an instance of xs:decimal and $precision is less than one, then the result may be an instance of xs:integer.

If the second argument is omitted or an empty sequence, the function produces the same result as the two-argument version with $precision = 0.

For arguments of type xs:float and xs:double:

  1. If the argument is NaN, positive or negative zero, or positive or negative infinity, then the result is the same as the argument.

  2. In all other cases, the argument is cast to xs:decimal using an implementation of xs:decimal that imposes no limits on the number of digits that can be represented. The function is applied to this xs:decimal value, and the resulting xs:decimal is cast back to xs:float or xs:double as appropriate to form the function result. If the resulting xs:decimal value is zero, then positive or negative zero is returned according to the sign of the original argument.

Notes

This function is typically used in financial applications where the argument is of type xs:decimal. For arguments of type xs:float and xs:double the results may be counter-intuitive. For example, consider round-half-to-even(xs:float(150.015), 2). The result is not 150.02 as might be expected, but 150.01. This is because the conversion of the xs:float value represented by the literal 150.015 to an xs:decimal produces the xs:decimal value 150.014999389..., which is closer to 150.01 than to 150.02.

From 4.0, the effect of this function can also be achieved by calling fn:round with the third argument set to "half-to-even".

Examples
Expression Result
round-half-to-even(0.5)
0.0
round-half-to-even(1.5)
2.0
round-half-to-even(2.5)
2.0
round-half-to-even(3.567812e+3, 2)
3567.81e0
round-half-to-even(4.7564e-3, 2)
0.0e0
round-half-to-even(35612.25, -2)
35600
math:log(0) => round-half-to-even()
-xs:double('INF')

4.4.6 fn:is-NaN

Changes in 4.0  

  1. New in 4.0  [  20 September 2022]

Summary

Returns true if the argument is the xs:float or xs:double value NaN.

Signature
fn:is-NaN(
$value as xs:anyAtomicType
) as xs:boolean
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

The function returns true if the argument is the xs:float or xs:double value NaN; otherwise it returns false.

Examples
Expression Result
is-NaN(23)
false()
is-NaN("NaN")
false()
is-NaN(number("twenty-three"))
true()
is-NaN(math:sqrt(-1))
true()

4.5 Parsing numbers

It is possible to convert strings to values of type xs:integer, xs:float, xs:decimal, or xs:double using the constructor functions described in 19 Constructor functions or using cast expressions as described in 20 Casting.

In addition the fn:number function is available to convert strings to values of type xs:double. It differs from the xs:double constructor function in that any value outside the lexical space of the xs:double datatype is converted to the xs:double value NaN.

Function Meaning
fn:number Returns the value indicated by $value or, if $value is not specified, the context value after atomization, converted to an xs:double.
fn:parse-integer Converts a string to an integer, recognizing any radix in the range 2 to 36.

4.5.1 fn:number

Summary

Returns the value indicated by $value or, if $value is not specified, the context value after atomization, converted to an xs:double.

Signature
fn:number(
$value as xs:anyAtomicType? := .
) as xs:double
Properties

The zero-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-dependent·.

The one-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

Calling the zero-argument version of the function is defined to give the same result as calling the single-argument version with the context value (.). That is, fn:number() is equivalent to fn:number(.), as defined by the rules that follow.

If $value is the empty sequence or if $value cannot be converted to an xs:double, the xs:double value NaN is returned.

Otherwise, $value is converted to an xs:double following the rules of 20.1.3.2 Casting to xs:double. If the conversion to xs:double fails, the xs:double value NaN is returned.

Error Conditions

A type error is raised [err:XPDY0002]XP if $value is omitted and the context value is absentDM40.

As a consequence of the rules given above, a type error is raised [err:XPTY0004]XP if the context value cannot be atomized, or if the result of atomizing the context value is a sequence containing more than one atomic item.

Notes

XSD 1.1 allows the string +INF as a representation of positive infinity; XSD 1.0 does not. It is ·implementation-defined· whether XSD 1.1 is supported.

Generally fn:number returns NaN rather than raising a dynamic error if the argument cannot be converted to xs:double. However, a type error is raised in the usual way if the supplied argument cannot be atomized or if the result of atomization does not match the required argument type.

Examples
Variables
let $e := <e price="12.1" discount="NONE"/>
Expression Result
number(12)
1.2e1
number('12')
1.2e1
number('INF')
xs:double('INF')
number('NaN')
xs:double('NaN')
number('non-numeric')
xs:double('NaN')
number($e/@price)
1.21e1
number($e/@discount)
xs:double('NaN')
number($e/@misspelt)
xs:double('NaN')
("10", "11", "12") ! number()
1.0e1, 1.1e1, 1.2e1

4.5.2 fn:parse-integer

Changes in 4.0  

  1. New in 4.0  [Issue 241 PR 434 25 April 2023]

Summary

Converts a string to an integer, recognizing any radix in the range 2 to 36.

Signature
fn:parse-integer(
$value as xs:string?,
$radix as xs:integer? := 10
) as xs:integer?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is an empty sequence, the result is an empty sequence.

The supplied $radix must be in the range 2 to 36 inclusive.

The string $value is preprocessed by stripping all whitespace characters (including internal whitespace) and underscore characters.

After this process, the supplied value must consist of an optional sign (+ or -) followed by a sequence of one or more generalized digits drawn from the first $radix characters in the alphabet 0123456789abcdefghijklmnopqrstuvwxyz; upper-case alphabetics A-Z may be used in place of their lower-case equivalents.

The value of a generalized digit corresponds to its position in this alphabet.

Formal Specification

The effect of the function is equivalent to the result of the following XPath expression, except in error cases.

let $alphabet := characters("0123456789abcdefghijklmnopqrstuvwxyz")
let $preprocessed-value := translate($value, "_ 	

", "")
let $digits := translate($preprocessed-value, "+-", "")
let $abs := sum(
  for $char at $p in reverse(characters(lower-case($digits)))
  return (index-of($alphabet, $char) - 1) * xs:integer(math:pow($radix, $p - 1)))
return if (starts-with($preprocessed-value, "-")) then -$abs else +$abs
Error Conditions

A dynamic error is raised [err:FORG0011] if $radix is not in the range 2 to 36.

A dynamic error is raised [err:FORG0012] if, after stripping whitespace and underscores and the optional leading sign, $value is a zero-length string, or if it contains a character that is not among the first $radix characters in the alphabet 0123456789abcdefghijklmnopqrstuvwxyz, or the upper-case equivalent of such a character.

A dynamic error is raised [err:FOCA0003] if the value of the resulting integer exceeds the implementation-dependent limit on the size of an xs:integer.

Notes

When $radix takes its default value of 10, the function delivers the same result as casting $value (after removal of whitespace and underscores) to xs:integer.

If underscores or whitespace in the input need to be rejected, then the string should first be validated, perhaps using fn:matches.

If other characters may legitimately appear in the input, for example a leading 0x, then this must first be removed by pre-processing the input.

If the input uses a different family of digits, then the value should first be converted to the required digits using fn:translate.

A string in the lexical space of xs:hexBinary will always be an acceptable input, provided it is not too long. So, for example, the expression "1DE=" => xs:base64Binary() => xs:hexBinary() => xs:string() => parse-integer(16) can be used to convert the Base 64 value 1DE= to the integer 54321, via the hexadecimal string D431.

Examples
Expression:

parse-integer(" 200 ")

Result:
200
Expression:

parse-integer("-20")

Result:
-20
Expression:

parse-integer(" +100")

Result:
100
Expression:

parse-integer("ff", 16)

Result:
255
Expression:

parse-integer("FFFF FFFF", 16)

Result:
4294967295
Expression:

parse-integer("-FFFF_FFFF", 16)

Result:
-4294967295
Expression:

parse-integer("377", 8)

Result:
255
Expression:

parse-integer("101", 2)

Result:
5
Expression:

parse-integer("vv", 32)

Result:
1023

Alphabetic base-26 numbering systems (hexavigesimal) can be parsed via translation. Note, enumerating systems that do not assign a symbol to zero (e.g., spreadsheet columns) must be preprocessed in a different fashion.

Expression:
lower-case("AAB")
=> translate("abcdefghijklmnopqrstuvwxyz", "0123456789abcdefghijklmnop")
=> parse-integer(26)
Result:
1

Digit-based numeration systems comparable to the Arabic numbers 0 through 9 can be parsed via translation.

Expression:
translate(value := '٢٠٢٣', replace := '٠١٢٣٤٥٦٧٨٩', with := '0123456789')
=> parse-integer()
Result:
2023

4.6 Formatting integers

Function Meaning
fn:format-integer Formats an integer according to a given picture string, using the conventions of a given natural language if specified.

4.6.1 fn:format-integer

Changes in 4.0  

  1. The function has been extended to allow output in a radix other than 10, for example in hexadecimal.  [Issue 241 PR 434 7 April 2023]

Summary

Formats an integer according to a given picture string, using the conventions of a given natural language if specified.

Signature
fn:format-integer(
$value as xs:integer?,
$picture as xs:string,
$language as xs:string? := ()
) as xs:string
Properties

The two-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-independent·. It depends on default language.

The three-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is an empty sequence, the function returns a zero-length string.

In all other cases, the $picture argument describes the format in which $value is output.

The rules that follow describe how non-negative numbers are output. If the value of $value is negative, the rules below are applied to the absolute value of $value, and a minus sign is prepended to the result.

The value of $picture consists of the following, in order:

  1. An optional radix, which is an integer in the range 2 to 36, written using ASCII digits (0-9) without any leading zero;

  2. A circumflex (^), which is present if the radix is present, and absent otherwise.

    A circumflex is recognized as marking the presence of a radix only if (a) it is immediately preceded by an integer in the range 2 to 36, and (b) it is followed (somewhere within the primary format token) by an "X" or "x". In other cases, the circumflex is treated as a grouping separator. For example, the picture 9^000 outputs the number 2345 as "2^345", whereas 9^XXX outputs "3185". This rule is to ensure backwards compatibility.

  3. A primary format token. This is always present and must not be zero-length.

  4. An optional format modifier.

    If the string contains one or more semicolons then the last semicolon is taken as terminating the primary format token, and everything that follows is taken as the format modifier; if the string contains no semicolon then the format modifier is taken to be absent (which is equivalent to supplying a zero-length string).

If a radix is present, then the primary format token must follow the rules for a digit-pattern.

The primary format token is classified as one of the following:

  1. A digit-pattern made up of optional-digit-signs, mandatory-digit-signs, and grouping-separator-signs.

    • The optional-digit-sign is the character #.

    • If the radix is absent, then a mandatory-digit-sign is a ·character· in Unicode category Nd. All mandatory-digit-signs within the format token must be from the same digit family, where a digit family is a sequence of ten consecutive characters in Unicode category Nd, having digit values 0 through 9. Within the format token, these digits are interchangeable: a three-digit number may thus be indicated equivalently by 000, 001, or 999.

      If the primary format token contains at least one Unicode digit, then the primary format token is taken as a decimal digit pattern, and in this case it must match the regular expression ^((\p{Nd}|#|[^\p{N}\p{L}])+?)$. If it contains a digit but does not match this pattern, a dynamic error is raised [err:FODF1310].

    • If the radix (call it R) is present (including the case where an explicit radix of 10 is used), then the character used as the mandatory-digit-sign is either "x" or "X". If any mandatory-digit-sign is upper-case "X", then all mandatory-digit-signs must be upper-case "X". The digit family used in the output comprises the first R characters of the alphabet 0123456789abcdefghijklmnopqrstuvwxyz, but using upper-case letters in place of lower-case if an upper-case "X" is used as the mandatory-digit-sign.

      In this case the primary format token must match the regular expression ^(([Xx#]|[^\p{N}\p{L}])+?)$

    • a grouping-separator-sign is a non-alphanumeric character, that is a ·character· whose Unicode category is other than Nd, Nl, No, Lu, Ll, Lt, Lm or Lo.

    Note:

    If a semicolon is to be used as a grouping separator, then the primary format token as a whole must be followed by another semicolon, to ensure that the grouping separator is not mistaken as a separator between the primary format token and the format modifier.

    There must be at least one mandatory-digit-sign. There may be zero or more optional-digit-signs, and (if present) these must precede all mandatory-digit-signs. There may be zero or more grouping-separator-signs. A grouping-separator-sign must not appear at the start or end of the digit-pattern, nor adjacent to another grouping-separator-sign.

    The corresponding output is a number in the specified radix, using this digit family, with at least as many digits as there are mandatory-digit-signs in the format token. Thus:

    • A format token 1 generates the sequence 0 1 2 ... 10 11 12 ...

    • A format token 01 (or equivalently, 00 or 99) generates the sequence 00 01 02 ... 09 10 11 12 ... 99 100 101

    • A format token of U+0661 (ARABIC-INDIC DIGIT ONE, ١) generates the sequence ١ then ٢ then ٣ ...

    • A format token of 16^xx generates the sequence 00 01 02 03 ... 08 09 0a 0b 0c 0d 0e 0f 10 11 ...

    • A format token of 16^X generates the sequence 0 1 2 3 ... 8 9 A B C D E F 10 11 ...

    The grouping-separator-signs are handled as follows:

    1. The position of grouping separators within the format token, counting backwards from the last digit, indicates the position of grouping separators to appear within the formatted number, and the character used as the grouping-separator-sign within the format token indicates the character to be used as the corresponding grouping separator in the formatted number.

    2. More specifically, the position of a grouping separator is the number of optional-digit-signs and mandatory-digit-signs appearing between the grouping separator and the right-hand end of the primary format token.

    3. Grouping separators are defined to be regular if the following conditions apply:

      1. There is at least one grouping separator.

      2. Every grouping separator is the same character (call it C).

      3. There is a positive integer G (the grouping size) such that:

        1. The position of every grouping separator is an integer multiple of G, and

        2. Every positive integer multiple of G that is less than the number of optional-digit-signs and mandatory-digit-signs in the primary format token is the position of a grouping separator.

    4. The grouping separator template is a (possibly infinite) set of (position, character) pairs.

    5. If grouping separators are regular, then the grouping separator template contains one pair of the form (n×G, C) for every positive integer n where G is the grouping size and C is the grouping character.

    6. Otherwise (when grouping separators are not regular), the grouping separator template contains one pair of the form (P, C) for every grouping separator found in the primary formatting token, where C is the grouping separator character and P is its position.

    7. Note:

      If there are no grouping separators, then the grouping separator template is an empty set.

    The number is formatted as follows:

    1. Let S1 be the result of formatting the supplied number in the appropriate radix: for radix 10 this will be the value obtained by casting it to xs:string.

    2. Let S2 be the result of padding S1 on the left with as many leading zeroes as are needed to ensure that it contains at least as many digits as the number of mandatory-digit-signs in the primary format token.

    3. Let S3 be the result of replacing all decimal digits (0-9) in S2 with the corresponding digits from the selected digit family. (This has no effect when the selected digit family uses ASCII digits (0-9), which will always be the case if a radix is specified.)

    4. Let S4 be the result of inserting grouping separators into S3: for every (position P, character C) pair in the grouping separator template where P is less than the number of digits in S3, insert character C into S3 at position P, counting from the right-hand end.

    5. Let S5 be the result of converting S4 into ordinal form, if an ordinal modifier is present, as described below.

    6. The result of the function is then S5.

  2. The format token A, which generates the sequence A B C ... Z AA AB AC....

  3. The format token a, which generates the sequence a b c ... z aa ab ac....

  4. The format token i, which generates the sequence i ii iii iv v vi vii viii ix x ....

  5. The format token I, which generates the sequence I II III IV V VI VII VIII IX X ....

  6. The format token w, which generates numbers written as lower-case words, for example in English, one two three four ...

  7. The format token W, which generates numbers written as upper-case words, for example in English, ONE TWO THREE FOUR ...

  8. The format token Ww, which generates numbers written as title-case words, for example in English, One Two Three Four ...

  9. Any other format token, which indicates a numbering sequence in which that token represents the number 1 (one) (but see the note below). It is ·implementation-defined· which numbering sequences, additional to those listed above, are supported. If an implementation does not support a numbering sequence represented by the given token, it must use a format token of 1.

    Note:

    In some traditional numbering sequences additional signs are added to denote that the letters should be interpreted as numbers, for example, in ancient Greek U+0374 (DEXIA KERAIA, ʹ) and sometimes U+0375 (ARISTERI KERAIA, ͵) . These should not be included in the format token.

For all format tokens other than a digit-pattern, there may be ·implementation-defined· lower and upper bounds on the range of numbers that can be formatted using this format token; indeed, for some numbering sequences there may be intrinsic limits. For example, the format token U+2460 (CIRCLED DIGIT ONE, ) has a range imposed by the Unicode character repertoire — zero to 20 in Unicode versions prior to 3.2, or zero to 50 in subsequent versions. For the numbering sequences described above any upper bound imposed by the implementation must not be less than 1000 (one thousand) and any lower bound must not be greater than 1. Numbers that fall outside this range must be formatted using the format token 1.

The above expansions of numbering sequences for format tokens such as a and i are indicative but not prescriptive. There are various conventions in use for how alphabetic sequences continue when the alphabet is exhausted, and differing conventions for how roman numerals are written (for example, IV versus IIII as the representation of the number 4). Sometimes alphabetic sequences are used that omit letters such as i and o. This specification does not prescribe the detail of any sequence other than those sequences consisting entirely of decimal digits.

Many numbering sequences are language-sensitive. This applies especially to the sequence selected by the tokens w, W and Ww. It also applies to other sequences, for example different languages using the Cyrillic alphabet use different sequences of characters, each starting with the letter U+0410 (CYRILLIC CAPITAL LETTER A, А) . In such cases, the $language argument specifies which language conventions are to be used. If the argument is specified, the value should be either an empty sequence or a value that would be valid for the xml:lang attribute (see [Extensible Markup Language (XML) 1.0 (Fifth Edition)]). Note that this permits the identification of sublanguages based on country codes (from ISO 3166-1) as well as identification of dialects and regions within a country.

The set of languages for which numbering is supported is ·implementation-defined·. If the $language argument is absent, or is set to an empty sequence, or is invalid, or is not a language supported by the implementation, then the number is formatted using the default language from the dynamic context.

The format modifier must be a string that matches the regular expression ^([co](\(.+\))?)?[at]?$. That is, if it is present it must consist of one or more of the following, in order:

  • either c or o, optionally followed by a sequence of characters enclosed between parentheses, to indicate cardinal or ordinal numbering respectively, the default being cardinal numbering

  • either a or t, to indicate alphabetic or traditional numbering respectively, the default being ·implementation-defined·.

If the o modifier is present, this indicates a request to output ordinal numbers rather than cardinal numbers. For example, in English, when used with the format token 1, this outputs the sequence 1st 2nd 3rd 4th ..., and when used with the format token w outputs the sequence first second third fourth ....

The string of characters between the parentheses, if present, is used to select between other possible variations of cardinal or ordinal numbering sequences. The interpretation of this string is ·implementation-defined·. No error occurs if the implementation does not define any interpretation for the defined string.

It is ·implementation-defined· what combinations of values of the format token, the language, and the cardinal/ordinal modifier are supported. If ordinal numbering is not supported for the combination of the format token, the language, and the string appearing in parentheses, the request is ignored and cardinal numbers are generated instead.

The use of the a or t modifier disambiguates between numbering sequences that use letters. In many languages there are two commonly used numbering sequences that use letters. One numbering sequence assigns numeric values to letters in alphabetic sequence, and the other assigns numeric values to each letter in some other manner traditional in that language. In English, these would correspond to the numbering sequences specified by the format tokens a and i. In some languages, the first member of each sequence is the same, and so the format token alone would be ambiguous. In the absence of the a or t modifier, the default is ·implementation-defined·.

Error Conditions

A dynamic error is raised [err:FODF1310] if the format token is invalid, that is, if it violates any mandatory rules (indicated by an emphasized must or required keyword in the above rules). For example, the error is raised if the primary format token contains a digit but does not match the required regular expression.

Notes
  1. Note the careful distinction between conditions that are errors and conditions where fallback occurs. The principle is that an error in the syntax of the format picture will be reported by all processors, while a construct that is recognized by some implementations but not others will never result in an error, but will instead cause a fallback representation of the integer to be used.

  2. The following notes apply when a digit-pattern is used:

    1. If grouping-separator-signs appear at regular intervals within the format token, then the sequence is extrapolated to the left, so grouping separators will be used in the formatted number at every multiple of N. For example, if the format token is 0'000 then the number one million will be formatted as 1'000'000, while the number fifteen will be formatted as 0'015.

    2. The only purpose of optional-digit-signs is to mark the position of grouping-separator-signs. For example, if the format token is #'##0 then the number one million will be formatted as 1'000'000, while the number fifteen will be formatted as 15. A grouping separator is included in the formatted number only if there is a digit to its left, which will only be the case if either (a) the number is large enough to require that digit, or (b) the number of mandatory-digit-signs in the format token requires insignificant leading zeros to be present.

    3. Grouping separators are not designed for effects such as formatting a US telephone number as (365)123-9876. In general they are not suitable for such purposes because (a) only single characters are allowed, and (b) they cannot appear at the beginning or end of the number.

    4. Numbers will never be truncated. Given the digit-pattern 01, the number three hundred will be output as 300, despite the absence of any optional-digit-sign.

  3. The following notes apply when ordinal numbering is selected using the o modifier.

    In some languages, the form of numbers (especially ordinal numbers) varies depending on the grammatical context: they may have different genders and may decline with the noun that they qualify. In such cases the string appearing in parentheses after the letter c or o may be used to indicate the variation of the cardinal or ordinal number required.

    The way in which the variation is indicated will depend on the conventions of the language.

    For inflected languages that vary the ending of the word, the approach recommended in the previous version of this specification was to indicate the required ending, preceded by a hyphen: for example in German, appropriate values might be o(-e), o(-er), o(-es), o(-en).

    Another approach, which might usefully be adopted by an implementation based on the open-source ICU localization library [ICU], or any other library making use of the Unicode Common Locale Data Repository [Unicode CLDR], is to allow the value in parentheses to be the name of a registered numbering rule set for the language in question, conventionally prefixed with a percent sign: for example, o(%spellout-ordinal-masculine), or c(%spellout-cardinal-year).

  4. The following notes apply when the primary format token is neither a digit-pattern nor one of the seven other defined format tokens (A, a, i, I, w, W, Ww), but is an arbitrary token representing the number 1:

    Unexpected results may occur for traditional numbering. For example, in an implementation that supports traditional numbering system in Greek, the example format-integer(19, "α;t") might return δπιιιι or ιθ, depending upon whether the ancient acrophonic or late antique alphabetic system is supported.

    Unexpected results may also occur for alphabetic numbering. For example, in an implementation that supports alphabetic numbering system in Greek, someone writing format-integer(19, "α;a") might expect the nineteenth Greek letter, U+03C4 (GREEK SMALL LETTER TAU, τ) , but the implementation might return the eighteenth one, U+03C3 (GREEK SMALL LETTER SIGMA, σ) , because the latter is the nineteenth item in the sequence of lowercase Greek letters in Unicode (the sequence is interrupted because of the final form of the sigma, U+03C2 (GREEK SMALL LETTER FINAL SIGMA, ς) ). Because Greek never had a final capital sigma, Unicode has marked U+03A2, the eighteenth codepoint in the sequence of Greek capital letters, as reserved, to ensure that every Greek uppercase letter is always 32 codepoints less than its lowercase counterpart. Therefore, someone writing format-integer(18, "Α;a") might expect the eighteenth Greek capital letter, U+03A3 (GREEK CAPITAL LETTER SIGMA, Σ) , but an implementation might return U+03A2, the eighteenth position in the sequence of Greek capital letters, but unassigned to any character.

Examples
Expression:

format-integer(123, '0000')

Result:
"0123"

format-integer(123, 'w') might return "one hundred and twenty-three"

Ordinal numbering in Italian: The specification "1;o(-º)" with $language equal to it, if supported, should produce the sequence:

1º 2º 3º 4º ...

The specification "Ww;o" with $language equal to it, if supported, should produce the sequence:

Primo Secondo Terzo Quarto Quinto ...
Expression:

format-integer(21, '1;o', 'en')

Result:
"21st"

format-integer(14, 'Ww;o(-e)', 'de') might return "Vierzehnte"

Expression:

format-integer(7, 'a')

Result:
"g"
Expression:

format-integer(27, 'a')

Result:
"aa"
Expression:

format-integer(57, 'I')

Result:
"LVII"
Expression:

format-integer(1234, '#;##0;')

Result:
"1;234"
Expression:

format-integer(1234, '16^xxxx')

Result:
"04d2"
Expression:

format-integer(1234, '16^X')

Result:
"4D2"
Expression:

format-integer(12345678, '16^xxxx_xxxx')

Result:
"00bc_614e"
Expression:

format-integer(12345678, '16^#_xxxx')

Result:
"bc_614e"
Expression:

format-integer(255, '2^xxxx xxxx')

Result:
"1111 1111"
Expression:

format-integer(1023, '32^XXXX')

Result:
"00VV"
Expression:

format-integer(1023, '10^XXXX')

Result:
"1023"
Expression:

format-integer(1023, '10^00')

Result:
"10^23"

4.7 Formatting numbers

This section defines a function for formatting decimal and floating point numbers.

Function Meaning
fn:format-number Returns a string containing a number formatted according to a given picture string and decimal format.

Note:

This function can be used to format any numeric quantity, including an integer. For integers, however, the fn:format-integer function offers additional possibilities. Note also that the picture strings used by the two functions are not 100% compatible, though they share some options in common.

4.7.1 Defining a decimal format

Decimal formats are defined in the static context, and the way they are defined is therefore outside the scope of this specification. XSLT and XQuery both provide custom syntax for creating a decimal format.

The static context provides a set of decimal formats. One of the decimal formats is unnamed, the others (if any) are identified by a QName. There is always an unnamed decimal format available, but its contents are ·implementation-defined·.

Each decimal format provides a set of named properties.

Note:

A phrase such as "The minus-signXP31 character" is to be read as “the character assigned to the minus-signXP31 property in the relevant decimal format”.

[Definition] The decimal digit family of a decimal format is the sequence of ten digits with consecutive Unicode ·codepoints· starting with the character that is the value of the zero-digitXP31 property.

[Definition] The optional digit character is the character that is the value of the digitXP31 property.

For any decimal format, the properties representing characters used in a ·picture string· must have distinct values. These properties are decimal-separatorXP31 , grouping-separatorXP31, exponent-separatorXP31, percentXP31, per-milleXP31, digitXP31, and pattern-separatorXP31. Furthermore, none of these properties may be equal to any ·character· in the ·decimal digit family·.

4.7.2 fn:format-number

Changes in 4.0  

  1. The decimal format name can now be supplied as a value of type xs:QName, as an alternative to supplying a lexical QName as an instance of xs:string.

  2. Decimal format parameters can now be supplied directly as a map in the third argument, rather than referencing a format defined in the static context.  [Issues 340 1138 PRs 1049 1151 5 March 2024]

  3. For selected properties including percent and exponent-separator, it is now possible to specify a single-character marker to be used in the picture string, together with a multi-character rendition to be used in the formatted output.  [Issue 1048 PR 1250 11 June 2024]

Summary

Returns a string containing a number formatted according to a given picture string and decimal format.

Signature
fn:format-number(
$value as xs:numeric?,
$picture as xs:string,
$options as (xs:string | map(*))? := ()
) as xs:string
Properties

The two-argument form of this function is ·deterministic·, ·context-independent·, and ·focus-independent·.

The three-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-independent·. It depends on decimal formats, and namespaces.

Rules

The function formats $value as a string using the ·picture string· specified by the $picture argument and a decimal format.

The $value argument may be of any numeric data type (xs:double, xs:float, xs:decimal, or their subtypes including xs:integer). Note that if an xs:decimal is supplied, it is not automatically promoted to an xs:double, as such promotion can involve a loss of precision.

If the supplied value of the $value argument is an empty sequence, the function behaves as if the supplied value were the xs:double value NaN.

If $options is absent, or if it is supplied as an empty sequence or an empty map, then the number is formatted using the properties of the unnamed decimal format in the static context.

For backwards compatibility reasons, the decimal format can be supplied as an instance of xs:string. If the value of the $options argument is an xs:string, then its value must be a string which after removal of leading and trailing whitespace is in the form of an EQName as defined in the XPath 4.0 grammar, that is one of the following:

  • A lexical QName, which is expanded using the statically known namespaces. The default namespace is not used (no prefix means no namespace).

  • A URIQualifiedName using the syntax Q{uri}local, where the URI can be zero-length to indicate a name in no namespace.

The effective value of the $options argument is then the map {'format-name':$FN} where $FN is the xs:QName result of expanding this EQName.

The entries that may appear in the $options map are as follows. The ·option parameter conventions· apply. The detailed rules for the interpretation of each option appear later.

In the table, the type xs:string (: matching '.' :) represents a single-character string, that is, a restriction of xs:string with the facet pattern=".", while the type xs:string (: matching '.|.:.*' :) indicates a string that is either a single character, or a single character followed by U+003A (COLON, :) followed by an arbitrary string. Such a property identifies two values: a single character called the marker, which is used to represent the property in the picture string; and an arbitrary string called the rendition which is used to represent in the property in the result string. In the absence of the colon the single character value is used both as the marker and the rendition.

The default value for absent options (other than format-name) is taken from a decimal format in the static context; the default values shown in the table are the values used if no specific value is assigned in the static context.

record(
format-name? as (xs:NCName | xs:QName)?,
decimal-separator? as xs:string (: matching '.|.:.*' :),
grouping-separator? as xs:string (: matching '.|.:.*' :),
exponent-separator? as xs:string (: matching '.|.:.*' :),
infinity? as xs:string,
minus-sign? as xs:string,
NaN? as xs:string,
percent? as xs:string (: matching '.|.:.*' :),
per-mille? as xs:string (: matching '.|.:.*' :),
zero-digit? as xs:string (: matching '.' :),
digit? as xs:string (: matching '.' :),
pattern-separator? as xs:string (: matching '.' :)
)
Key Meaning

format-name

The name of a decimal format in the static context; if absent, the unnamed decimal format in the static context is used. An xs:NCName represents the local part of an xs:QName in no namespace.
  • Type: (xs:NCName | xs:QName)?

  • Default: ()

decimal-separator

The marker used to represent the decimal point in the picture string, and the rendition of the decimal point in the formatted number.
  • Type: xs:string (: matching '.|.:.*' :)

  • Default: "."

grouping-separator

The marker used to separate groups of digits in the picture string, and the rendition of the grouping separator in the formatted number.
  • Type: xs:string (: matching '.|.:.*' :)

  • Default: ","

exponent-separator

The marker used to separate the mantissa from the exponent in scientific notation in the picture string, and the rendition of the exponent separator in the formatted number.
  • Type: xs:string (: matching '.|.:.*' :)

  • Default: "e"

infinity

The string used to represent the value positive or negative infinity in the formatted number.
  • Type: xs:string

  • Default: "Infinity"

minus-sign

The string used as a minus sign in the formatted number if there is no subpicture for formatting negative numbers.
  • Type: xs:string

  • Default: "-"

NaN

The string used to represent the value NaN in the formatted number.
  • Type: xs:string

  • Default: "NaN"

percent

The marker used to indicate the presence of a percent sign in the picture string, and the rendition of the percent sign in the formatted number.
  • Type: xs:string (: matching '.|.:.*' :)

  • Default: "%"

per-mille

marker used to indicate the presence of a per-mille sign in the picture string, and the rendition of the per-mille sign in the formatted number.
  • Type: xs:string (: matching '.|.:.*' :)

  • Default: "‰" (0x2030)

zero-digit

Defines the characters used in the picture string to represent a mandatory digit: for example, if the zero-digit is 0 then any of the digits 0 to 9 may be used (interchangeably) in the picture string to represent a mandatory digit, and in the formatted number the characters 0 to 9 will be used to represent the digits zero to nine. The value must be a character in Unicode category Nd with decimal digit value 0 (zero).
  • Type: xs:string (: matching '.' :)

  • Default: "0"

digit

The character used in the picture string to represent an optional digit.
  • Type: xs:string (: matching '.' :)

  • Default: "#"

pattern-separator

The character used in the picture string to separate the positive and negative subpictures.
  • Type: xs:string (: matching '.' :)

  • Default: ";"

A base decimal format is established as follows:

  • If the format-name option is present, then the decimal format in the static context identified by this name.

  • Otherwise, the unnamed decimal format in the static context.

The base decimal format is then modified using the other entries in the supplied $options map.

The evaluation of the fn:format-number function takes place in two phases, an analysis phase described in 4.7.4 Analyzing the picture string and a formatting phase described in 4.7.5 Formatting the number.

The analysis phase takes as its inputs the ·picture string· and the variables derived from the relevant decimal format in the static context, and produces as its output a number of variables with defined values. The formatting phase takes as its inputs the number to be formatted and the variables produced by the analysis phase, and produces as its output a string containing a formatted representation of the number.

The result of the function is the formatted string representation of the supplied number.

Error Conditions

A dynamic error is raised [err:FODF1280] if the $options argument is supplied as an xs:string that is neither a valid lexical QName nor a valid URIQualifiedName, or if it uses a prefix that is not found in the statically known namespaces; or if the static context does not contain a declaration of a decimal format with a matching expanded QName; or if $options?format-name is present and the static context does not contain a declaration of a decimal format whose name matches $options?format-name. If the processor is able to detect the error statically (for example, when the argument is supplied as a string literal), then the processor may optionally signal this as a static error.

A dynamic error is raised [err:FODF1290] if a value of $format is not valid for the associated property, or if the properties of the decimal format resulting from a supplied $options map do not have distinct values.

Notes

A string is an ordered sequence of characters, and this specification uses terms such as “left” and “right”, “preceding” and “following” in relation to this ordering, irrespective of the position of the characters when visually rendered on some output medium. Both in the picture string and in the result string, digits with higher significance (that is, representing higher powers of ten) always precede digits with lower significance, even when the rendered text flow is from right to left.

In previous versions of XSLT and XQuery, decimal formats were typically defined in the static context using custom declarations (<xsl:decimal-format> in XSLT, declare decimal-format in XQuery) and then selected by name in a call on fn:format-number. This mechanism remains available, but in 4.0, it may be more convenient to dispense with these declarations, and instead to define a decimal format as a map bound to a global variable, which can be referenced in the $options argument of the fn:format-number call.

Examples

The following examples assume a default decimal format in which the chosen digits are the ASCII digits 0-9, the decimal separator is ., the grouping separator is ,, the minus-sign is -, and the percent-sign is %.

Expression:

format-number(12345.6, '#,###.00')

Result:
"12,345.60"
Expression:

format-number(12345678.9, '9,999.99')

Result:
"12,345,678.90"
Expression:

format-number(123.9, '9999')

Result:
"0124"
Expression:

format-number(0.14, '01%')

Result:
"14%"
Expression:
format-number(12345, '0,###^0', {
  'percent': '%:pc'
})
Result:
"14pc"
Expression:

format-number(-6, '000')

Result:
"-006"
Expression:
format-number(1234567.8, '0.000,0', {
   'grouping-separator': '.',
   'decimal-separator': ','
 })
Result:
"1.234.567,8"

The following examples assume the existence of a decimal format named de in which the grouping separator is . and the decimal separator is ,:

Expression:

format-number(1234.5678, '#.##0,00', {'format-name':'de'})

Result:
"1.234,57"
Expression:
format-number(12345, '0,###^0', {
  'format-name': 'de',
  'exponent-separator': '^'
})
Result:
"1,234^4"
Expression:
format-number(12345, '0,###^0', {
  'format-name': 'de',
  'exponent-separator': '^:×10^'
})
Result:
"1,234×10^4"

The following examples assume that the exponent separator in decimal format fortran is E:

Expression:

format-number(1234.5678, '00.000E0', 'fortran')

Result:
"12.346E2"
Expression:

format-number(0.234, '0.0E0', 'fortran')

Result:
"2.3E-1"
Expression:

format-number(0.234, '#.00E0', 'fortran')

Result:
"0.23E0"
Expression:

format-number(0.234, '.00E0', 'fortran')

Result:
".23E0"

4.7.3 Syntax of the picture string

Note:

This differs from the format-number function previously defined in XSLT 2.0 in that any digit can be used in the picture string to represent a mandatory digit: for example the picture strings "000", "001", and "999" are equivalent. The digits will all be from the same decimal digit family, specifically, the sequence of ten consecutive digits starting with the digit assigned to the zero-digit property. This change is to align format-number (which previously used "000") with format-dateTime (which used 001).

[Definition] The formatting of a number is controlled by a picture string. The picture string is a sequence of ·characters·, in which the characters assigned to the properties decimal-separatorXP31 , exponent-separatorXP31, grouping-separatorXP31, digitXP31, and pattern-separatorXP31 and the members of the ·decimal digit family·, are classified as active characters, and all other characters (including the values of the properties percentXP31 and per-milleXP31) are classified as passive characters.

A dynamic error is raised [err:FODF1310] if the ·picture string· does not conform to the following rules. Note that in these rules the words "preceded" and "followed" refer to characters anywhere in the string; they are not to be read as "immediately preceded" and "immediately followed".

  • A picture-string consists either of a sub-picture, or of two sub-pictures separated by the pattern-separatorXP31 character. A picture-string must not contain more than one instance of the pattern-separatorXP31 character. If the picture-string contains two sub-pictures, the first is used for positive and unsigned zero values and the second for negative values.

  • A sub-picture must not contain more than one instance of the decimal-separatorXP31 character.

  • A sub-picture must not contain more than one instance of the percentXP31 or per-milleXP31 characters, and it must not contain one of each.

  • The mantissa part of a sub-picture (defined below) must contain at least one character that is either an ·optional digit character· or a member of the ·decimal digit family·.

  • A sub-picture must not contain a passive character that is preceded by an active character and that is followed by another active character.

  • A sub-picture must not contain a grouping-separatorXP31 character that appears adjacent to a decimal-separatorXP31 character, or in the absence of a decimal-separatorXP31 character, at the end of the integer part.

  • A sub-picture must not contain two adjacent instances of the grouping-separatorXP31 character.

  • The integer part of a sub-picture (defined below) must not contain a member of the ·decimal digit family· that is followed by an instance of the ·optional digit character·. The fractional part of a sub-picture (defined below) must not contain an instance of the ·optional digit character· that is followed by a member of the ·decimal digit family·.

  • A character that matches the exponent-separatorXP31 property is treated as an exponent-separator-sign if it is both preceded and followed within the sub-picture by an active character. Otherwise, it is treated as a passive character. A sub-picture must not contain more than one character that is treated as an exponent-separator-sign.

  • A sub-picture that contains a percentXP31 or per-milleXP31 character must not contain a character treated as an exponent-separator-sign.

  • If a sub-picture contains a character treated as an exponent-separator-sign then this must be followed by one or more characters that are members of the ·decimal digit family·, and it must not be followed by any active character that is not a member of the ·decimal digit family·.

The mantissa part of the sub-picture is defined as the part that appears to the left of the exponent-separator-sign if there is one, or the entire sub-picture otherwise. The exponent part of the subpicture is defined as the part that appears to the right of the exponent-separator-sign; if there is no exponent-separator-sign then the exponent part is absent.

The integer part of the sub-picture is defined as the part that appears to the left of the decimal-separatorXP31 character if there is one, or the entire mantissa part otherwise.

The fractional part of the sub-picture is defined as that part of the mantissa part that appears to the right of the decimal-separatorXP31 character if there is one, or the part that appears to the right of the rightmost active character otherwise. The fractional part may be zero-length.

4.7.4 Analyzing the picture string

This phase of the algorithm analyzes the ·picture string· and the properties from the selected decimal format in the static context, and it has the effect of setting the values of various variables, which are used in the subsequent formatting phase. These variables are listed below. Each is shown with its initial setting and its datatype.

Several variables are associated with each sub-picture. If there are two sub-pictures, then these rules are applied to one sub-picture to obtain the values that apply to positive and unsigned zero numbers, and to the other to obtain the values that apply to negative numbers. If there is only one sub-picture, then the values for both cases are derived from this sub-picture.

The variables are as follows:

  • The integer-part-grouping-positions is a sequence of integers representing the positions of grouping separators within the integer part of the sub-picture. For each grouping-separatorXP31 character that appears within the integer part of the sub-picture, this sequence contains an integer that is equal to the total number of ·optional digit character· and ·decimal digit family· characters that appear within the integer part of the sub-picture and to the right of the grouping-separatorXP31 character.

    The grouping is defined to be regular if the following conditions apply:

    1. There is an least one grouping-separator in the integer part of the sub-picture.

    2. There is a positive integer G (the grouping size) such that the position of every grouping-separator in the integer part of the sub-picture is a positive integer multiple of G.

    3. Every position in the integer part of the sub-picture that is a positive integer multiple of G is occupied by a grouping-separator.

    If the grouping is regular, then the integer-part-grouping-positions sequence contains all integer multiples of G as far as necessary to accommodate the largest possible number.

  • The minimum-integer-part-size is an integer indicating the minimum number of digits that will appear to the left of the decimal-separator character. It is initially set to the number of ·decimal digit family· characters found in the integer part of the sub-picture, but may be adjusted as described below.

    Note:

    There is no maximum integer part size. All significant digits in the integer part of the number will be displayed, even if this exceeds the number of ·optional digit character· and ·decimal digit family· characters in the subpicture.

  • The scaling factor is a non-negative integer used to determine the scaling of the mantissa in exponential notation. It is set to the number of ·decimal digit family· characters found in the integer part of the sub-picture.

  • The prefix is set to contain all passive characters in the sub-picture to the left of the leftmost active character. If the picture string contains only one sub-picture, the prefix for the negative sub-picture is set by concatenating the minus-signXP31 character and the prefix for the positive sub-picture (if any), in that order.

  • The fractional-part-grouping-positions is a sequence of integers representing the positions of grouping separators within the fractional part of the sub-picture. For each grouping-separatorXP31 character that appears within the fractional part of the sub-picture, this sequence contains an integer that is equal to the total number of ·optional digit character· and ·decimal digit family· characters that appear within the fractional part of the sub-picture and to the left of the grouping-separatorXP31 character.

    Note:

    There is no need to extrapolate grouping positions on the fractional side, because the number of digits in the output will never exceed the number of ·optional digit character· and ·decimal digit family· characters in the fractional part of the sub-picture.

  • The minimum-fractional-part-size is set to the number of ·decimal digit family· characters found in the fractional part of the sub-picture.

  • The maximum-fractional-part-size is set to the total number of ·optional digit character· and ·decimal digit family· characters found in the fractional part of the sub-picture.

  • If the effect of the above rules is that minimum-integer-part-size and maximum-fractional-part-size are both zero, then an adjustment is applied as follows:

    • If an exponent separator is present then:

      • minimum-fractional-part-size is changed to 1 (one).

      • maximum-fractional-part-size is changed to 1 (one).

      Note:

      This has the effect that with the picture #.e9, the value 0.123 is formatted as 0.1e0

    • Otherwise:

      • minimum-integer-part-size is changed to 1 (one).

      Note:

      This has the effect that with the picture #, the value 0.23 is formatted as 0

  • If all the following conditions are true:

    • An exponent separator is present

    • The minimum-integer-part-size is zero

    • There is at least one ·optional digit character· in the integer part of the sub-picture

    then the minimum-integer-part-size is changed to 1 (one).

    Note:

    This has the effect that with the picture .9e9, the value 0.1 is formatted as .1e0, while with the picture #.9e9, it is formatted as 0.1e0

  • If (after making the above adjustments) the minimum-integer-part-size and the minimum-fractional-part-size are both zero, then the minimum-fractional-part-size is set to 1 (one).

  • The minimum-exponent-size is set to the number of ·decimal digit family· characters found in the exponent part of the sub-picture if present, or zero otherwise.

    Note:

    The rules for the syntax of the picture string ensure that if an exponent separator is present, then the minimum-exponent-size will always be greater than zero.

  • The suffix is set to contain all passive characters to the right of the rightmost active character in the sub-picture.

Note:

If there is only one sub-picture, then all variables for positive numbers and negative numbers will be the same, except for prefix: the prefix for negative numbers will be preceded by the minus-signXP31 character.

4.7.5 Formatting the number

This section describes the second phase of processing of the fn:format-number function. This phase takes as input a number to be formatted (referred to as the input number), and the variables set up by analyzing the decimal format in the static context and the ·picture string·, as described above. The result of this phase is a string, which forms the return value of the fn:format-number function.

The algorithm for this second stage of processing is as follows:

  1. If the input number is NaN (not a number), the result is the value of the pattern separatorXP31 property (with no prefix or suffix).

  2. In the rules below, the positive sub-picture and its associated variables are used if the input number is positive, and the negative sub-picture and its associated variables are used if it is negative. For xs:double and xs:float, negative zero is taken as negative, positive zero as positive. For xs:decimal and xs:integer, the positive sub-picture is used for zero.

  3. The adjusted number is determined as follows:

    • If the sub-picture contains a percentXP31 character, the adjusted number is the input number multiplied by 100.

    • If the sub-picture contains a per-milleXP31 character, the adjusted number is the input number multiplied by 1000.

    • Otherwise, the adjusted number is the input number.

    If the multiplication causes numeric overflow, no error occurs, and the adjusted number is positive or negative infinity as appropriate.

  4. If the adjusted number is positive or negative infinity, the result is the concatenation of the appropriate prefix, the value of the infinityXP31 property, and the appropriate suffix.

  5. If the minimum exponent size is non-zero, and the adjusted number is non-zero, then the adjusted number is scaled to establish a mantissa and an integer exponent. The mantissa and exponent are chosen such that all the following conditions are true:

    • The primitive type of the mantissa is the same as the primitive type of the adjusted number (integer, decimal, float, or double).

    • The mantissa multiplied by ten to the power of the exponent is equal to the adjusted number.

    • The mantissa (unless it is zero) is less than 10N, and at least 10N-1, where N is the scaling factor.

    If the minimum exponent size is zero, then the mantissa is the adjusted number and there is no exponent.

    If the minimum exponent size is non-zero and the adjusted number is zero, then the mantissa is the adjusted number and the exponent is zero.

  6. The mantissa is converted (if necessary) to an xs:decimal value, using an implementation of xs:decimal that imposes no limits on the totalDigits or fractionDigits facets. If there are several such values that are numerically equal to the mantissa (bearing in mind that if the mantissa is an xs:double or xs:float, the comparison will be done by converting the decimal value back to an xs:double or xs:float), the one that is chosen should be one with the smallest possible number of digits not counting leading or trailing zeroes (whether significant or insignificant). For example, 1.0 is preferred to 0.9999999999, and 100000000 is preferred to 100000001. This value is then rounded so that it uses no more than maximum-fractional-part-size digits in its fractional part. The rounded number is defined to be the result of converting the mantissa to an xs:decimal value, as described above, and then calling the function fn:round-half-to-even with this converted number as the first argument and the maximum-fractional-part-size as the second argument, again with no limits on the totalDigits or fractionDigits in the result.

  7. The absolute value of the rounded number is converted to a string in decimal notation, using the digits in the ·decimal digit family· to represent the ten decimal digits, and the decimal-separatorXP31 character to separate the integer part and the fractional part. This string must always contain a decimal-separatorXP31, and it must contain no leading zeroes and no trailing zeroes. The value zero will at this stage be represented by a decimal-separatorXP31 on its own.

  8. If the number of digits to the left of the decimal-separatorXP31 character is less than minimum-integer-part-size, leading zero digitXP31 characters are added to pad out to that size.

  9. If the number of digits to the right of the decimal-separatorXP31 character is less than minimum-fractional-part-size, trailing zero digitXP31 characters are added to pad out to that size.

  10. For each integer N in the integer-part-grouping-positions list, a grouping-separatorXP31 character is inserted into the string immediately after that digit that appears in the integer part of the number and has N digits between it and the decimal-separatorXP31 character, if there is such a digit.

  11. For each integer N in the fractional-part-grouping-positions list, a grouping-separatorXP31 character is inserted into the string immediately before that digit that appears in the fractional part of the number and has N digits between it and the decimal-separatorXP31 character, if there is such a digit.

  12. If there is no decimal-separatorXP31 character in the sub-picture, or if there are no digits to the right of the decimal-separator character in the string, then the decimal-separator character is removed from the string (it will be the rightmost character in the string).

  13. If an exponent exists, then the string produced from the mantissa as described above is extended with the following, in order: (a) the exponent-separatorXP31 character; (b) if the exponent is negative, the minus-signXP31 character; (c) the value of the exponent represented as a decimal integer, extended if necessary with leading zeroes to make it up to the minimum exponent size, using digits taken from the ·decimal digit family·.

  14. The result of the function is the concatenation of the appropriate prefix, the string conversion of the number as obtained above, and the appropriate suffix.

4.8 Trigonometric and exponential functions

The functions in this section perform trigonometric and other mathematical calculations on xs:double values. They are provided primarily for use in applications performing geometrical computation, for example when generating SVG graphics.

Functions are provided to support the six most commonly used trigonometric calculations: sine, cosine and tangent, and their inverses arc sine, arc cosine, and arc tangent. Other functions such as secant, cosecant, and cotangent are not provided because they are easily computed in terms of these six.

The functions in this section (with the exception of math:pi) are specified by reference to [IEEE 754-2019], where they appear as Recommended operations in section 9. IEEE defines these functions for a variety of floating point formats; this specification defines them only for xs:double values. The IEEE specification applies with the following caveats:

  1. IEEE states that the preferred quantum is language-defined. In this specification, it is ·implementation-defined·.

  2. IEEE states that certain functions should raise the inexact exception if the result is inexact. In this specification, this exception if it occurs does not result in an error. Any diagnostic information is outside the scope of this specification.

  3. IEEE defines various rounding algorithms for inexact results, and states that the choice of rounding direction, and the mechanisms for influencing this choice, are language-defined. In this specification, the rounding direction and any mechanisms for influencing it are ·implementation-defined·.

  4. Certain operations (such as taking the square root of a negative number) are defined in IEEE to signal the invalid operation exception and return a quiet NaN. In this specification, such operations return NaN and do not raise an error. The same policy applies to operations (such as taking the logarithm of zero) that raise a divide-by-zero exception. Any diagnostic information is outside the scope of this specification.

  5. Operations whose mathematical result is greater than the largest finite xs:double value are defined in IEEE to signal the overflow exception; operations whose mathematical result is closer to zero than the smallest non-zero xs:double value are similarly defined in IEEE to signal the underflow exception. The treatment of these exceptions in this specification is defined in 4.2 Arithmetic operators on numeric values.

Function Meaning
math:pi Returns an approximation to the mathematical constant π.
math:e Returns an approximation to the mathematical constant e.
math:exp Returns the value of ex where x is the argument value.
math:exp10 Returns the value of 10x, where x is the supplied argument value.
math:log Returns the natural logarithm of the argument.
math:log10 Returns the base-ten logarithm of the argument.
math:pow Returns the result of raising the first argument to the power of the second.
math:sqrt Returns the non-negative square root of the argument.
math:sin Returns the sine of the argument. The argument is an angle in radians.
math:cos Returns the cosine of the argument. The argument is an angle in radians.
math:tan Returns the tangent of the argument. The argument is an angle in radians.
math:asin Returns the arc sine of the argument.
math:acos Returns the arc cosine of the argument.
math:atan Returns the arc tangent of the argument.
math:atan2 Returns the angle in radians subtended at the origin by the point on a plane with coordinates (x, y) and the positive x-axis.
math:sinh Returns the hyperbolic sine of the argument.
math:cosh Returns the hyperbolic cosine of the argument.
math:tanh Returns the hyperbolic tangent of the argument.

4.8.1 math:pi

Summary

Returns an approximation to the mathematical constant π.

Signature
math:pi() as xs:double
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

This function returns the xs:double value whose lexical representation is 3.141592653589793e0

Examples
Expression Result
2 * math:pi()
6.283185307179586e0

The expression 60 * (math:pi() div 180) converts an angle of 60 degrees to radians.

4.8.2 math:e

Changes in 4.0  

  1. New in 4.0  [Issues 1196 1216 PRs 1205 1230 14 May 2024]

Summary

Returns an approximation to the mathematical constant e.

Signature
math:e() as xs:double
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

This function returns the xs:double value whose lexical representation is 2.718281828459045e0

Examples
Expression Result
math:pow(math:e(), 0.05 * 3)
1.161834242728283e0

(approximately)

4.8.3 math:exp

Summary

Returns the value of ex where x is the argument value.

Signature
math:exp(
$value as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is the empty sequence, the function returns the empty sequence.

Otherwise the result is the mathematical constant e raised to the power of $value, as defined in the [IEEE 754-2019] specification of the exp function applied to 64-bit binary floating point values.

Notes

The treatment of overflow and underflow is defined in 4.2 Arithmetic operators on numeric values.

Examples
Expression Result
math:exp(())
()
math:exp(0)
1.0e0
math:exp(1)
2.7182818284590455e0

(approximately)

math:exp(2)
7.38905609893065e0
math:exp(-1)
0.36787944117144233e0
math:exp(math:pi())
23.140692632779267e0
math:exp(xs:double('NaN'))
xs:double('NaN')
math:exp(xs:double('INF'))
xs:double('INF')
math:exp(xs:double('-INF'))
0.0e0

4.8.4 math:exp10

Summary

Returns the value of 10x, where x is the supplied argument value.

Signature
math:exp10(
$value as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is the empty sequence, the function returns the empty sequence.

Otherwise the result is ten raised to the power of $value, as defined in the [IEEE 754-2019] specification of the exp10 function applied to 64-bit binary floating point values.

Notes

The treatment of overflow and underflow is defined in 4.2 Arithmetic operators on numeric values.

Examples
Expression Result
math:exp10(())
()
math:exp10(0)
1.0e0
math:exp10(1)
1.0e1
math:exp10(0.5)
3.1622776601683795e0
math:exp10(-1)
1.0e-1
math:exp10(xs:double('NaN'))
xs:double('NaN')
math:exp10(xs:double('INF'))
xs:double('INF')
math:exp10(xs:double('-INF'))
0.0e0

4.8.5 math:log

Summary

Returns the natural logarithm of the argument.

Signature
math:log(
$value as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is the empty sequence, the function returns the empty sequence.

Otherwise the result is the natural logarithm of $value, as defined in the [IEEE 754-2019] specification of the log function applied to 64-bit binary floating point values.

Notes

The treatment of divideByZero and invalidOperation exceptions is defined in 4.2 Arithmetic operators on numeric values. The effect is that if the argument is zero, the result is -INF, and if it is negative, the result is NaN.

Examples
Expression Result
math:log(())
()
math:log(0)
xs:double('-INF')
math:log(math:exp(1))
1.0e0
math:log(1.0e-3)
-6.907755278982137e0
math:log(2)
0.6931471805599453e0
math:log(-1)
xs:double('NaN')
math:log(xs:double('NaN'))
xs:double('NaN')
math:log(xs:double('INF'))
xs:double('INF')
math:log(xs:double('-INF'))
xs:double('NaN')

4.8.6 math:log10

Summary

Returns the base-ten logarithm of the argument.

Signature
math:log10(
$value as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is the empty sequence, the function returns the empty sequence.

Otherwise the result is the base-10 logarithm of $value, as defined in the [IEEE 754-2019] specification of the log10 function applied to 64-bit binary floating point values.

Notes

The treatment of divideByZero and invalidOperation exceptions is defined in 4.2 Arithmetic operators on numeric values. The effect is that if the argument is zero, the result is -INF, and if it is negative, the result is NaN.

Examples
Expression Result
math:log10(())
()
math:log10(0)
xs:double('-INF')
math:log10(1.0e3)
3.0e0
math:log10(1.0e-3)
-3.0e0
math:log10(2)
0.3010299956639812e0
math:log10(-1)
xs:double('NaN')
math:log10(xs:double('NaN'))
xs:double('NaN')
math:log10(xs:double('INF'))
xs:double('INF')
math:log10(xs:double('-INF'))
xs:double('NaN')

4.8.7 math:pow

Summary

Returns the result of raising the first argument to the power of the second.

Signature
math:pow(
$x as xs:double?,
$y as xs:numeric
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $x is the empty sequence, the function returns the empty sequence.

If $y is an instance of xs:integer, the result is $x raised to the power of $y as defined in the [IEEE 754-2019] specification of the pown function applied to a 64-bit binary floating point value and an integer.

Otherwise $y is converted to an xs:double by numeric promotion, and the result is $x raised to the power of $y as defined in the [IEEE 754-2019] specification of the pow function applied to two 64-bit binary floating point values.

Notes

The treatment of the divideByZero and invalidOperation exceptions is defined in 4.2 Arithmetic operators on numeric values. Some of the consequences are illustrated in the examples below.

Examples
Expression Result
math:pow((), 93.7)
()
math:pow(2, 3)
8.0e0
math:pow(-2, 3)
-8.0e0
math:pow(2, -3)
0.125e0
math:pow(-2, -3)
-0.125e0
math:pow(2, 0)
1.0e0
math:pow(0, 0)
1.0e0
math:pow(xs:double('INF'), 0)
1.0e0
math:pow(xs:double('NaN'), 0)
1.0e0
math:pow(-math:pi(), 0)
1.0e0
math:pow(0e0, 3)
0.0e0
math:pow(0e0, 4)
0.0e0
math:pow(-0e0, 3)
-0.0e0
math:pow(0, 4)
0.0e0
math:pow(0e0, -3)
xs:double('INF')
math:pow(0e0, -4)
xs:double('INF')
math:pow(-0e0, -3)
xs:double('-INF')
math:pow(0, -4)
xs:double('INF')
math:pow(16, 0.5e0)
4.0e0
math:pow(16, 0.25e0)
2.0e0
math:pow(0e0, -3.0e0)
xs:double('INF')
math:pow(-0e0, -3.0e0)
xs:double('-INF')

(Odd-valued whole numbers are treated specially).

math:pow(0e0, -3.1e0)
xs:double('INF')
math:pow(-0e0, -3.1e0)
xs:double('INF')
math:pow(0e0, 3.0e0)
0.0e0
math:pow(-0e0, 3.0e0)
-0.0e0

(Odd-valued whole numbers are treated specially).

math:pow(0e0, 3.1e0)
0.0e0
math:pow(-0e0, 3.1e0)
0.0e0
math:pow(-1, xs:double('INF'))
1.0e0
math:pow(-1, xs:double('-INF'))
1.0e0
math:pow(1, xs:double('INF'))
1.0e0
math:pow(1, xs:double('-INF'))
1.0e0
math:pow(1, xs:double('NaN'))
1.0e0
math:pow(-2.5e0, 2.0e0)
6.25e0
math:pow(-2.5e0, 2.00000001e0)
xs:double('NaN')

4.8.8 math:sqrt

Summary

Returns the non-negative square root of the argument.

Signature
math:sqrt(
$value as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is the empty sequence, the function returns the empty sequence.

Otherwise the result is the mathematical non-negative square root of $value as defined in the [IEEE 754-2019] specification of the squareRoot function applied to 64-bit binary floating point values.

Notes

The treatment of the invalidOperation exception is defined in 4.2 Arithmetic operators on numeric values. The effect is that if the argument is less than zero, the result is NaN.

If $value is positive or negative zero, positive infinity, or NaN, then the result is $value. (Negative zero is the only case where the result can have negative sign)

Examples
Expression Result
math:sqrt(())
()
math:sqrt(0.0e0)
0.0e0
math:sqrt(-0.0e0)
-0.0e0
math:sqrt(1.0e6)
1.0e3
math:sqrt(2.0e0)
1.4142135623730951e0
math:sqrt(-2.0e0)
xs:double('NaN')
math:sqrt(xs:double('NaN'))
xs:double('NaN')
math:sqrt(xs:double('INF'))
xs:double('INF')
math:sqrt(xs:double('-INF'))
xs:double('NaN')

4.8.9 math:sin

Summary

Returns the sine of the argument. The argument is an angle in radians.

Signature
math:sin(
$radians as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $radians is the empty sequence, the function returns the empty sequence.

Otherwise the result is the sine of $radians (which is treated as an angle in radians) as defined in the [IEEE 754-2019] specification of the sin function applied to 64-bit binary floating point values.

Notes

The treatment of the invalidOperation and underflow exceptions is defined in 4.2 Arithmetic operators on numeric values.

If $radians is positive or negative zero, the result is $radians.

If $radians is positive or negative infinity, or NaN, then the result is NaN.

Otherwise the result is always in the range -1.0e0 to +1.0e0

Examples
Expression Result
math:sin(())
()
math:sin(0)
0.0e0
math:sin(-0.0e0)
-0.0e0
math:sin(math:pi() div 2)
1.0e0

(approximately)

math:sin(-math:pi() div 2)
-1.0e0

(approximately)

math:sin(math:pi())
0.0e0

(approximately)

math:sin(xs:double('NaN'))
xs:double('NaN')
math:sin(xs:double('INF'))
xs:double('NaN')
math:sin(xs:double('-INF'))
xs:double('NaN')

4.8.10 math:cos

Summary

Returns the cosine of the argument. The argument is an angle in radians.

Signature
math:cos(
$radians as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $radians is the empty sequence, the function returns the empty sequence.

If $radians is positive or negative infinity, or NaN, then the result is NaN.

Otherwise the result is the cosine of $radians (which is treated as an angle in radians) as defined in the [IEEE 754-2019] specification of the cos function applied to 64-bit binary floating point values.

Notes

The treatment of the invalidOperation exception is defined in 4.2 Arithmetic operators on numeric values.

If $radians is positive or negative zero, the result is $radians.

If $radiansis positive or negative infinity, or NaN, then the result is NaN.

Otherwise the result is always in the range -1.0e0 to +1.0e0

Examples
Expression Result
math:cos(())
()
math:cos(0)
1.0e0
math:cos(-0.0e0)
1.0e0
math:cos(math:pi() div 2)
0.0e0

(approximately)

math:cos(-math:pi() div 2)
0.0e0

(approximately)

math:cos(math:pi())
-1.0e0

(approximately)

math:cos(xs:double('NaN'))
xs:double('NaN')
math:cos(xs:double('INF'))
xs:double('NaN')
math:cos(xs:double('-INF'))
xs:double('NaN')

4.8.11 math:tan

Summary

Returns the tangent of the argument. The argument is an angle in radians.

Signature
math:tan(
$radians as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $radians is the empty sequence, the function returns the empty sequence.

Otherwise the result is the tangent of $radians (which is treated as an angle in radians) as defined in the [IEEE 754-2019] specification of the tan function applied to 64-bit binary floating point values.

Notes

The treatment of the invalidOperation and underflow exceptions is defined in 4.2 Arithmetic operators on numeric values.

If $radians is positive or negative infinity, or NaN, then the result is NaN.

Examples
Expression Result
math:tan(())
()
math:tan(0)
0.0e0
math:tan(-0.0e0)
-0.0e0
math:tan(math:pi() div 4)
1.0e0

(approximately)

math:tan(-math:pi() div 4)
-1.0e0

(approximately)

1 div math:tan(math:pi() div 2)
0.0e0

(approximately)

(Mathematically, tan(π/2) is positive infinity. But because math:pi() div 2 returns an approximation, the result of math:tan(math:pi() div 2) will be a large but finite number.)

1 div math:tan(-math:pi() div 2)
-0.0e0

(approximately)

(Mathematically, tan(-π/2) is negative infinity. But because -math:pi() div 2 returns an approximation, the result of math:tan(-math:pi() div 2) will be a large but finite negative number.)

math:tan(math:pi())
0.0e0

(approximately)

math:tan(xs:double('NaN'))
xs:double('NaN')
math:tan(xs:double('INF'))
xs:double('NaN')
math:tan(xs:double('-INF'))
xs:double('NaN')

4.8.12 math:asin

Summary

Returns the arc sine of the argument.

Signature
math:asin(
$value as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is the empty sequence, the function returns the empty sequence.

Otherwise the result is the arc sine of $value as defined in the [IEEE 754-2019] specification of the asin function applied to 64-bit binary floating point values. The result is in the range -π/2 to +π/2 radians.

Notes

The treatment of the invalidOperation and underflow exceptions is defined in 4.2 Arithmetic operators on numeric values.

If $value is positive or negative zero, the result is $value.

If $value is NaN, or if its absolute value is greater than one, then the result is NaN.

In other cases, the result is an xs:double value representing an angle θ in radians in the range -math:pi() div 2 <= θ <= math:pi() div 2.

Examples
Expression Result
math:asin(())
()
math:asin(0)
0.0e0
math:asin(-0.0e0)
-0.0e0
math:asin(1.0e0)
1.5707963267948966e0

(approximately)

math:asin(-1.0e0)
-1.5707963267948966e0

(approximately)

math:asin(2.0e0)
xs:double('NaN')
math:asin(xs:double('NaN'))
xs:double('NaN')
math:asin(xs:double('INF'))
xs:double('NaN')
math:asin(xs:double('-INF'))
xs:double('NaN')

4.8.13 math:acos

Summary

Returns the arc cosine of the argument.

Signature
math:acos(
$value as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is the empty sequence, the function returns the empty sequence.

Otherwise the result is the arc cosine of $value, as defined in the [IEEE 754-2019] specification of the acos function applied to 64-bit binary floating point values. The result is in the range zero to +π radians.

Notes

The treatment of the invalidOperation exception is defined in 4.2 Arithmetic operators on numeric values.

If $value is NaN, or if its absolute value is greater than one, then the result is NaN.

In other cases, the result is an xs:double value representing an angle θ in radians in the range 0 <= θ <= math:pi().

Examples
Expression Result
math:acos(())
()
math:acos(0)
1.5707963267948966e0

(approximately)

math:acos(-0.0e0)
1.5707963267948966e0

(approximately)

math:acos(1.0e0)
0.0e0
math:acos(-1.0e0)
3.141592653589793e0

(approximately)

math:acos(2.0e0)
xs:double('NaN')
math:acos(xs:double('NaN'))
xs:double('NaN')
math:acos(xs:double('INF'))
xs:double('NaN')
math:acos(xs:double('-INF'))
xs:double('NaN')

4.8.14 math:atan

Summary

Returns the arc tangent of the argument.

Signature
math:atan(
$value as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is the empty sequence, the function returns the empty sequence.

Otherwise the result is the arc tangent of $value, as defined in the [IEEE 754-2019] specification of the atan function applied to 64-bit binary floating point values. The result is in the range -π/2 to +π/2 radians.

Notes

The treatment of the underflow exception is defined in 4.2 Arithmetic operators on numeric values.

If $value is positive or negative zero, the result is $value.

If $value is NaN then the result is NaN.

In other cases, the result is an xs:double value representing an angle θ in radians in the range -math:pi() div 2 <= θ <= math:pi() div 2.

Examples
Expression Result
math:atan(())
()
math:atan(0)
0.0e0
math:atan(-0.0e0)
-0.0e0
math:atan(1.0e0)
0.7853981633974483e0

(approximately)

math:atan(-1.0e0)
-0.7853981633974483e0

(approximately)

math:atan(xs:double('NaN'))
xs:double('NaN')
math:atan(xs:double('INF'))
1.5707963267948966e0

(approximately)

math:atan(xs:double('-INF'))
-1.5707963267948966e0

(approximately)

4.8.15 math:atan2

Summary

Returns the angle in radians subtended at the origin by the point on a plane with coordinates (x, y) and the positive x-axis.

Signature
math:atan2(
$y as xs:double,
$x as xs:double
) as xs:double
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

The result is the value of atan2(y, x) as defined in the [IEEE 754-2019] specification of the atan2 function applied to 64-bit binary floating point values. The result is in the range -π to +π radians.

Notes

The treatment of the underflow exception is defined in 4.2 Arithmetic operators on numeric values. The following rules apply when the values are finite and non-zero, (subject to rules for overflow, underflow and approximation).

If either argument is NaN then the result is NaN.

If $x is positive, then the value of atan2($y, $x) is atan($y div $x).

If $x is negative, then:

  • If $y is positive, then the value of atan2($y, $x) is atan($y div $x) + π.

  • If $y is negative, then the value of atan2($y, $x) is atan($y div $x) - π.

Some results for special values of the arguments are shown in the examples below.

Examples
Expression Result
math:atan2(+0.0e0, 0.0e0)
0.0e0
math:atan2(-0.0e0, 0.0e0)
-0.0e0
math:atan2(+0.0e0, -0.0e0)
3.141592653589793e0
math:atan2(-0.0e0, -0.0e0)
-3.141592653589793e0
math:atan2(-1, 0.0e0)
-1.5707963267948966e0
math:atan2(+1, 0.0e0)
1.5707963267948966e0
math:atan2(-0.0e0, -1)
-3.141592653589793e0
math:atan2(+0.0e0, -1)
3.141592653589793e0
math:atan2(-0.0e0, +1)
-0.0e0
math:atan2(+0.0e0, +1)
+0.0e0

4.8.16 math:sinh

Changes in 4.0  

  1. New in 4.0  [Issues 1196 1216 PRs 1205 1230 14 May 2024]

Summary

Returns the hyperbolic sine of the argument.

Signature
math:sinh(
$value as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is the empty sequence, the function returns the empty sequence.

Otherwise the result is the hyperbolic sine of $value as defined in the [IEEE 754-2019] specification of the sinh function applied to 64-bit binary floating point values.

Notes

The treatment of the overflow and underflow exceptions is defined in 4.2 Arithmetic operators on numeric values.

If $value is positive or negative zero, the result is $value.

If $value is positive or negative infinity, or NaN, the result is NaN.

Examples
Expression Result
math:sinh(1)
1.1752011936438014e0

(approximately)

math:sinh(math:pi())
11.548739357257748e0

(approximately)

4.8.17 math:cosh

Changes in 4.0  

  1. New in 4.0  [Issues 1196 1216 PRs 1205 1230 14 May 2024]

Summary

Returns the hyperbolic cosine of the argument.

Signature
math:cosh(
$value as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is the empty sequence, the function returns the empty sequence.

Otherwise the result is the hyperbolic cosine of $value as defined in the [IEEE 754-2019] specification of the cosh function applied to 64-bit binary floating point values.

Notes

The treatment of the overflow exception is defined in 4.2 Arithmetic operators on numeric values.

If $value is positive or negative zero, the result is 1.

If $value is positive or negative infinity, the result is INF.

If $value is NaN, the result is NaN.

In other cases, the result is an xs:double in the range +1.0 to INF.

Examples
Expression Result
math:cosh(0)
1.0e0
math:cosh(math:pi())
11.591953275521519e0

(approximately)

4.8.18 math:tanh

Changes in 4.0  

  1. New in 4.0  [Issues 1196 1216 PRs 1205 1230 14 May 2024]

Summary

Returns the hyperbolic tangent of the argument.

Signature
math:tanh(
$value as xs:double?
) as xs:double?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If $value is the empty sequence, the function returns the empty sequence.

Otherwise the result is the hyperbolic tangent of $value as defined in the [IEEE 754-2019] specification of the tanh function applied to 64-bit binary floating point values.

Notes

The treatment of the underflow exception is defined in 4.2 Arithmetic operators on numeric values.

If $value is positive or negative zero, the result is $value.

If $value is positive infinity, the result is +1.0.

If $value is negative infinity, the result is -1.0.

In other cases, the result is an xs:double in the range -1.0 to +1.0.

Examples
Expression Result
math:tanh(1)
0.7615941559557649e0

(approximately)

math:tanh(math:pi())
0.99627207622075e0

(approximately)

4.9 Random Numbers

Function Meaning
fn:random-number-generator Returns a random number generator, which can be used to generate sequences of random numbers.

4.9.1 fn:random-number-generator

Changes in 4.0  

  1. The 3.1 specification suggested that every value in the result range should have the same chance of being chosen. This has been corrected to say that the distribution should be arithmetically uniform (because there are as many xs:double values between 0.01 and 0.1 as there are between 0.1 and 1.0).

Summary

Returns a random number generator, which can be used to generate sequences of random numbers.

Signature
fn:random-number-generator(
$seed as xs:anyAtomicType? := ()
) as random-number-generator-record
record random-number-generator-record (
   number as xs:double,
   next as fn() as random-number-generator-record,
   permute as function(item()*) as item()*
)
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

The function returns a random number generator. A random number generator is represented as a value of type random-number-generator-record, defined as follows:

Name Meaning

number

An xs:double greater than or equal to zero (0.0e0), and less than one (1.0e0).

  • Type: xs:double

next

A zero-arity function that can be called to return another random number generator.

The properties of this function are as follows:

  • name: absent

  • parameter names: ()

  • signature: () => map(xs:string, item())

  • non-local variable bindings: none

  • implementation: implementation-dependent

  • Type: fn() as random-number-generator-record

permute

A function with arity 1 (one), which takes an arbitrary sequence as its argument, and returns a random permutation of that sequence.

The properties of this function are as follows:

  • name: absent

  • parameter names: "arg"

  • signature: (item()*) => item()*

  • non-local variable bindings: none

  • body: implementation-dependent

  • Type: function(item()*) as item()*

Calling the fn:random-number-generator function with no arguments is equivalent to calling the single-argument form of the function with an implementation-dependent seed.

Calling the fn:random-number-generator function with an empty sequence as $seed is equivalent to calling the single-argument form of the function with an implementation-dependent seed.

If a $seed is supplied, it may be an atomic item of any type.

Both forms of the function are ·deterministic·: calling the function twice with the same arguments, within a single ·execution scope·, produces the same results.

The value of the number entry should be such that the distribution of numbers is uniform: for example, the probability of the number being in the range 0.1e0 to 0.2e0 is the same as the probability of its being in the range 0.8e0 to 0.9e0.

The function returned in the permute entry should be such that all permutations of the supplied sequence are equally likely to be chosen.

The map returned by the fn:random-number-generator function may contain additional entries beyond those specified here, but it must match the record type defined above. The meaning of any additional entries is ·implementation-defined·. To avoid conflict with any future version of this specification, the keys of any such entries should start with an underscore character.

Notes

It is not meaningful to ask whether the functions returned in the next and permute functions resulting from two separate calls with the same seed are “the same function”, but the functions must be equivalent in the sense that calling them produces the same sequence of random numbers.

The repeatability of the results of function calls in different execution scopes is outside the scope of this specification. It is recommended that when the same seed is provided explicitly, the same random number sequence should be delivered even in different execution scopes; while if no seed is provided, the processor should choose a seed that is likely to be different from one execution scope to another. (The same effect can be achieved explicitly by using fn:current-dateTime() as a seed.)

The specification does not place strong conformance requirements on the actual randomness of the result; this is left to the implementation. It is desirable, for example, when generating a sequence of random numbers that the sequence should not get into a repeating loop; but the specification does not attempt to dictate this.

Examples

The following example returns a random permutation of the integers in the range 1 to 100:

random-number-generator()?permute(1 to 100)

The following example returns a 10% sample of the items in an input sequence $seq, chosen at random:

random-number-generator()?permute($seq)[1 to (count($seq) idiv 10)]

The following XQuery code produces a random sequence of 200 xs:double values in the range zero to one:

declare %public function local:random-sequence($length as xs:integer) as xs:double* {
  local:random-sequence($length, random-number-generator())
};
declare %private function local:random-sequence(
  $length as xs:integer, 
  $record as record(number as xs:double, next as fn(*), *)
) as xs:double* {
  if ($length != 0) {
    $record?number,
    local:random-sequence($length - 1, $record?next())
  }
};
local:random-sequence(200)

An equivalent result can be achieved with fn:fold-left:

tail(fold-left(
  (1 to 200),
  random-number-generator(),
  fn($result) { head($result) ! (?next(), ?number), tail($result) }
))

5 Functions on strings

This section specifies functions and operators on the [XML Schema Part 2: Datatypes Second Edition] xs:string datatype and the datatypes derived from it.

5.1 String types

The operators described in this section are defined on the following types.

    • string

      • normalizedString

        • token

          • language

          • NMTOKEN

          • Name

            • NCName

              • ENTITY

              • ID

              • IDREF

Legend:

  • Supertype

    • subtype

  • Built-in atomic types

They also apply to user-defined types derived by restriction from the above types.

5.2 Functions to assemble and disassemble strings

Function Meaning
fn:codepoints-to-string Returns an xs:string whose characters have supplied ·codepoints·.
fn:string-to-codepoints Returns the sequence of ·codepoints· that constitute an xs:string value.

5.2.1 fn:codepoints-to-string

Summary

Returns an xs:string whose characters have supplied ·codepoints·.

Signature
fn:codepoints-to-string(
$values as xs:integer*
) as xs:string
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

The function returns the string made up from the ·characters· whose Unicode ·codepoints· are supplied in $values. This will be the zero-length string if $values is the empty sequence.

Error Conditions

A dynamic error is raised [err:FOCH0001] if any of the codepoints in $values is not a ·permitted character·.

Examples
Expression Result
codepoints-to-string((66, 65, 67, 72))
"BACH"
codepoints-to-string((2309, 2358, 2378, 2325))
"अशॊक"
codepoints-to-string(())
""
codepoints-to-string(0)

Raises error FOCH0001.

5.2.2 fn:string-to-codepoints

Summary

Returns the sequence of ·codepoints· that constitute an xs:string value.

Signature
fn:string-to-codepoints(
$value as xs:string?
) as xs:integer*
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

The function returns a sequence of integers, each integer being the Unicode ·codepoint· of the corresponding ·character· in $value.

If $value is a zero-length string or the empty sequence, the function returns the empty sequence.

Examples
Expression Result
string-to-codepoints("Thérèse")
(84, 104, 233, 114, 232, 115, 101)

5.3 Comparison of strings

Function Meaning
fn:codepoint-equal Returns true if two strings are equal, considered codepoint-by-codepoint.
fn:collation Constructs a collation URI with requested properties.
fn:collation-available Asks whether a collation URI is recognized by the implementation.
fn:collation-key Given a string value and a collation, generates an internal value called a collation key, with the property that the matching and ordering of collation keys reflects the matching and ordering of strings under the specified collation.
fn:contains-token Determines whether or not any of the supplied strings, when tokenized at whitespace boundaries, contains the supplied token, under the rules of the supplied collation.

5.3.1 Collations

A collation is a specification of the manner in which ·strings· are compared and, by extension, ordered. When values whose type is xs:string or a type derived from xs:string are compared (or, equivalently, sorted), the comparisons are inherently performed according to some collation (even if that collation is defined entirely on codepoint values). The [Character Model for the World Wide Web 1.0: Fundamentals] observes that some applications may require different comparison and ordering behaviors than other applications. Similarly, some users having particular linguistic expectations may require different behaviors than other users. Consequently, the collation must be taken into account when comparing strings in any context. Several functions in this and the following section make use of a collation.

Collations can indicate that two different codepoints are, in fact, equal for comparison purposes (e.g., “v” and “w” are considered equivalent in some Swedish collations). Strings can be compared codepoint-by-codepoint or in a linguistically appropriate manner, as defined by the collation.

Some collations, especially those based on the Unicode Collation Algorithm (see [UTS #10]) can be “tailored” for various purposes. This document does not discuss such tailoring, nor does it provide a mechanism to perform tailoring. Instead, it assumes that the collation argument to the various functions below is a tailored and named collation.

The ·Unicode codepoint collation· is a collation available in every implementation, which sorts based on codepoint values. For further details see 5.3.2 The Unicode Codepoint Collation.

Collations may or may not perform Unicode normalization on strings before comparing them.

This specification assumes that collations are named and that the collation name may be provided as an argument to string functions. Functions that allow specification of a collation do so with an argument whose type is xs:string but whose lexical form must conform to an xs:anyURI. This specification also defines the manner in which a default collation is determined if the collation argument is not specified in calls of functions that use a collation but allow it to be omitted.

If the collation is specified using a relative URI reference, it is resolved relative to an ·implementation-defined· base URI.

Note:

Previous versions of this specification stated that it must be resolved against the Static Base URIXP40, but this is not always operationally convenient. It is recommended that processors should provide a means of setting the base URI for resolving collation URIs independently of the Static Base URIXP40, though for backwards compatibility, the Static Base URIXP40 or Executable Base URIXP40 should be used as a default.

This specification does not define whether or not the collation URI is dereferenced. The collation URI may be an abstract identifier, or it may refer to an actual resource describing the collation. If it refers to a resource, this specification does not define the nature of that resource. One possible candidate is that the resource is a locale description expressed using the Locale Data Markup Language: see [UTS #35].

Functions such as fn:compare and fn:max that compare xs:string values use a single collation URI to identify all aspects of the collation rules. This means that any parameters such as the strength of the collation must be specified as part of the collation URI. For example, suppose there is a collation http://www.example.com/collations/French that refers to a French collation that compares on the basis of base characters. Collations that use the same basic rules, but with higher strengths, for example, base characters and accents, or base characters, accents and case, would need to be given different names, say http://www.example.com/collations/French1 and http://www.example.com/collations/French2. Note that some specifications use the term collation to refer to an algorithm that can be parameterized, but in this specification, each possible parameterization is considered to be a distinct collation.

The XQuery/XPath static context includes a provision for a default collation that can be used for string comparisons and ordering operations. See the description of the static context in Section 2.1.1 Static Context XP31. If the default collation is not specified by the user or the system, the default collation is the ·Unicode codepoint collation·.

Note:

XML allows elements to specify the xml:lang attribute to indicate the language associated with the content of such an element. This specification does not use xml:lang to identify the default collation because using xml:lang does not produce desired effects when the two strings to be compared have different xml:lang values or when a string is multilingual.

5.3.2 The Unicode Codepoint Collation

[Definition] The collation URI http://www.w3.org/2005/xpath-functions/collation/codepoint identifies a collation which must be recognized by every implementation: it is referred to as the Unicode codepoint collation (not to be confused with the Unicode collation algorithm).

The Unicode codepoint collation does not perform any normalization on the supplied strings.

The collation is defined as follows. Each of the two strings is converted to a sequence of integers using the fn:string-to-codepoints function. These two sequences $A and $B are then compared as follows:

  1. If both sequences are empty, the strings are equal.

  2. If one sequence is empty and the other is not, then the string corresponding to the empty sequence is less than the other string.

  3. If the first integer in $A is less than the first integer in $B, then the string corresponding to $A is less than the string corresponding to $B.

  4. If the first integer in $A is greater than the first integer in $B, then the string corresponding to $A is greater than the string corresponding to $B.

  5. Otherwise (the first pair of integers are equal), the result is obtained by applying the same rules recursively to fn:tail($A) and fn:tail($B)

Note:

While the Unicode codepoint collation does not produce results suitable for quality publishing of printed indexes or directories, it is adequate for many purposes where a restricted alphabet is used, such as sorting of vehicle registrations.

5.3.3 The Unicode Collation Algorithm

This specification defines a family of collation URIs representing tailorings of the Unicode Collation Algorithm (UCA) as defined in [UTS #10]. The parameters used for tailoring the UCA are based on the parameters defined in the Locale Data Markup Language (LDML), defined in [UTS #35].

This family of URIs use the scheme and path http://www.w3.org/2013/collation/UCA followed by an optional query part. The query part, if present, consists of a question mark followed by a sequence of zero or more semicolon-separated parameters. Each parameter is a keyword-value pair, the keyword and value being separated by an equals sign.

All implementations must recognize URIs in this family in the collation argument of functions that take a collation argument.

If the fallback parameter is present with the value no, then the implementation must either use a collation that conforms with the rules in the Unicode specifications for the requested tailoring, or fail with a static or dynamic error indicating that it does not provide the collation (the error code should be the same as if the collation URI were not recognized). If the fallback parameter is omitted or takes the value yes, and if the collation URI is well-formed according to the rules in this section, then the implementation must accept the collation URI, and should use the available collation that most closely reflects the user’s intentions. For example, if the collation URI requested is http://www.w3.org/2013/collation/UCA?lang=se;fallback=yes and the implementation does not include a fully conformant version of the UCA tailored for Swedish, then it may choose to use a Swedish collation that is known to differ from the UCA definition, or one whose conformance has not been established. It might even, as a last resort, fall back to using codepoint collation.

If two query parameters use the same keyword then the last one wins. If a query parameter uses a keyword or value which is not defined in this specification then the meaning is ·implementation-defined·. If the implementation recognizes the meaning of the keyword and value then it should interpret it accordingly; if it does not recognize the keyword or value then if the fallback parameter is present with the value no it should reject the collation as unsupported, otherwise it should ignore the unrecognized parameter.

The following query parameters are defined. If any parameter is absent, the default is ·implementation-defined· except where otherwise stated. The meaning given for each parameter is non-normative; the normative specification is found in [UTS #35].

Keyword Values Meaning
fallback yes | no (default yes) Determines whether the processor uses a fallback collation if a conformant collation is not available.
lang language code: a string in the lexical space of xs:language. The language whose collation conventions are to be used.
version string The version number of the UCA to be used.
strength primary | secondary | tertiary | quaternary | identical, or 1|2|3|4|5 as synonyms (default tertiary / 3) The collation strength as defined in UCA. Primary strength takes only the base form of the character into account (so A=a=Ä=ä); secondary strength ignores case but considers accents and diacritics as significant (so A=a and Ä=ä but ä≠a); tertiary considers case as significant (A≠a≠Ä≠ä); quaternary strength always considers as significant spaces and punctuation (data-base≠database; if maxVariable is punct or higher and alternate is not non-ignorable, lower strengths will treat data-base=database).
maxVariable space | punct | symbol | currency (default punct) Given the sequence space, punct, symbol, currency, all characters in the specified group and earlier groups are treated as “noise” characters to be handled as defined by the alternate parameter. For example, maxVariable=punct indicates that characters classified as whitespace or punctuation get this treatment.
alternate non-ignorable | shifted | blanked (default non-ignorable) Controls the handling of characters such as spaces and hyphens; specifically, the "noise" characters in the groups selected by the maxVariable parameter. The value non-ignorable indicates that such characters are treated as distinct at the primary level (so data base sorts before database); shifted indicates that they are used to differentiate two strings only at the quaternary level, and blanked indicates that they are taken into account only at the identical level.
backwards yes | no (default no) The value backwards=yes indicates that the last accent in the string is the most significant.
normalization yes | no (default no) Indicates whether strings are converted to normalization form D.
caseLevel yes | no (default no) When used with primary strength, setting caseLevel=yes has the effect of ignoring accents while taking account of case.
caseFirst upper | lower (default lower) Indicates whether upper-case precedes lower-case or vice versa.
numeric yes | no (default no) When numeric=yes is specified, a sequence of consecutive digits is interpreted as a number, for example chap2 sorts before chap12.
reorder a comma-separated sequence of reorder codes, where a reorder code is one of space, punct, symbol, currency, digit, or a four-letter script code defined in [ISO 15924 Register], the register of scripts maintained by the Unicode Consortium in its capacity as registration authority for [ISO 15924]. Determines the relative ordering of text in different scripts; for example the value digit,Grek,Latn indicates that digits precede Greek letters, which precede Latin letters.

Note:

This list excludes parameters that are inconvenient to express in a URI, or that are applicable only to substring matching.

UCA collation URIs can be conveniently generated using the fn:collation function.

5.3.4 The HTML ASCII Case-Insensitive Collation

The collation URI http://www.w3.org/2005/xpath-functions/collation/html-ascii-case-insensitive must be recognized by every implementation. It is designed to be compatible with the HTML ASCII case-insensitive collation as defined in [HTML: Living Standard] (section 4.6, Strings), which is used, for example, when matching HTML class attribute values.

The collation is defined as follows:

  • Let $HACI be the collation URI "http://www.w3.org/2005/xpath-functions/collation/html-ascii-case-insensitive".

  • Let $UCC be the Unicode Codepoint Collation URI http://www.w3.org/2005/xpath-functions/collation/codepoint.

  • Let $lc be the function fn:translate(?, "ABCDEFGHIJKLMNOPQRSTUVWXYZ", "abcdefghijklmnopqrstuvwxyz").

  • Then for any two strings $A and $B, the result of the comparison fn:compare($A, $B, $HACI) is defined to be the same as the result of fn:compare($lc($A), $lc($B), $UCC).

Note:

HTML5 defines the semantics of equality matching using this collation; this specification additionally defines ordering rules. The collation supports collation units and can therefore be used with functions such as fn:contains; each Unicode codepoint is a single collation unit.

The corresponding HTML5 definition is: A string A is an ASCII case-insensitive match for a string B, if the ASCII lowercase of A is the ASCII lowercase of B.

5.3.5 Choosing a collation

Many functions have a signature that includes a $collation argument, which is generally optional and takes default-collation() as its default value.

The collation to use for these functions is determined by the following rules:

  1. If the function specifies an explicit collation, CollationA (e.g., if the optional collation argument is specified in a call of the fn:compare function), then:

    • If CollationA is supported by the implementation, then CollationA is used.

    • Otherwise, a dynamic error is raised [err:FOCH0002].

  2. If no collation is explicitly specified for the function (that is, if the $collation argument is omitted or is set to an empty sequence), and the default collation in the XQuery/XPath static context is CollationB, then:

    • If CollationB is supported by the implementation, then CollationB is used.

    • Otherwise, a dynamic error is raised [err:FOCH0002].

Note:

Because the set of collations that are supported is ·implementation-defined·, an implementation has the option to support all collation URIs, in which case it will never raise this error.

If the value of the collation argument is a relative URI reference, it is resolved against the base-URI from the static context. If it is a relative URI reference and cannot be resolved, perhaps because the base-URI property in the static context is absent, a dynamic error is raised [err:FOCH0002].

Note:

There is no explicit requirement that the string used as a collation URI be a valid URI. Implementations will in many cases reject such strings on the grounds that do not identify a supported collation; they may also cause an error if they cannot be resolved against the relevant base URI.

5.3.6 fn:codepoint-equal

Summary

Returns true if two strings are equal, considered codepoint-by-codepoint.

Signature
fn:codepoint-equal(
$value1 as xs:string?,
$value2 as xs:string?
) as xs:boolean?
Properties

This function is ·deterministic·, ·context-independent·, and ·focus-independent·.

Rules

If either argument is the empty sequence, the function returns the empty sequence.

Otherwise, the function returns true or false depending on whether $value1 is equal to $value2, according to the Unicode codepoint collation (http://www.w3.org/2005/xpath-functions/collation/codepoint).

Notes

This function allows xs:anyURI values to be compared without having to specify the Unicode codepoint collation.

Examples
Expression Result
codepoint-equal("abcd", "abcd")
true()
codepoint-equal("abcd", "abcd ")
false()
codepoint-equal("", "")
true()
codepoint-equal("", ())
()
codepoint-equal((), ())
()

5.3.7 fn:collation

Changes in 4.0  

  1. New in 4.0  [Issue 1091 PR 1093 9 April 2024]

Summary

Constructs a collation URI with requested properties.

Signature
fn:collation(
$options as map(*)
) as xs:string
Properties

This function is ·deterministic·, ·context-dependent·, and ·focus-independent·. It depends on collations.

Rules

The function is supplied with a map defining the properties required of the collation, and returns a collation URI with these properties.

Specifically, it returns a string in the form of a URI with the scheme and path http://www.w3.org/2013/collation/UCA followed by an optional query part. The query part is absent if options is empty. Otherwise it consists of a question mark followed by a sequence of one or more semicolon-separated parameters. Each parameter is a keyword-value pair, the keyword and value being separated by an equals sign. There is one keyword-value pair for each entry in the options map: the keyword is the same as the string value of the key in the map, and the value is the string value of the corresponding value, except where the value is of type xs:boolean, in which case true and false are translated to yes and no.

The function does not check whether the implementation actually recognizes the resulting collation URI: that can be achieved using the fn:collation-available function.

The properties available are as defined for the Unicode Collation Algorithm (see 5.3.3 The Unicode Collation Algorithm). Additional ·implementation-defined· properties may be specified as described in the rules for UCA collation URIs.

The ·option parameter conventions· apply, except as regards the handling of options not defined in this specification. Specifically:

  • If the option key is of type xs:string, xs:anyURI, or xs:untypedAtomic then it is converted to a string, and produces a URI query parameter which is handled as described in 5.3.3 The Unicode Collation Algorithm.

  • If the option key is of any other type then the function fails with a type error [err:XPTY0004]XP.

The following options are defined:

record(
fallback? as xs:boolean,
lang? as xs:language,
version? as xs:string,
strength? as enum("primary", "secondary", "tertiary", "quaternary", "identical", "1", "2", "3", "4", "5"),
maxVariable? as enum("space", "punct", "symbol", "currency"),
alternate? as enum("non-ignorable", "shifted", "blanked", "currency"),
backwards? as xs:boolean,
normalization? as xs:boolean,
caseLevel? as xs:boolean,
caseFirst? as enum("upper","lower"),
numeric? as xs:boolean,
reorder? as xs:string
)
Key Meaning

fallback

See 5.3.3 The Unicode Collation Algorithm.
  • Type: xs:boolean

  • Default: true()

lang

See 5.3.3 The Unicode Collation Algorithm.
  • Type: xs:language

  • Default: default-language()

version

See 5.3.3 The Unicode Collation Algorithm.
  • Type: xs:string

  • Default: ()

strength

See 5.3.3 The Unicode Collation Algorithm.
  • Type: enum("primary", "secondary", "tertiary", "quaternary", "identical", "1", "2", "3", "4", "5")

  • Default: ()

maxVariable

See 5.3.3 The Unicode Collation Algorithm.
  • Type: enum("space", "punct", "symbol", "currency")

  • Default: "punct"

alternate

See 5.3.3 The Unicode Collation Algorithm.
  • Type: enum("non-ignorable", "shifted", "blanked", "currency")

  • Default: "non-ignorable"

backwards

See 5.3.3 The Unicode Collation Algorithm.
  • Type: xs:boolean

  • Default: false()

normalization

See 5.3.3 The Unicode Collation Algorithm.
  • Type: xs:boolean

  • Default: false()

caseLevel

See 5.3.3 The Unicode Collation Algorithm.
  • Type: xs:boolean

  • Default: false()

caseFirst

See 5.3.3 The Unicode Collation Algorithm.
  • Type: enum("upper","lower")

  • Default: "lower"

numeric

See 5.3.3 The Unicode Collation Algorithm.
  • Type: xs:boolean

  • Default: false()

reorder

See 5.3.3 The Unicode Collation Algorithm.
  • Type: xs:string

  • Default: ""

Error Conditions

A type error is raised [err:XPTY0004]XP if options includes an entry whose key is not of type xs:string, xs:anyURI, or xs:untypedAtomic, or whose corresponding value is not castable to xs:string.

Examples
Expression:

collation({})

Result:
"http://www.w3.org/2013/collation/UCA"
Expression:

collation(map{'lang':'de'})

Result:
"http://www.w3.org/2013/collation/UCA?lang=de"
Expression:

collation(map{'lang':'de', 'strength':'primary'})

Result:
"http://www.w3.org/2013/collation/UCA?lang=de;strength=primary"

(The order of query parameters may vary.)

The expression collation(map{'lang':default-language()}) returns a collation suitable for the default language in the dynamic context.

5.3.8 fn:collation-available

Changes in 4.0  

  1. New in 4.0  [Issue 1160 PR 1262 9 July 2024]

Summary

Asks whether a collation URI is recognized by the implementation.

Signature
fn:collation-available(
$collation as xs:string,
$usage as enum('equality', 'sort', 'substring')* := ()
) as xs:boolean
Properties

This function is ·deterministic·, ·context-dependent·, and ·focus-independent·. It depends on collations.

Rules

The first argument is a candidate collation URI.

The second argument establishes the intended usage of the collation URI. The value is a sequence containing zero or more of the following:

  • equality indicates that the intended purpose of the collation URI is to compare strings for equality, for example in functions such as fn:index-of or fn:deep-equal.

  • sort indicates that the intended purpose of the collation URI is to sort or compare different strings in a collating sequence, for example in functions such as fn:sort or fn:max.

  • substring indicates that the intended purpose of the collation URI is to establish whether one string is a substring of another, for example in functions such as fn:contains or fn:starts-with.

The function returns true if and only if the implementation recognizes the candidate collation URI as one that can be used for each of the purposes listed in the $usage argument. If the $usage argument is absent or set to an empty sequence, the function returns true only if the collation is available for all purposes.

Notes

If the candidate collation is a UCA collation specifying fallback=yes, then this function will always return true: implementations are required to recognize such a collation and use fallback behavior if there is no direct equivalent available.

Examples
Expression:

collation-available("http://www.w3.org/2013/collation/UCA?lang=de")

Result:
true()
Expression:

collation({ 'lang': 'de' }) => collation-available()

Result:
true()

The expression collation({ 'lang': default-language() }) returns a collation suitable for the default language in the dynamic context.

5.3.9 fn:collation-key

Summary

Given a string value and a collation, generates an internal value called a collation key, with the property that the matching and ordering of collation keys reflects the matching and ordering of strings under the specified collation.

Signature
fn:collation-key(
$value as xs:string,
$collation as xs:string? := fn:default-collation()
) as xs:base64Binary
Properties

This function is ·deterministic·, ·context-dependent·, and ·focus-independent·. It depends on collations.

Rules

Calling the one-argument version of this function is equivalent to calling the two-argument version supplying the default collation as the second argument.

The function returns an ·implementation-dependent· value with the property that, for any two strings $K1 and $K2:

  • collation-key($K1, $C) eq collation-key($K2, $C) if and only if compare($K1, $K2, $C) eq 0

  • collation-key($K1, $C) lt collation-key($K2, $C) if and only if compare($K1, $K2, $C) lt 0

The collation used by this function is determined according to the rules in 5.3.5 Choosing a collation. Collation keys are defined as xs:base64Binary values to ensure unambiguous and context-free comparison semantics.

An implementation is free to generate a collation key in any convenient way provided that it always generates the same collation key for two strings that are equal under the collation, and different collation keys for strings that are not equal. This holds only within a single ·execution scope·; an implementation is under no obligation to generate the same collation keys during a subsequent unrelated query or transformation.

It is possible to define collations that do not have the ability to generate collation keys. Supplying such a collation will cause the function to fail. The ability to generate collation keys is an ·implementation-defined· property of the collation.

Error Conditions

An error is raised [err:FOCH0004] if the specified collation does not support the generation of collation keys.

Notes

The function is provided primarily for use with maps. If a map is required where codepoint equality is inappropriate for comparing keys, then a common technique is to normalize the key so that equality matching becomes feasible. There are many ways keys can be normalized, for example by use of functions such as fn:upper-case, fn:lower-case, fn:normalize-space, or fn:normalize-unicode, but this function provides a way of normalizing them according to the rules of a specified collation. For example, if the collation ignores accents, then the function will generate the same collation key for two input strings that differ only in their use of accents.

The result of the function is defined to be an xs:base64Binary value. Binary values are chosen because they have unambiguous and context-free comparison semantics, because the value space is unbounded, and because the ordering rules are such that between any two values in the ordered value space, an arbitrary number of further values can be interpolated. The choice between xs:base64Binary and xs:hexBinary is arbitrary; the only operation that behaves differently between the two binary data types is conversion to/from a string, and this operation is not one that is normally required for effective use of collation keys.

For collations based on the Unicode Collation Algorithm, an algorithm for computing collation keys is provided in [UTS #10]. Implementations are not required to use this algorithm.

The fact that collation keys are ordered can be exploited in XQuery, whose order by clause does not allow the collation to be selected dynamically. This restriction can be circumvented by rewriting the clause order by $e/@key collation "URI" as order by fn:collation-key($e/@key, $collation), where $collation allows the collation to be chosen dynamically.

Note that xs:base64Binary becomes an ordered type in XPath 3.1, making binary collation keys possible.

Examples
Variables
let $C := collation(map{'strength':'primary'})
Expression:
map:merge(
  ({ collation-key("A", $C): 1 }, { collation-key("a", $C): 2 }),
  { "duplicates": "use-last" }
)(collation-key("A", $C))
Result:
2

(Given that the keys of the two entries are equal under the rules of the chosen collation, only one of the entries can appear in the result; the one that is chosen is the one from the last map in the input sequence.)

Expression:
let $M := {
  collation-key("A", $C): 1,
  collation-key("B", $C): 2
}
return $M(collation-key("a", $C))
Result:
1

(The strings "A" and "a" have the same collation key under this collation.)

As the above examples illustrate, it is important that when the collation-key function is used to add entries to a map, then it must also be used when retrieving entries from the map. This process can be made less error-prone by encapsulating the map within a function: fn($k) { $M(collation-key($k, $collation) }.

5.3.10 fn:contains-token

Summary

Determines whether or not any of the supplied strings, when tokenized at whitespace boundaries, contains the supplied token, under the rules of the supplied collation.

Signature
fn:contains-token(
$value as xs:string*,
$token as xs:string,
$collation as xs:string? := fn:default-collation()
) as xs:boolean
Properties

The two-argument form of this function is ·deterministic·, ·context-dependent·, and ·focus-independent·. It depends on collations.