This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29487 - [XPath31] Section 3.11.3.1 Unary Lookup wrongly compares array?* to array:flatten
Summary: [XPath31] Section 3.11.3.1 Unary Lookup wrongly compares array?* to array:fla...
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-19 15:48 UTC by Martin Honnen
Modified: 2016-03-11 13:17 UTC (History)
4 users (show)

See Also:


Attachments

Description Martin Honnen 2016-02-19 15:48:44 UTC
The section https://www.w3.org/TR/xpath-31/#id-unary-lookup defines the '?' unary lookup operator on maps and arrays, for arrays at the item (4.) it says about doing 

array?*

----- quote ----
If the KeySpecifier is a wildcard ("*"), the UnaryLookup operator is equivalent to the following expression:

for $k in 1 to array:size(.)
return .($k)

Note:

This is also equivalent to Section 17.3.17 array:flatten FO31.
---- end quote ----

The comparison to array:flatten seems wrong in my understanding as array:flatten is recursive while the array?* definition is not recursive.

So array:flatten([[1, 2], ['a', 'b']]) gives a sequence of atomic items (1, 2, "a", "b") while [[1, 2], ['a', 'b']]?* gives a sequence ([1, 2], ["a", "b"])
 of two arrays.

So I would like clarification on that note saying "This is also equivalent to Section 17.3.17 array:flatten FO31", in my view it is wrong.
Comment 1 Josh Spiegel 2016-02-19 16:01:58 UTC
I agree, good catch.
Comment 2 johnlumley 2016-02-25 09:32:02 UTC
It might also be worthwhile adding for clarification an example where internal sequences are also 'flattened', e.g.

[1, 2, (5, 6), [7, 8]]?* evaluates to (1, 2, 5, 6, [7, 8])
Comment 3 Andrew Coleman 2016-03-11 13:17:53 UTC
At the meeting on 2016-03-08, the WG agreed to fix this editorially