This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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 §§..§§.
(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.
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.
(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!