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 29929 - map:merge: duplicates=unspecified
Summary: map:merge: duplicates=unspecified
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Working drafts
Hardware: PC Windows NT
: 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-11 10:43 UTC by Christian Gruen
Modified: 2016-12-16 19:55 UTC (History)
0 users

See Also:


Attachments

Description Christian Gruen 2016-10-11 10:43:58 UTC
I did not find any hint in the XQFO specification why the "unspecified" option was added for the "duplicates" option in map:merge. I did not find a similar solution for any other function, and I assume that most users of XQuery prefer to have results they can rely on, no matter which implementation they use. Would it hurt anyone to simply drop this value?
Comment 1 Michael Kay 2016-10-12 08:47:10 UTC
One member of the WG persuaded his colleagues that there were many situations where the user would know that duplicates would never be encountered, and therefore didn't care how they were handled, and therefore wanted the implementation to use whatever approach would be most efficient; and that different implementation strategies might lead to a different answer to what the most efficient choice would be.
Comment 2 Michael Kay 2016-10-12 08:57:38 UTC
Digging deeper into my memory of this, I think we were particularly concerned that an implementation that evaluated all the input maps in parallel should not be required to retain information about the ordering of the input maps purely in order to decide which duplicate to retain, when the user might not care.
Comment 3 Christian Gruen 2016-10-16 11:24:48 UTC
Thanks for the clarification, Michael.

Just a guess: It could be helpful for the user of this function to name the value "ignore" (or "use-any"? "use-one"? because "unspecified" hides the fact that only one value will be retained), and to add a little note that this option may improve parallelized execution in some implementations.
Comment 4 Michael Kay 2016-10-18 15:36:35 UTC
The WG agreed to rename the option "use-any" and to add a justificatory note.
Comment 5 Michael Kay 2016-10-18 22:22:06 UTC
The changes have been applied and the only test case I could find has been updated.