[Bug 11460] New: [XSLT 3.0] Context for xsl:merge-key

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11460

           Summary: [XSLT 3.0] Context for xsl:merge-key
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
        AssignedTo: mike@saxonica.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


The content model for xsl:merge-input is

<xsl:merge-input
  select? = expression >
  <!-- Content: (sequence-constructor, xsl:merge-key+) -->
</xsl:merge-input>

This makes it legal to write

<xsl:merge-input>
  <xsl:variable name="o">ascending</xsl:variable>
  <xsl:sequence select="abcd"/>
  <xsl:merge-key select="." order="{$o}"/>
</xsl:merge-input>

But this is meaningless: the criteria for sorting/merging cannot depend in this
way on the data to be sorted. It's legal because of an accident of the rules
for variable scope: rather than saying that the scope of a variable is the rest
of the sequence constructor, we say that it is all following sibling elements
of the xsl:variable.

Proposed solution: in 9.7, after the following:

<quote>
A local variable binding element is visible for all following siblings and
their descendants, with the following exceptions:

1. It is not visible in any region where it is shadowed by another variable
binding.

2. It is not visible within the subtree rooted at an xsl:fallback instruction
that is a sibling of the variable binding element.

3. It is not visible within the subtree rooted at an xsl:catch instruction that
is a sibling of the variable binding element.
</quote>

add a fourth exception:

4. It is not visible within the subtree rooted at an xsl:merge-key instruction
that is a sibling of the variable binding element.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 3 December 2010 12:17:51 UTC