[Bug 6164] New: [XSLT] Description of compatibility mode for key function is ambiguous

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

           Summary: [XSLT] Description of compatibility mode for key
                    function is ambiguous
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: All
               URL: http://www.w3.org/TR/xslt20/#keys
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P4
         Component: XSLT 2.0
        AssignedTo: mike@saxonica.com
        ReportedBy: zongaro@ca.ibm.com
         QAContact: public-qt-comments@w3.org


Consider this stylesheet

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
  <xsl:key name="mykey" match="pz" use="number()" version="1.0"/>
  <xsl:key name="mykey" match="nz" use="number()"/>

  <xsl:template match="/">
    <out><xsl:copy-of select="key('mykey',0)"/></out>
  </xsl:template>
</xsl:stylesheet>

applied to this input

<doc><pz>0</pz><nz>-0.0</nz></doc>

According to section 16.3.2 of XSLT 2.0[1] "if any of the xsl:key elements in
the definition of the key enables backwards compatible behavior, then the value
of the key specifier and the value of the second argument of the key function
are both converted after atomization to a sequence of strings, by applying a
cast to each item in the sequence, before performing the comparison."

It's unclear to me from that description whether the conversions to sequences
of strings occurs only for the values of the key specifiers of those xsl:key
elements that enable backwards compatible behaviour and comparison with those
specifiers, or for the key specifiers of all the xsl:key elements for that key,
if at least one enables backwards compatible behaviour.

If the former was intended, the value of the key specifier for pz and nz would
be cast to sequences of string - '0' for pz and '-0' for nz - the second
argument of key would be cast to the string '0'.  Only the key specifier for pz
would match, and the result of the above stylesheet would be

<?xml version="1.0"?><out><pz>0</pz></out>

If the latter reading was intended, the value of the key specifier for pz would
be cast to the string '0' as would the value of the second argument in
comparing with that key specifier, so pz would be selected.  The value of the
key specifier for nz - the xs:double value -0.0 - would be compared to the
value of the second argument - the xs:integer value 0 - and so nz would also be
selected.  The result would be

<?xml version="1.0"?><out><pz>0</pz><nz>-0</nz></out>

If it helps, the description of the backwards compatible behaviour first
appeared in the working draft of 11 February 2005.[2]  I couldn't find any
discussion in the mail archives of this particular aspect of backwards
compatibility after a brief search.

[1] http://www.w3.org/TR/xslt20/#keys
[2] http://www.w3.org/TR/2005/WD-xslt20-20050211


-- 
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 Wednesday, 15 October 2008 20:25:22 UTC