This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The relationship between stable, contextual, deterministic, and non-deterministic is not spelled out, and the terms stable and contextual, though carefully defined, are confusing and not used much outside of the definitions. This raises some questions. 1) Are all functions stable unless the text says otherwise? If not, then how do I identify which functions are stable? 2) Only two functions are said to be contextual. Are these the only ones? If not, then how do I identify which are contextual? 3) Contextual is defined in the definition of stable. What is the relationship between contextual functions and stable functions. Can a function be both? 4) We need to address whether unordered is non-deterministic, unstable, or both.
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 *stable*. 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.
> 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). I think the parenthetical clause will be slightly clearer if we say ... the static context of the call ... or ... the static context of an expression ... (at which point, I think the "by definition" would fit better after the "because".)
need to consider the scope of 'query' or 'transformation' for stablity of F&O with respect to xquery scripting: current-date(), current-dateTime(), current-time(), implicit-timezone(), adjust-date-to-timezone(), adjust-dateTime-to-timezone(), and adjust-time-to-timezone() that depend on properties of the dynamic context that are fixed for the duration of a query or transformation.
The WG decided that we want to resolve this as suggested by Mike Kay in Comment #1. He may make editorial changes as needed.