- 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