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 ...


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 ...


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,

> 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