W3C home > Mailing lists > Public > public-xslt-40@w3.org > January 2021

Re: Processiing arrays in XSLT 4

From: Reece Dunn <msclrhd@googlemail.com>
Date: Tue, 12 Jan 2021 18:48:57 +0000
Message-ID: <CAGdtn27kOXJE+K3tjv3vaa3GBzbKPR3n1UyTrYUJKcf8iVz94A@mail.gmail.com>
To: Michael Kay <mike@saxonica.com>
Cc: Christian Grün <cg@basex.org>, Martin Honnen <martin.honnen@gmx.de>, public-xslt-40@w3.org
On Tue, 12 Jan 2021 at 18:31, Michael Kay <mike@saxonica.com> wrote:

> Perhaps
>
> for key $k value $val in $map return ...
>

+1

I'm wondering how this would work in XSLT. Maybe something like:

    <xsl:for-each select="..." key="k" value="v">

which would mean that arrays would be something like:

    <xsl:for-each select="..." member="v">

That would keep the select and align with XQuery for expressions. It would
also make it easy/intuitive to extend with a position="i" attribute (or
at="i" if we want to keep the naming consistent with XQuery, although that
may be easily confused with the @as attribute) to hold the position.


> or
>
> for entry ($k, $v) in $map return ...
>

+1

If we do go for this option (which I'm not opposed to), it would be useful
to consider aligning it with the sequence destructuring proposal, which in
the xpath-ng issue the following syntax was considered:

    for entry $(k, v) in $map return ...

Note: this syntax is to align with the proposed array -- $[a, b] -- and map
-- ${key, value} -- destructuring syntax as part of the same proposal.

Kind regards,
Reece


> Michael Kay
> Saxonica
>
> > On 12 Jan 2021, at 18:23, Christian Grün <cg@basex.org> wrote:
> >
> >> If we are going for consistency with the XPath/XQuery proposal then
> this could be member="..." that accepts an array or map. I'm happy either
> way (@array/@map or @member).
> >
> > I believe 'member' is exclusively used for arrays. Maybe 'entry' would
> > be a better option then?
>
>
Received on Tuesday, 12 January 2021 18:49:22 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 12 January 2021 18:49:23 UTC