[Bug 5577] [XSLT 2.1] Composite (multi-part) keys

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

           Summary: [XSLT 2.1] Composite (multi-part) keys
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 2.1
        AssignedTo: mike@saxonica.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


We currently allow composite sort keys (sort first by surname, then given
name), but we do not allow composite access keys (xsl:key) or grouping keys.
Instead we require users to construct such keys by string concatenation, which
is clumsy and error prone because the result may not be unique, and it prevents
use of non-string types as keys.

The simplest way of defining a composite access key would be a new attribute
<xsl:key composite="yes"/>. If the use expression is then multivalued, instead
of indexing each item in the use expression as a separate key value, the
sequence as a whole would be treated as a single key value, to be compared
after atomization using deep-equal().

Alternatively we could adopt a syntax closer to that of xsl:sort, using one
element for each component of the key.

Similarly for xsl:for-each-group we could add an attribute composite="yes", or
we could allow multiple <xsl:group-by> children. 

The advantage of separate elements is that aspects such as collation can be
defined separately for each component. The advantage of a composite="yes"
attribute is that the number of components does not need to be known at compile
time.

Received on Sunday, 16 March 2008 19:38:58 UTC