ACTION 2016-10-06-002 (component binding in inline functions)

ACTION 2016-10-06-002: MK to review mail from Abel on the topic of
component binding in inline functions (message 28 of September).

Note the message referred to is:

https://lists.w3.org/Archives/Member/w3c-xsl-wg/2016Sep/0028.html

(member-only link)

I think Abel probably intended the example to read:

Package A:

<xsl:variable name="v" as="xs:integer" visibility="private" select="3" />
<xsl:variable name="f" as="function(*)" visibility="final" select="function() {$v}"/>
<xsl:variable name="g" as="function(*)" visibility="public" select="function() {$v}"/>


Package B:

<xsl:variable name="v" as="xs:integer" visibility="public " select="4" />
<xsl:use-package name="A">
  <xsl:override>
    <xsl:variable name="g" as="function(*)" visibility="public" select="function(){$v}" />
  </xsl:override>
</xsl:use-package>


Package C:

<xsl:use-package name="B">
  <xsl:override>
    <xsl:variable name="v" as="xs:integer" visibility="public " select="5" />
  </xsl:override>
</xsl:use-package>
Abel says:

(1) Within A, f()() will return 3 and g()() will return 3
Not quite, f and g are variables not functions. I think $f() and $g() were intended. With that caveat, fine.

(2) Within B, f()() will return 3 and g()() will return 4

Again, changing these to $f() and $g(), that's correct.

(3) Within C, f()() will return 3 and g()() will return 5
Again, changing these to $f() and $g(), I agree.

I think these are all in accordance with my own analysis, and are extensions of the example that we have now added to the spec.

It might be useful to add this as another test case...

Michael Kay
Saxonica