This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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.
Maybe deleting the text "Unlike the map expression (map{...})" would avoid implying there is some technical limitation where map:entry is required.
I have implemented Josh's suggestion.
The WG decided that there were adequate reasons to retain the function and the text justifying its inclusion has been improved.