>  I would still think that XSLT 3 with composite keys
> xsl:key name="key-name" match="foo" use="bar, baz" composite="yes" is
easier than doing that with a map.

Yes, nested-maps can be tricky. We have a proposal to allow as keys of a
map not only atomic items, but any item (like map or array) or a  sequence.

Or use a single key that is: *{key1}_{key2}_..._{keyN}*  as was done in
XSLT 2 and 1.

Thanks,
Dimitre

On Fri, Mar 14, 2025 at 9:49b/AM Martin Honnen martin.honnen@xxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>
> On 14/03/2025 17:37, Graydon graydon@xxxxxxxxx wrote:
>
> On Fri, Mar 14, 2025 at 04:26:54PM -0000, Michael Kay michaelkay90@xxxxxxxxx
scripsit:
>
> Three options:
>
> (a) use xsl:key
>
> (b) use an XSLT processor that optimizes joins (such as Saxon-EE) (but you
may need to write the search using predicates, not using xsl:for-each and
xsl:if)
>
> (c) build your own indexes as maps, as you suggest.
>
> Tangentially, is there a use case where xsl:key is expected to be
> preferable in performance terms to using maps?
>
>
> I would still think that XSLT 3 with composite keys xsl:key
> name="key-name" match="foo" use="bar, baz" composite="yes" is easier than
> doing that with a map.
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/782854> (by
> email <>)