array:members-at

[dnovatchev]

The title says it all.

We have fn:slice and array:slice. We also do have fn:items-at, but we have somehow missed to add the corresponding array:items-at array:members-at function.

We could even think of a function map:entries-at and map:values-for-keys. The first of these would return all map entries that have as keys one of the provided as argument set of keys. The 2nd function would return all values of the map entries that have as keys one of the provided as argument set of keys.

Here is a complete XPath 3.1 implementation:

let $members-at := function(
                 $input as array( *), 
                 $indexes as xs:integer*
                ) as array(*)*
 {
     for $ind in $indexes
       return [$input($ind)]
 }

---

Example:

Evaluating this expression:

let $members-at := function(
                 $input as array( *), 
                 $indexes as xs:integer*
                ) as array(*)*
 {
     for $ind in $indexes
       return [$input($ind)]
 }
  return
     $members-at([1, (2, 3), (4, 5, 6)], (1, 3) )

produces the wanted result:

[1], [(4,5,6)]

[michaelhkay]

The reason for the omission is that arrays do not contains items, they contain members, which are sequences. Filtering is therefore a more complex operation.

[michaelhkay]

I agree though that array:members-at() would be a useful addition.

[ChristianGruen]

@dnovatchev I assume you would expect the signature to be…

fn:members-at(
  $array  as array(*),	
  $at     as xs:integer*	
) as array(*)

…and array:join($at ! [ $array(.) ]) would be an equivalent expression?

Related: #135

[dnovatchev]

@dnovatchev I assume you would expect the signature to be…

fn:members-at(
  $array  as array(*),	
  $at     as xs:integer*	
) as array(*)

…and array:join($at ! [ $array(.) ]) would be an equivalent expression?

Related: #135

@ChristianGruen I had significant difficulties understanding what this expression was intended to mean.

Why should one spend 30 minutes to decipher what such expression may mean, when they could use a very understandable fn:members-at ?

[dnovatchev]

I agree though that array:members-at() would be a useful addition.

Absolutely agree!

I will edit the title and the issue.

Done!

[ChristianGruen]

Why should one spend 30 minutes to decipher what such expression may mean, when they could use a very understandable fn:members-at ?

No need to. Once again, this seems to be a misunderstanding. I just wanted to understand what exactly your function is expected to do, as it needs to be implemented at some stage. Feel free to add a better explanation.

[dnovatchev]

Why should one spend 30 minutes to decipher what such expression may mean, when they could use a very understandable fn:members-at ?

No need to. Once again, this seems to be a misunderstanding. I just wanted to understand what exactly your function is expected to do, as it needs to be implemented at some stage. Feel free to add a better explanation.

A proposal for array:members-at will essentially be similar to the one for fn:items-at, where "sequence" is replaced by "array" and "item" by member (in the text) or item()* in the signature.

Writing such a proposal can be done rather mechanically.

I added a complete XPath 3.1 implementation.

[ChristianGruen]

As we already have array:get, we could possiby drop array:members-at and adjust fn:items-at instead (see #872).

[ndw]

The CG decided to close this issue without further action at meeting 067.