29918 2016-10-06 16:40:49 +0000 [FO31] map:find ordering constraint prevents streaming evaluation 2016-12-16 19:55:39 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.1 Candidate Recommendation PC All CLOSED FIXED P2 normal --- 1 josh.spiegel mike andrew_coleman public-qt-comments oldest_to_newest 127672 0 josh.spiegel 2016-10-06 16:40:49 +0000 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. 127833 1 mike 2016-10-18 15:28:44 +0000 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. 127988 2 mike 2016-10-31 18:01:54 +0000 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. 127989 3 josh.spiegel 2016-10-31 18:59:19 +0000 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. 128008 4 mike 2016-11-01 16:53:33 +0000 The changes were agreed and have been applied.