W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2015

[Bug 28931] New: [xslt 3.0] apply-templates across packages

From: <bugzilla@jessica.w3.org>
Date: Thu, 09 Jul 2015 12:19:54 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-28931-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28931

            Bug ID: 28931
           Summary: [xslt 3.0] apply-templates across packages
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

I've written a test case override-v-004 and I'm having difficulty establishing
from the spec what the correct result is. To precis the problem, there is a
package A which has

<xsl:use-package B
 <xsl:override
  <xsl:variable name="V" select="13"/>

<call-template name="go"/>

And there is a package B which has

<xsl:variable name="V select="1"/>

<xsl:template match="*[$V=1]">one</xsl:template>
<xsl:template match="*[$V=13]">thirteen</xsl:template>

<xsl:template name="go" visibility="public">
  <xsl:apply-templates select="/*"/>
</xsl:template>

Which template rule should fire? Intuitively, the one with $V=13. Certainly,
any reference to $V within named components of B invoked via something in A
would evaluate to 13.

Let's first assume that we treat the apply-templates and xsl:template
declarations as if they had an explicit mode="U".

Notation: C(P) means the version of component C that appears explicitly or
implicitly in package P.

Then the call-template instruction is a call to go(A), and the apply-templates
instruction in go(A) is bound to mode U(A) which is a copy of mode U(B) but
with different component bindings.

I think there are two clarifications needed to the spec to make this work
unambiguously.

(a) we need to make it clear that when xsl:apply-templates defaults the mode
attribute, this behaves as if it were a component reference to a named mode.

(b) In 3.5.3.5 where we say "When reference resolution is performed for a
component C, each symbolic reference R that is present in the declaration of C
is processed as follows:", we need to make it clear that for template rules,
performing reference resolution for a mode means resolving references for all
template rules in that mode, and that the "symbolic references that are present
in the declaration of the mode" are all the symbolic references in any of those
template rules".

I think there may be additional problems when a mode itself is overridden, but
we'll put that problem on one side for now.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 9 July 2015 12:19:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:55 UTC