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 29918 - [FO31] map:find ordering constraint prevents streaming evaluation
Summary: [FO31] map:find ordering constraint prevents streaming evaluation
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-06 16:40 UTC by Josh Spiegel
Modified: 2016-12-16 19:55 UTC (History)
1 user (show)

See Also:


Attachments

Description Josh Spiegel 2016-10-06 16:40:49 UTC
Step 3 in the definition of map:find:

<quote>
To process an item that is a map, perform both of the following steps, in order:

 a. If the map contains a key-value entry (K, V) where K is the same key as $key, then add V as a new member to the end of the result array.

 b. For each key-value entry (K, V) in the map (in ·implementation-dependent· order), process V (which is, in general, a sequence).
</quote>

The requirement that a matching entry be added to the result first blocks any hope of streaming evaluation.  I would like the working group to consider making the order implementation-dependent.
Comment 1 Michael Kay 2016-10-18 15:28:44 UTC
The WG discussed the bug in Josh's absence and was unconvinced by the rationale, but we are leaving it open so Josh can argue the case.
Comment 2 Michael Kay 2016-10-31 18:01:54 UTC
I'm not convinced that there is a requirement for streamed evaluation of maps, since I think they are by their nature direct-access data structures. However, if we accept this requirement we could change the rule to read:

<quote>
To process an item that is a map, then for each key-value entry (K, V) in the map (in ·implementation-dependent· order), perform both the following steps, in order:

 a. If K is the same key as $key, then add V as a new member to the end of the result array.

 b. Process V (which is, in general, a sequence).
</quote>

We could also relax the rules on ordering further, but this goes explicitly against a previous decision of the WG which wanted the order to be as predictable as possible.
Comment 3 Josh Spiegel 2016-10-31 18:59:19 UTC
I think that streaming JSON processing is a valid use case, just like streaming XML is.  The working group has made previous decisions in similar cases to facilitate streaming JSON processing so it would not make sense to change direction just for this function.  Further, imposing a partial ordering here isn't useful since the entries are already unordered.  So, relaxing the ordering constraints here does not hurt interoperability in a meaningful way.

I agree that the change proposed in comment 2 would resolve this issue.
Comment 4 Michael Kay 2016-11-01 16:53:33 UTC
The changes were agreed and have been applied.