This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider test serialize-xml-120 <test-case name="serialize-xml-120" covers="fn-serialize"> ... <test>let $params := map { QName("","indent") : true() } return serialize(., $params) </test> <result> <error code="SEPM0017"/> </result> </test-case> SEPM0017 should not be expected in this case. From SER31: https://www.w3.org/TR/2015/CR-xslt-xquery-serialization-31-20151217/ "If in any case evaluating this expression would yield an error, serialization error [err:SEPM0017] results." "expression" refers to query that validates a serialization document and there is no serialization document used in this case. But I don't think the specification says which error code should be raised. http://www.w3.org/XML/Group/qtspecs/specifications/xpath-functions-31/html/#func-serialize "The key of the entry is an xs:string value in the cases of parameter names defined in these specifications, or an xs:QName (with non-absent namespace) in the case of implementation-defined serialization parameters." Then the table has a note: "If an xs:QName is supplied, then it must have a non-absent namespace URI. This means that system-defined serialization methods such as xml and json are defined as strings, not as xs:QName values." One could argue that this falls under SEPM0016 but I think the definition should clarify this.
I have been asked to propose a resolution. Note 1 beneath the table refers to the entries in the table that reference Note 1, that is, the values of the method and json-node-output-method parameters. It is therefore not relevant to this test case. The Note should be clarified to avoid any misunderstanding on this point. I believe that this test case should not be an error. The spec says that "The option parameter conventions apply", and these conventions state that option keys that are not recognized are ignored. The thinking here is that an implementation can look in the map for the keys it knows how to handle, it does not have to enumerate all the keys in the map and check that each one is recognized. An implementation shouldn't be looking for QName("", "indent") and should therefore ignore it.
At the meeting on 2016-03-15, the WG agreed to adopt the resolution proposed in comment 1
In closing this, I thought it would be useful to have an example of how to set serialization parameters using a map. The existing example The expression fn:serialize($data, map{}) returns '<a b="3"/>'. is rather trivial. So I have changed it to fn:serialize($data, map{"method":"xml", "omit-xml-declaration":true()}) but with the observation that neither of these parameters is necessary, because they correspond to the defaults.