29220 2015-10-21 15:33:27 +0000 [QT30] map-merge-003-hof, map-entry-001-hof, map-put-003-hof 2015-11-06 16:48:25 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Candidate Recommendation PC Windows NT RESOLVED WONTFIX P2 normal --- 1 christian.gruen oneil abel.braaksma mike public-qt-comments oldest_to_newest 123827 0 christian.gruen 2015-10-21 15:33:27 +0000 The test case "map-merge-003-hof" contains the following query: map:merge(map:entry("foo", 1 to 5)) One of the tests is: <not><assert-type>function(xs:anyURI) as xs:integer*</assert-type></not> I believe this should be inverted to... <assert-type>function(xs:anyURI) as xs:integer*</assert-type> ...because I think it is allowed to specify URIs as function argument: map:merge(map:entry("foo", 1 to 5))(xs:anyURI('x')) However, the instance test should yield false, if the return type differs from the type of the map values, so this would be another alternative: <not><assert-type>function(xs:string) as xs:anyURI*</assert-type></not> The same observation applies to map-entry-001-hof and map-put-003-hof. 124057 1 mike 2015-11-03 15:43:33 +0000 XPath 2.5.5.8 says: The function signature of the map, treated as a function, is always function(xs:anyAtomicType) as item()*, regardless of the actual types of the keys and values in the map. §§This means that a function item type with a more specific return type, such as function(xs:anyAtomicType) as xs:integer, does not match a map in the sense required to satisfy the instance of operator.§§ However, the rules for function coercion mean that any map can be supplied as a value in a context where such a type is the required type, and a type error will only occur if an actual call on the map (treated as a function) returns a value that is not an instance of the required return type. I think that if you are challenging this test case then you are challenging this statement in the spec, especially the sentence I have marked with §§..§§. 124065 2 christian.gruen 2015-11-03 19:04:36 +0000 (In reply to Michael Kay from comment #1) > §§This means that a function item type with a more specific return type, > such as function(xs:anyAtomicType) as xs:integer, does not match a map > in the sense required to satisfy the instance of operator.§§ > [...] > I think that if you are challenging this test case then you are challenging > this statement in the spec, especially the sentence I have marked with > §§..§§. Yes, it may well be that the spec needs to be revised as well. – In the discussed test, it is assumed that map { "foo", 1 to 5 } instance of function(xs:anyURI) as xs:integer* yields false, but I believe it should yield true. However, the result should not be true for the example return type in the spec (xs:integer), because the returned result of a map can always be the empty sequence. 124067 3 mike 2015-11-03 19:12:26 +0000 The rule in the spec has been very extensively discussed by the WG and I believe it correctly reflects what the WG decided. I'm afraid I don't recall all the detailed reasoning. 124068 4 christian.gruen 2015-11-03 19:25:47 +0000 (In reply to Michael Kay from comment #3) > The rule in the spec has been very extensively discussed by the WG and I > believe it correctly reflects what the WG decided. I'm afraid I don't recall > all the detailed reasoning. I see, and I agree: If the actual map contents are to be ignored, the solution is indeed consistent with the spec. Thanks for the clarification!