- From: <bugzilla@jessica.w3.org>
- Date: Fri, 29 Jul 2016 10:22:18 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29740
Michael Kay <mike@saxonica.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mike@saxonica.com
Assignee|josh.spiegel@oracle.com |mike@saxonica.com
Component|XQuery 3 & XPath 3 Test |Functions and Operators 3.1
|Suite |
--- Comment #2 from Michael Kay <mike@saxonica.com> ---
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.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 29 July 2016 10:22:26 UTC