- From: <bugzilla@jessica.w3.org>
- Date: Fri, 25 Nov 2016 18:11:51 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29952 Michael Kay <mike@saxonica.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |mike@saxonica.com --- Comment #1 from Michael Kay <mike@saxonica.com> --- 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 25 November 2016 18:12:06 UTC