29952 2016-10-20 14:22:53 +0000 [QT3TS] d1e78807, d1e78807b 2016-11-29 16:29:58 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Candidate Recommendation PC Windows NT RESOLVED WORKSFORME P2 normal --- 1 tim oneil mike public-qt-comments oldest_to_newest 127880 0 tim 2016-10-20 14:22:53 +0000 The expected results for these are wrong. Each uses a deep-equal, where the LHS is from document returned from a call to fn:transform, while the RHS is a "matching" expected result. However, the nodes from the LHS use XSLT default validation mode "strip", so come out as untyped, wherease the RHS elements are constructed as "preserve" so are typed. This means the nodes aren't considered deep equal. 128255 1 mike 2016-11-25 18:11:51 +0000 Note that these tests are in test set app/Walmsley. I think Tim's argument is not quite accurate. On the XQuery side, an element node constructor may produce xs:untyped or xs:anyType depending on whether the processor supports the typed data feature. On the XSLT side, the two tests are different: * the first test constructs a document node and returns it directly. The result is untyped. * the second test returns the result of calling doc(). This delivers typed or untyped data depending on the setting of input-type-annotations, whose default is unspecified. So it's actually implementation-defined on both sides of the fence. But the more important question is whether two elements are deep equal if one of them is annotated as xs:anyType and the other as xs:untyped. Time suggests not. But my reading is that they are. The data model says: "The properties of xs:untyped are the same as the properties of xs:anyType except for the base type and name. The base type of xs:untyped is xs:anyType." This means in particular that they have the same {variety} (specifically, mixed). fn:deep-equal() does not require nodes to have the same type annotation, so long as both type annotations have the same {variety}, and that condition is satisfied here. 128262 2 mike 2016-11-29 16:29:58 +0000 Thw WG decided to close on the basis of comment #1