Re: What happens with the lexical value space and the closure of dynamic functions?

I think we start with the rules for the named function reference system-property#1. From XPath 3.0 §3.1.6

<quote>
if the function referenced by a NamedFunctionRef has an implementation-dependent implementation, then the implementation of the function returned by the NamedFunctionRef is associated with the static context of this NamedFunctionRef expression and to the dynamic context in which it is currently being evaluated.
</quote>

The phrase “has an implementation-dependent implementation” essentially means any function other that isn’t written in XPath, XQuery, or XSLT, and system-property#1 falls into this category. So $fun is a function that includes in its closure, among other things, the namespace binding xmlns:xsl="http://www.w3.org/1999/XSL/Transform”.

Then we go to the rules for dynamic function invocations. §3.2.2 directs us to §3.1.5.1, where rule 5(b)(i) tells us:

<quote>
If F's implementation is implementation-dependent (e.g., it is a built-in function or external function or host-language-dependent function, or a partial application of such a function) [then] F's implementation is invoked with the converted argument values using the contexts it is associated with in F. If these contexts are absent in F, it is associated with SC and DC.
</quote>

This tells us, I believe, that we evaluate system-property using the static context held in the closure of $fun, which includes the namespace binding xmlns:xsl="http://www.w3.org/1999/XSL/Transform”

I have to admit that I don’t understand exactly what the last sentence “If these contexts are absent in F, it is associated with SC and DC.” means. I think (hope!) that this is simply covering the case of static function calls, where the context is that of the function call.

It looks as if you are writing some interesting tests. I do hope you will get around to committing them. In many ways, committing the test would be more useful than raising the question by email, because we will automatically have a discussion about the question if it turns out that different implementations have interpreted the spec differently. I have to admit I am a little disappointed how few test cases we are seeing from other implementors, as they are always the most useful ones.

Michael Kay
Saxonica


> On 1 Oct 2015, at 05:43, Abel Braaksma <abel.braaksma@xs4all.nl> wrote:
> 
> Consider:
> 
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="3.0">
>   <xsl:variable name="fun" select="system-property#1" />
>   <other:variable name="test" select="$fun('xsl:version')" 
>        xmlns:xsl="http://other"
>        xmlns:other="http://www.w3.org/1999/XSL/Transform" />
> </xsl:stylesheet>
> 
> What would the value of $test be? When I wrote it (and didn't think about it), I assumed somewhat naïve that the dynamic function call would return the empty string, because the "xsl" prefix does not resolve to the correct namespace in scope.
> 
> However, after testing this, we return "3.0", because at the moment of binding the variable, the namespace for "xsl" is in scope and becomes part of its closure of $fun. Then, when the dynamic call is resolved, it uses whatever namespace bindings were in scope at the binding of $fun and ignores the namespace redefinition. 
> 
> Likewise, using $fun('other:version') fails here (returns empty string) for the same reasons.
> 
> I am not sure this is correct. Or wrong. Or either. Or neither.
> 
> The example here is with system-property, but applies to any dynamic function call that takes a string that takes the lexical namepace into account. The problem does not arise for functions with the argument as a QName.
> 
> Cheers,
> Abel
> 
>

Received on Thursday, 1 October 2015 08:32:01 UTC