This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29740 - [FO31] serialize-xml-139,140
Summary: [FO31] serialize-xml-139,140
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-19 14:32 UTC by Tim Mills
Modified: 2016-09-07 09:08 UTC (History)
2 users (show)

See Also:


Attachments

Description Tim Mills 2016-07-19 14:32:47 UTC
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?
Comment 1 O'Neil Delpratt 2016-07-19 15:51:26 UTC
I have assigned this bug to Josh to resolve.
Comment 2 Michael Kay 2016-07-29 10:22:18 UTC
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.
Comment 3 Tim Mills 2016-08-09 13:19:38 UTC
In the meantime, I've added XPTY0004 as possible results for these two tests (without removing the existing assertion).
Comment 4 Michael Kay 2016-09-06 19:48:49 UTC
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.
Comment 5 Tim Mills 2016-09-07 09:07:46 UTC
I've updated the test suite accordingly.