This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
These tests use odd maps for in use-character-maps, namely map { QName("http://example.org","xyz") : "abc" } and map { 'x' : xs:untypedAtomic('j'), 'm' : <e>so</e>, 'l' : 'n' } Neither of these match the required type map(xs:string, xs:string)? Why is the expected result not XPTY0004?
I have assigned this bug to Josh to resolve.
We say two things about the character map in fn:serialize: (a) the required type is map{xs:string, xs:string} (b) the option parameter conventions apply recursively to this map. The tests are trying to test for (b), but the bug suggests that they fail on condition (a), and I agree. I don't think that (b) overrides (a). This leaves the question as to whether statement (b) has any remaining meaning. If all the entries are (string, string) pairs, then there's very little in the option parameter conventions that's actually applicable. It also raises the question of what should happen if any of the keys in the map is a string of length other than 1. One interpretation would be that OPC rule 4 kicks in "It is not an error if the options map contains options with names other than those described in this specification.", since the "names" for which the specification defines a meaning are all single-character strings. That seems unhelpful; I would prefer the interpretation: <quote> If the value [of use-character-maps] is of the correct type [map(xs:string, xs:string)?], but does not satisfy the rules for that parameter defined in [XSLT and XQuery Serialization 3.1], then a dynamic error [err:SEPM0016]SER31 is raised. </quote> So my vote is for deleting the Note that says the option parameter conventions apply recursively, and for raising XPTY0004 for these two tests. Promoting this to a spec bug against F+O.
In the meantime, I've added XPTY0004 as possible results for these two tests (without removing the existing assertion).
The WG agreed that the sentence stating that the option parameter conventions applied to the use-character-maps map should be deleted. The change has been applied; I have also made it explicit what happens when you supply a character map containing a key that is not a string of length one.
I've updated the test suite accordingly.