It is ·implementation-defined· which version of Unicode is supported, but it is recommended that the most recent version of Unicode be used. (See Conformance.)
It is ·implementation-defined· whether the type system is based on XML Schema 1.0 or XML Schema 1.1. (See Conformance.)
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. (See Conformance.)
It is not an error if the options map contains options with names other than those
described in this specification. Implementations may attach an
·implementation-defined· meaning to such entries,
and may define errors that arise if such entries are present with invalid values.
Implementations must ignore such entries unless they have a specific
·implementation-defined· meaning.
Implementations that define additional options in this way should
use values of type xs:QName
as the option names, using an appropriate namespace.
(See Options.)
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. (See Strings, characters, and codepoints.)
[Definition] Some
functions (such as fn:distinct-values
, fn:unordered
, map:keys
,
and map:for-each
) produce results in an
·implementation-defined· or
·implementation-dependent· order.
In such cases two calls with the same arguments are not guaranteed to produce the results in the same order. These functions are
said to be nondeterministic with respect to ordering.
(See .)
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. (See Properties of functions.)
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.
(See fn:document-uri.)
In addition, the values of $value
, converted to an xs:string
,
and $label
(if supplied)
may be directed to a trace data set. The destination of the trace
output is ·implementation-defined·. The format of the trace output is
·implementation-dependent·. The ordering of output from calls of the
fn:trace
function is ·implementation-dependent·.
(See fn:trace.)
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]. (See Arithmetic operators on numeric values.)
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.
(See Arithmetic operators on numeric values.)
The [IEEE 754-2008] 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.
(See Arithmetic operators on numeric values.)
The [IEEE 754-2008] 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.
(See Arithmetic operators on numeric values.)
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.
(See op:numeric-integer-divide.)
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.
(See fn:number.)
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
.
(See fn:format-integer.)
For all format tokens other than a decimal-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 ①
(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
.
(See fn:format-integer.)
The set of languages for which numbering is supported is ·implementation-defined·. If the $lang
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.
(See fn:format-integer.)
...either a
or t
, to indicate alphabetic or traditional
numbering respectively, the default being ·implementation-defined·.
(See fn:format-integer.)
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. (See fn:format-integer.)
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. (See fn:format-integer.)
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·.
(See fn:format-integer.)
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·. (See Defining a decimal format.)
IEEE states that the preferred quantum is language-defined. In this specification, it is ·implementation-defined·. (See Trigonometric and exponential functions.)
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·. (See Trigonometric and exponential functions.)
The map returned by the fn:random-number-generator
function may contain additional entries beyond
those specified here, but it must match the type
item-type(rng)
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.
(See fn:random-number-generator.)
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.
(See The Unicode Collation Algorithm.)
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]. (See The Unicode Collation Algorithm.)
HTML5 defines the semantics of equality matching using this collation; it does not define rules for ordering. If the collation
is used for ordering, the results are ·implementation-defined·. The collation supports collation units and can therefore
be used with functions such as fn:contains
; each Unicode codepoint is a single collation unit.
(See The HTML ASCII Case-Insensitive Collation.)
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. (See Choosing a collation.)
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. (See fn:collation-key.)
Conforming implementations must support normalization form "NFC" and may support normalization forms "NFD", "NFKC", "NFKD", and "FULLY-NORMALIZED". They may also support other normalization forms with ·implementation-defined· semantics. (See fn:normalize-unicode.)
It is ·implementation-defined· which
version of Unicode (and therefore, of the normalization algorithms and their underlying
data) is supported by the implementation. See [UAX #15] for
details of the stability policy regarding changes to the normalization rules in future
versions of Unicode. If the input string contains codepoints that are unassigned in the
relevant version of Unicode, or for which no normalization rules are defined, the
fn:normalize-unicode
function leaves such codepoints unchanged. If the
implementation supports the requested normalization form then it must
be able to handle every input string without raising an error.
(See fn:normalize-unicode.)
It is possible to define collations that do not have the ability to decompose a string into units suitable for substring matching. An argument to a function defined in this section may be a URI that identifies a collation that is able to compare two strings, but that does not have the capability to split the string into collation units. Such a collation may cause the function to fail, or to give unexpected results or it may be rejected as an unsuitable argument. The ability to decompose strings into collation units is an ·implementation-defined· property of the collation. (See Functions based on substring matching.)
The result of the function will always be such that validation against this schema would succeed. However, it is ·implementation-defined· whether the result is typed or untyped, that is, whether the elements and attributes in the returned tree have type annotations that reflect the result of validating against this schema. (See fn:analyze-string.)
All minimally conforming processors must support positive year values with a minimum of 4 digits (i.e., YYYY) and a minimum fractional second precision of 1 millisecond or three digits (i.e., s.sss). However, conforming processors may set larger ·implementation-defined· limits on the maximum number of digits they support in these two situations. Processors may also choose to support the year 0000 and years with negative values. The results of operations on dates that cross the year 0000 are ·implementation-defined·. (See Limits and precision.)
...the format token n
, N
,
or Nn
, indicating that the value of the component is to be output by name,
in lower-case, upper-case, or title-case respectively. Components that can be output by name
include (but are not limited to) months, days of the week, timezones, and eras.
If the processor cannot output these components by name for the chosen calendar and language
then it must use an ·implementation-defined· fallback representation.
(See The picture string.)
...indicates alphabetic or traditional numbering respectively,
the default being ·implementation-defined·.
This has the same meaning as in the second argument of fn:format-integer
.
(See The picture string.)
The sequence of characters in the (adjusted) first presentation modifier is reversed (for example,
999'###
becomes ###'999
).
If the result is not a valid decimal digit pattern, then the output is
·implementation-defined·.
(See Formatting Fractional Seconds.)
The output for these components is entirely ·implementation-defined·.
The default presentation modifier for these components is n
, indicating that they are output as names (or
conventional abbreviations), and the chosen names will in many cases depend on the chosen language: see 9.8.4.8 The language, calendar, and place arguments.
(See Formatting Other Components.)
The set of languages, calendars, and places that are supported in the ·date formatting functions· is ·implementation-defined·. When any of these arguments is omitted or is an empty sequence, an ·implementation-defined· default value is used. (See The language, calendar, and place arguments.)
The choice of the names and abbreviations used in any given language is
·implementation-defined·. For example,
one implementation might abbreviate July as Jul
while another uses Jly
. In German,
one implementation might represent Saturday as Samstag
while another
uses Sonnabend
. Implementations may provide mechanisms allowing users to
control such choices.
(See The language, calendar, and place arguments.)
The choice of the names and abbreviations used in any given language for calendar units such as days of the week and months of the year is ·implementation-defined·. (See The language, calendar, and place arguments.)
The calendar value if present must be a valid EQName
(dynamic error: [err:FOFD1340]).
If it is a lexical QName
then it is expanded into an expanded QName
using the statically known namespaces; if it has no prefix then it represents an expanded-QName in no namespace.
If the expanded QName is in no namespace,
then it must identify a calendar with a designator specified below
(dynamic error: [err:FOFD1340]).
If the expanded QName is in a namespace then it identifies the calendar in an ·implementation-defined· way.
(See The language, calendar, and place arguments.)
At least one of the above calendars must be supported. It is ·implementation-defined· which calendars are supported. (See The language, calendar, and place arguments.)
Various aspects of this processing are ·implementation-defined·. Implementations may provide external configuration options that allow any aspect of the processing to be controlled by the user. In particular:... (See fn:doc.)
It is ·implementation-defined· whether DTD validation and/or schema validation is applied to the source document. (See fn:doc.)
The effect of a fragment identifier in the supplied URI is ·implementation-defined·. One possible interpretation is to treat the fragment identifier as an ID attribute value, and to return a document node having the element with the selected ID value as its only child. (See fn:doc.)
By default, this function is ·deterministic·. This means that repeated calls on the function with the same argument will return the same result. However, for performance reasons, implementations may provide a user option to evaluate the function without a guarantee of determinism. The manner in which any such option is provided is ·implementation-defined·. If the user has not selected such an option, a call to this function must either return a deterministic result or must raise a dynamic error [err:FODC0003]. (See fn:collection.)
By default, this function is ·deterministic·. This means that repeated calls on the function with the same argument will return the same result. However, for performance reasons, implementations may provide a user option to evaluate the function without a guarantee of determinism. The manner in which any such option is provided is ·implementation-defined·. If the user has not selected such an option, a call to this function must either return a deterministic result or must raise a dynamic error [err:FODC0003]. (See fn:uri-collection.)
...the processor may use ·implementation-defined· heuristics to determine the likely encoding, otherwise... (See fn:unparsed-text.)
The fact that the resolution of URIs is defined by a mapping in the dynamic context means that in effect, various aspects of the behavior of this function are ·implementation-defined·. Implementations may provide external configuration options that allow any aspect of the processing to be controlled by the user. In particular:... (See fn:unparsed-text.)
The collation used for matching names is ·implementation-defined·, but must be the same as the collation used to ensure that the names of all environment variables are unique. (See fn:environment-variable.)
The precise process used to construct the XDM instance is ·implementation-defined·. In particular, it is implementation-defined whether DTD and/or schema validation is invoked, and it is implementation-defined whether an XML 1.0 or XML 1.1 parser is used. (See fn:parse-xml.)
The precise process used to construct the XDM instance is ·implementation-defined·. In particular, it is implementation-defined whether an XML 1.0 or XML 1.1 parser is used. (See fn:parse-xml-fragment.)
If the second argument is omitted, or is supplied in the form of an output:serialization-parameters
element, then the values of any serialization parameters that are not explicitly specified is ·implementation-defined·,
and may depend on the context.
(See fn:serialize.)
If the arguments to fn:function-lookup
identify a function that is present
in the static context of the function call, the function will always return the same
function that a static reference to this function would bind to. If there is no such
function in the static context, then the results depend on what is present in the
dynamic context, which is ·implementation-defined·.
(See fn:function-lookup.)
A sequence of URIs (in the form of xs:string
values) which may be used or ignored in an
·implementation-defined· way....
(See fn:load-xquery-module.)
Values for vendor-defined configuration options for the XQuery processor used to process the request. The key is the name of an option, expressed as a QName: the namespace URI of the QName should be a URI controlled by the vendor of the XQuery processor. The meaning of the associated value is ·implementation-defined·. Implementations should ignore options whose names are in an unrecognized namespace. The ·option parameter conventions· do not apply to this contained map.... (See fn:load-xquery-module.)
It is ·implementation-defined· whether constructs in the library module are evaluated in the same ·execution scope· as the calling module. (See fn:load-xquery-module.)
The library module that is loaded may import schema declarations using an import schema
declaration. It is
·implementation-defined· whether schema components in the in-scope
schema definitions of the calling module
are automatically added to the in-scope schema definitions of the dynamically loaded module. The in-scope schema definitions
of the calling and called modules must be consistent, according to the rules defined in
Section
2.2.5 Consistency Constraints
XQ31.
(See fn:load-xquery-module.)
If the implementation provides a way of writing or invoking functions
with side-effects, this post-processing function might be used to save
a copy of the result document to persistent storage. For example, if the
implementation provides access to the EXPath File library [EXPath],
then a serialized document might be written to filestore by calling the
file:write
function. Similar mechanisms might be used to issue
an HTTP POST request that posts the result to an HTTP server, or to send
the document to an email recipient. The semantics of calling functions
with side-effects are entirely ·implementation-defined·.
(See fn:transform.)
Calls to fn:transform
can potentially have side-effects
even in the absence of the post-processing option, because the XSLT
specification allows a stylesheet to invoke extension functions
that have side-effects. The semantics in this case are ·implementation-defined·.
(See fn:transform.)
A string intended to be used as the static base URI of the principal stylesheet
module. This value must be used if no other static base URI is
available. If the supplied stylesheet already has a base URI (which will generally be
the case if the stylesheet is supplied using stylesheet-node
or
stylesheet-location
) then it is ·implementation-defined· whether this
parameter has any effect. If the value is a relative reference, it is resolved against
the static base URI of the fn:transform
function call....
(See fn:transform.)
Values for vendor-defined configuration options for the XSLT processor used to process the request. The key is the name of an option, expressed as a QName: the namespace URI of the QName should be a URI controlled by the vendor of the XSLT processor. The meaning of the associated value is ·implementation-defined·. Implementations should ignore options whose names are in an unrecognized namespace. Default is an empty map.... (See fn:transform.)
It is ·implementation-defined· whether the XSLT transformation is executed within the same ·execution scope· as the calling code. (See fn:transform.)
XSLT 1.0 does not define any error codes, so this is the likely outcome with an XSLT 1.0 processor. XSLT 2.0 and 3.0 do define error codes, but some APIs do not expose them. If multiple errors are signaled by the transformation (which is most likely to happen with static errors) then the error code should where possible be that of one of these errors, chosen arbitrarily; the processor may make details of additional errors available to the application in an ·implementation-defined· way. (See fn:transform.)
The input may contain deviations from the grammar of [RFC 7159], which are handled in an ·implementation-defined· way. (Note: some popular extensions include allowing quotes on keys to be omitted, allowing a comma to appear after the last item in an array, allowing leading zeroes in numbers, and allowing control characters such as tab and newline to be present in unescaped form.) Since the extensions accepted are implementation-defined, an error may be raised [err:FOJS0001] if the input does not conform to the grammar. (See fn:parse-json.)
The input may contain deviations from the grammar of [RFC 7159], which are handled in an ·implementation-defined· way. (Note: some popular extensions include allowing quotes on keys to be omitted, allowing a comma to appear after the last item in an array, allowing leading zeroes in numbers, and allowing control characters such as tab and newline to be present in unescaped form.) Since the extensions accepted are implementation-defined, an error may be raised (see below) if the input does not conform to the grammar. (See fn:json-to-xml.)
Indicates that the resulting XDM instance must be typed; that is, the element
and attribute nodes must carry the type annotations that result from validation
against the schema given at C.2 Schema for the result of fn:json-to-xml, or against an
·implementation-defined· schema
if the liberal
option has the value true
.
(See fn:json-to-xml.)
If ST is xs:float
or
xs:double
, then TV is the
xs:decimal
value, within the set of
xs:decimal
values that the implementation is
capable of representing, that is numerically closest to
SV. If two values are equally close, then the one
that is closest to zero is chosen. If SV is too
large to be accommodated as an xs:decimal
, (see
[XML Schema Part 2: Datatypes Second Edition] for ·implementation-defined· limits on
numeric values) a dynamic error is raised [err:FOCA0001]. If SV is one of the special
xs:float
or xs:double
values
NaN
, INF
, or -INF
, a dynamic
error is raised [err:FOCA0002].
(See Casting to xs:decimal.)
If ST is
xs:decimal
, xs:float
or
xs:double
, then TV is SV
with the fractional part discarded and the value converted to
xs:integer
. Thus, casting 3.1456
returns 3
and -17.89
returns
-17
. Casting 3.124E1
returns 31
. If SV is too large to be
accommodated as an integer, (see [XML Schema Part 2: Datatypes Second Edition] for
·implementation-defined· limits on numeric values) a
dynamic error is
raised [err:FOCA0003]. If SV is
one of the special xs:float
or
xs:double
values NaN
,
INF
, or -INF
, a dynamic error is raised
[err:FOCA0002].
(See Casting to xs:integer.)
In casting to xs:decimal
or to a type derived from xs:decimal
,
if the value is not too large or too small but nevertheless cannot be represented accurately
with the number of decimal digits available to the implementation, the implementation may round
to the nearest representable value or may raise a dynamic error [err:FOCA0006].
The choice of rounding algorithm and the choice between rounding and error behavior and is
·implementation-defined·.
(See Casting from xs:string and xs:untypedAtomic.)
The tz timezone database, available at http://www.iana.org/time-zones. It is ·implementation-defined· which version of the database is used. (See IANA Timezone Database.)
Unicode Standard Annex #15: Unicode Normalization Forms. Ed. Mark Davis and Ken Whistler, Unicode Consortium. The current version is 9.0.0, dated 2016-02-24. As with [The Unicode Standard], the version to be used is ·implementation-defined·. Available at: http://www.unicode.org/reports/tr15/. (See UAX #15.)
The Unicode Consortium, Reading, MA, Addison-Wesley, 2016. The Unicode Standard as updated from time to time by the publication of new versions. See http://www.unicode.org/standard/versions/ for the latest version and additional information on versions of the standard and of the Unicode Character Database. The version of Unicode to be used is ·implementation-defined·, but implementations are recommended to use the latest Unicode version; currently, Version 9.0.0. (See The Unicode Standard.)
Unicode Technical Standard #10: Unicode Collation Algorithm. Ed. Mark Davis and Ken Whistler, Unicode Consortium. The current version is 9.0.0, dated 2016-05-18. As with [The Unicode Standard], the version to be used is ·implementation-defined·. Available at: http://www.unicode.org/reports/tr10/. (See UTS #10.)
Unicode Technical Standard #35: Unicode Locale Data Markup Language. Ed Mark Davis et al, Unicode Consortium. The current version is 29, dated 2016-03-15. As with [The Unicode Standard], the version to be used is ·implementation-defined·. Available at: http://www.unicode.org/reports/tr35/. (See UTS #35.)