The Functions and Operators specification is intended primarily as a component that can be used by other specifications. Therefore, Functions and Operators relies on specifications that use it (such as , and ) to specify conformance criteria for their respective environments.

Authors of conformance criteria for the use of the Functions and Operators should pay particular attention to the following features:

The functions and operators discussed in this document are contained in one of three namespaces (see ) and referenced using an xs:QName. The datatypes and constructor functions for the built-in datatypes defined in and in of and discussed in are in the XML Schema namespace, http://www.w3.org/2001/XMLSchema, and named in this document using the xs prefix. The namespace prefix used in this document for functions that are available to users is fn. Operator functions are named with the prefix op.

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.

The namespace prefix used for the functions, datatypes and errors can vary, as long as the prefix is bound to the correct URI.

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

The functions defined with an fn prefix are callable by the user. Functions defined with the op prefix are described here to underpin the definitions of the operators in , and . 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:

In general, the specifications named above do not support function overloading in the sense that functions that have multiple signatures with the same name and the same number of parameters are not supported. Consequently, there are no such overloaded functions in this document except for legacy functions such as fn:string(), which accepts a single parameter of a variety of types. In addition, it should be noted that the functions defined in that accept numeric parameters accept arguments of type xs:integer, xs:decimal, xs:float or xs:double. See . Operators such as "+" may be overloaded. This document does define some functions with more than one signature with the same name and different number of parameters. User-defined functions with more than one signature with the same name and different number of parameters are also supported.

Each function is defined by specifying its signature, a description of the return type and each of the parameters and its semantics. For many functions, examples are included to illustrate their use.

Each function's signature is presented in a form like this:

In this notation, function-name, in bold-face, is the name of the function whose signature is being specified. 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 declaration specifies the static type of the parameter, in italics, and a descriptive, but non-normative, name. 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 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 .

In some cases the word numeric is used in function signatures as a shorthand to indicate the four numeric types: xs:integer, xs:decimal, xs:float and xs:double. For example, a function with the signature represents the following four function signatures:

For most functions there is an initial paragraph describing what the function does followed by semantic rules. These rules are meant to be followed in the order that they appear in this document.

In some cases, the static type returned by a function depends on the type(s) of its argument(s). These special functions are indicated by using bold italics for the return type. The semantic rules specifying the type of the value returned are documented in the function definition. The rules are described more formally in .

The function name is a QName as defined in and must adhere to its syntactic conventions. Following , function names are composed of English words separated by hyphens,"-". If a function name contains a datatype name, it may have intercapitalized spelling and is used in the function name as such. For example, fn:timezone-from-dateTime.

Rules for passing parameters to operators are described in the relevant sections of and . For example, the rules for passing parameters to arithmetic operators are described in . 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 ). In addition, numeric type instances and instances of type xs:anyURI can be promoted to produce an argument of the required type. (See ).

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

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.

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 item, referred to as .. In the second signature, the argument must be present but may be the empty sequence, referred to as ().

Some functions accept a sequence of zero or more values as an argument. This is indicated by following the name of 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.

This document uses the phrase "namespace URI" to identify the concept identified in as "namespace name", and the phrase "local name" to identify the concept identified in as "local part".

It also uses the term expanded-QName defined below.

The diagram below shows the types for which functions are defined in this document. These include the built-in types defined by (shown on the right) as well as types defined in (shown on the left). Solid lines connect a base datatype above to a derived datatype.xs:IDREFS, xs:NMTOKENS, xs:ENTITIES and user-defined list and union types are special types in that these types are lists or unions rather than true subtypes. Dashed lines connect a union type above with its component types below.

The terminology used to describe the functions and operators on is defined in the body of this specification. The terms defined in the following list are used in building those definitions:

Summary: Returns an expanded-QName for node kinds that can have names. For other kinds of nodes it returns the empty sequence. If $arg is the empty sequence, the empty sequence is returned.

Summary: Returns an xs:boolean indicating whether the argument node is nilled. If the argument is not an element node, returns the empty sequence. If the argument is the empty sequence, returns the empty sequence.

Summary: Returns the value of $arg represented as a xs:string. If no argument is supplied, the context item (.) is used as the default argument. The behavior of the function if the argument is omitted is exactly the same as if the context item had been passed as the argument.

If the context item is undefined, error is raised.

If $arg is the empty sequence, the zero-length string is returned.

If $arg is a node, the function returns the string-value of the node, as obtained using the dm:string-value accessor defined in the .

If $arg is an atomic value, then the function returns the same string as is returned by the expression $arg cast as xs:string (see ).

Summary: fn:data takes a sequence of items and returns a sequence of atomic values.

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

Summary: Returns the value of the base-uri URI property for $arg as defined by the accessor function dm:base-uri() for that kind of node in . If $arg is not specified, the behavior is identical to calling the function with the context item (.) as argument. The following errors may be raised: if the context item is undefined ; if the context item is not a node .

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

Document, element and processing-instruction nodes have a base-uri property which may be empty. The base-uri property of all other node types is the empty sequence. The value of the base-uri property is returned if it exists and is not empty. Otherwise, if the node has a parent, the value of dm:base-uri() applied to its parent is returned, recursively. If the node does not have a parent, or if the recursive ascent up the ancestor chain encounters a node whose base-uri property is empty and it does not have a parent, the empty sequence is returned.

See also fn:static-base-uri.

Summary: Returns the value of the document-uri property for $arg as defined by the dm:document-uri accessor function defined in .

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

Returns the empty sequence if the node is not a document node. Otherwise, returns the value of the dm:document-uri accessor of the document node.

In the case of a document node $D returned by the fn:doc function, or a document node at the root of a tree containing a node returned by the fn:collection function, it will always be true that either fn:document-uri($D) returns the empty sequence, or that the following expression is true: fn:doc(fn:document-uri($D)) is $D. It is implementation-defined whether this guarantee also holds for document nodes obtained by other means, for example a document node passed as the initial context node of a query or transformation.

Every built-in atomic type that is defined in , except xs:anyAtomicType and xs:NOTATION, has an associated constructor function. xs:untypedAtomic, defined in and the two derived types xs:yearMonthDuration and xs:dayTimeDuration defined in also have associated constructor functions.

A constructor function is not defined for xs:anyAtomicType as there are no atomic values with type annotation xs:anyAtomicType at runtime, although this can be a statically inferred type. A constructor function is not defined for xs:NOTATION since it is defined as an abstract type in . If the static context (See ) contains a type derived from xs:NOTATION then a constructor function is defined for it. See .

The form of the constructor function for a type prefix:TYPE is:

If $arg is the empty sequence, the empty sequence is returned. For example, the signature of the constructor function corresponding to the xs:unsignedInt type defined in is:

Invoking the constructor function xs:unsignedInt(12) returns the xs:unsignedInt value 12. Another invocation of that constructor function that returns the same xs:unsignedInt value is xs:unsignedInt("12"). The same result would also be returned if the constructor function were to be invoked with a node that had a typed value equal to the xs:unsignedInt 12. The standard features described in would 'atomize' the node to extract its typed value and then call the constructor with that value. If the value passed to a constructor is illegal for the datatype to be constructed, an error is raised .

The semantics of the constructor function xs:TYPE(arg) are identical to the semantics of arg cast as xs:TYPE? . See .

If the argument to a constructor function is a literal, the result of the function may be evaluated statically; if an error is found during such evaluation, it may be reported as a static error.

Special rules apply to constructor functions for xs:QName and types derived from xs:QName and xs:NOTATION. See .

The following constructor functions for the built-in types are supported:

A special constructor function is provided for constructing a xs:dateTime value from a xs:date value and a xs:time value.

The result xs:dateTime has a date component whose value is equal to $arg1 and a time component whose value is equal to $arg2. The result is the empty sequence if either of the parameters is the empty sequence.

The timezone of the result is computed as follows:

Special rules apply to constructor functions for the types xs:QName and xs:NOTATION, for two reasons:

These constraints result in the following restrictions:

When converting from an xs:string, the prefix within the lexical xs:QName supplied as the argument is resolved to a namespace URI using the statically known namespaces from the static context. If the lexical xs:QName has no prefix, the namespace URI of the resulting expanded-QName is the default element/type namespace from the static context. Components of the static context are discussed in . A static error is raised if the prefix is not bound in the static context. As described in , the supplied prefix is retained as part of the expanded-QName value.

For every atomic type in the static context (See ) that is derived from a primitive type, there is a constructor function (whose name is the same as the name of the type) whose effect is to create a value of that type from the supplied argument. The rules for constructing user-defined types are defined in the same way as the rules for constructing built-in derived types discussed in .

Special rules apply to constructor functions for types derived from xs:QName and xs:NOTATION. See .

Consider a situation where the static context contains a type called hatSize defined in a schema whose target namespace is bound to the prefix my. In such a case the constructor function:

is available to users.

To construct an instance of an atomic type that is not in a namespace, it is necessary to use a cast expression or undeclare the default function namespace. For example, if the user-defined type apple is derived from xs:integer but is not in a namespace, an instance of this type can be constructed as follows using a cast expression (this requires that the default element/type namespace is no namespace):

The following shows the use of the constructor function:

The operators described in this section are defined on the following numeric types. Each type whose name is indented is derived from the type whose name appears nearest above with one less level of indentation.

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

The following functions define the semantics of operators defined in and on these numeric types.