[Bug 6217] [FO11] Stable, contexual, deterministic, non-deterministic


--- Comment #1 from Michael Kay <mike@saxonica.com>  2009-05-26 09:43:05 ---
I don't think the term "non-deterministic" is useful in F+O, and it's hardly
used. "implementation-dependent" is all we need.

Let's try:

A function may have the property of being contextual: the result of such a
function depends on the values of properties in the static and dynamic
evaluation context as well as on the actual supplied arguments (if any).

Functions that depend on the context fall into a number of categories:

(a) current-date(), current-dateTime(), current-time(), implicit-timezone(),
adjust-date-to-timezone(), adjust-dateTime-to-timezone(), and
adjust-time-to-timezone() depend on properties of the dynamic context that are
fixed for the duration of a query or transformation. The same applies to a
number of functions in the op: namespace that manipulate dates and times and
that make use of the implicit timezone. These functions will return the same
result if called repeatedly during a single query or transformation.

(b) position(), last(), id(), idref(), element-with-id(), lang(), local-name(),
name(), namespace-uri(), normalize-space(), number(), root(), string(),
string-length() depend on the focus. These functions will in general return
different results on different calls if the focus is different.

(c) default-collation() and many string-handling operators and functions depend
on the default collation and the in-scope collations, which are both properties
of the static context. If a particular call of one of these functions is
evaluated twice with the same arguments then it will return the same result
each time (because the static context, by definition, does not change at run
time). However, two distinct calls (that is, two calls on the function
appearing in different places in the source code) may produce different results
even if the explicit arguments are the same.

(d) Functions such as static-base-uri(), doc(), and collection() depend on
other aspects of the static context. As with functions that depend on
collations, a single call will produce the same results on each call if the
explicit arguments are the same, but two calls appearing in different places in
the source code may produce different results.

For a contextual function, the parts of the context on which it depends are
referred to below as implicit arguments.

Two values $V and $W are defined to be identical if ... [Odd that we don't have
a definition of this. It's easy enough to define for nodes and atomic values,
harder now that we have first-class functions in the data model].

A function that is guaranteed to produce identical results from repeated calls
if the explicit and implicit arguments are identical is referred to as

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

* Some functions (distinct-values, unordered) produce results in an
implementation-defined order. In such cases there is no guarantee that the
order of results from different calls will be the same. These functions are
said to be ordering-unstable. [Is this what we want? Or do we want the results
of these functions to be stable?]

* The function analyze-string (introduced in 2.1) constructs an element node to
represent its results. There is no guarantee that repeated calls with the same
arguments will return the same identical node (in the sense of the "is"
operator). Such a function is said to be identity-unstable.

* Some functions (doc, collection) create new nodes by reading external
documents. Such functions are guaranteed to be stable with the exception that
an implementation is allowed to mke them unstable as a user option.

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 stable: that is, that
repeated calls with the same explicit and implicit arguments should return
identical results.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 26 May 2009 09:43:15 UTC