[Bug 30049] [XSLT30] Request for clarification if xsl:evaluate example supposed to implement function-lookup is supposed to return empty sequence if function is not found

https://www.w3.org/Bugs/Public/show_bug.cgi?id=30049

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
Certainly we should fix the example. I think it's dangerous to try and write an
example and claim that its effect is precisely equivalent to
fn:function-lookup(); I think it's safer to leave the example "as is" and
qualify the claim of equivalence: 

"If the function-lookupFO30 function were not available in the standard
library, then a very similar function could be implemented like this:"

... "Note: this differs from the effect of fn:function-lookup() in that it
raises an error when the function does not exist, rather than returning an
empty sequence."

The related discussion on the mulberrytech xsl-list and on
https://saxonica.plan.io/issues/3109 appears to raise another point, however.

Under xsl:evaluate (§10.4.2) we say: "All other aspects of the dynamic context
are the same as the dynamic context for the xsl:evaluate instruction itself,
except ..."

and this presumably includes "named functions". But the dynamic context for
xsl:evaluate is defined by §5.3.3, and this omits to tell us how the dynamic
context component "named functions" is initialised. For example, does it
include stylesheet functions with visibility="private"?

* If such functions are excluded, then we break the rule in XPath that the
functions in the dynamic context always include all the functions in the static
context

* If such functions are included, then we have a strange inconsistency with the
statement that the static context for the evaluation of the XPath expression
supplied to xsl:evaluate excludes these functions.

Similarly, does it include XSLT-defined functions such as fn:document()? It
seems a little odd that these are available to calls on fn:function-lookup(),
but not available to calls on xsl:evaluate - except of course that the reason
we excluded them from xsl:evaluate is to allow a free-standing third-party
XPath parser to be used.

Concerning §5.3.3, we should note also:

* the dynamic context component previously called "dynamic variables" is now
called "variable values"

* there are new components "default language", "default calendar", "default
place", "available text resources", "available uri collections", "default uri
collection", "environment variables".

It seems best to handle these with a catch-all addition: "Other components of
the dynamic context are initialized as described in the [XPath 3.0]
specification (or [XPath 3.1], where supported).

I also note that in §5.3.3 the link rendered as "available collections" is
actually a link to the anchor "dt-known-collections" in XP30, but there is no
such anchor (the actual anchor is dt-available-collections). It's not clear to
me why the build system allows the link to be created without error (or, for
that matter, why it passes W3C link checking). Similarly, the link rendered as
"available documents" has anchor "dt-known-docs" whereas the actual anchor is
"dt-available-docs".

Summary of Recommendations (more detailed wording above):

1. Fix the example by withdrawing the claim that the behavior is the same as
fn:function-lookup()

2. Fix the gaps in the specification of the dynamic context by saying that
other components of the dynamic context are defined as in the XPath spec.

3. (Editorial) Investigate why broken links to the XPath 3.0 specification are
not being detected by the build system, and fix the links that are broken.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 16 January 2017 23:42:27 UTC