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 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.
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.
Thw WG decided to close on the basis of comment #1