30024 2016-11-30 17:08:45 +0000 [F+O 3.1] Is map:entry superfluous? 2016-12-16 19:55:25 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.1 Candidate Recommendation PC All CLOSED FIXED P2 normal --- 1 mike mike josh.spiegel public-qt-comments oldest_to_newest 128264 0 mike 2016-11-30 17:08:45 +0000 Comment from Thomas Fischer on public-qt-comments: Hi, the documentation for map:entry says: Unlike the map expression (map{...}), this technique can be used to construct a map with a variable number of entries, for example: map:merge(for $b in //book return map:entry($b/isbn, $b)) At least with Saxon-HE 9.7.0.8J you can achieve the same result with a simple map constructor map:merge(for $b in //book return map{$b/isbn: $b}) I wonder, if this is just a "special feature" of Saxon or if there is any other reason to keep map:entry in the proposal salute Th. Fischer 128265 1 mike 2016-11-30 17:17:01 +0000 Provisional personal response: yes, I think map:entry() is now in a technical sense redundant. However, the fact that something can be done using custom syntax doesn't necessarily mean it's wrong to have a function as well, and at this stage of the game, I don't think redundancy is a good enough reason to pull something out of the spec. At one time I believe that the XSLT working group was trying to ensure that maps could be manipulated using XPath 2.0 without syntax extensions, purely as a function library, and that may still be a relevant argument for some people. 128269 2 josh.spiegel 2016-11-30 17:37:34 +0000 Maybe deleting the text "Unlike the map expression (map{...})" would avoid implying there is some technical limitation where map:entry is required. 128284 3 mike 2016-12-05 14:44:38 +0000 I have implemented Josh's suggestion. 128291 4 mike 2016-12-06 16:26:03 +0000 The WG decided that there were adequate reasons to retain the function and the text justifying its inclusion has been improved.