29676 2016-05-31 09:28:22 +0000 [QT3TS] map-entry-001-hof 2016-09-20 16:15:26 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Candidate Recommendation PC Windows NT RESOLVED FIXED https://www.w3.org/Bugs/Public/show_bug.cgi?id=29586 P2 normal --- 1 tim oneil mike public-qt-comments oldest_to_newest 126626 0 tim 2016-05-31 09:28:22 +0000 Assertion <not><assert-type>function(xs:anyAtomicType) as xs:integer?</assert-type></not> will need to be negated if the changes to the judgement subtype-itemtype(Ai, Bi) in Bug 29586 are adopted. It might be necessary regardless of Bug 29586 if we take the view that it's acceptable to return a subtype. I suggest changing this to <assert-type>function(xs:anyAtomicType) as item()*</assert-type> at the very least. 126627 1 tim 2016-05-31 14:51:14 +0000 Test map-put-003-hof is similarly affected. 126816 2 tim 2016-06-21 16:28:06 +0000 Now fixed. 127261 3 mike 2016-08-30 22:25:18 +0000 I am seeing three tests that appear to be still incorrect: map-merge-003-hof has <assert-type>function(xs:anyURI) as xs:integer*</assert-type> map-put-003-hof has <assert-type>function(xs:string) as xs:integer*</assert-type> map-entry-001-hof has <assert-type>function(xs:anyAtomicType) as xs:integer?</assert-type> I thought the idea/agreement was to change all of these to say "as item()*". 127262 4 tim 2016-08-31 08:55:13 +0000 See rule 35 in 2.5.6.2 The judgement subtype-itemtype(Ai, Bi). Ai is map(K, V), and Bi is function(xs:anyAtomicType) as V?. The test asserts <assert-type>map(xs:string, xs:integer+)</assert-type> so we know that <assert-type>function(xs:anyAtomicType) as xs:integer*</assert-type> should hold, and therefore by rule 26, <assert-type>function(xs:anyURI) as xs:integer*</assert-type> should hold. 127447 5 mike 2016-09-20 16:15:26 +0000 My re-opening in comment 3 is withdrawn.