- From: Ashok Malhotra <ashokma@microsoft.com>
- Date: Tue, 22 Jul 2003 06:04:27 -0700
- To: "Michael Brundage" <xquery@attbi.com>, <public-qt-comments@w3.org>
Michael: Thank you for your comments. We discussed this on 6/26/2003 and agreed to make the change re. empty document and element nodes. We added an explicit test for empty nodes. If you apply fn:data() to an empty element nodes it returns an empty sequence and two empty sequences compare equal. In case of document nodes, fn:data() returns the string value and two zero-length strings compare equal. Your other suggestions are pedagogical and we are considering how best to use them to improve the exposition. All the best, Ashok > -----Original Message----- > From: Michael Brundage [mailto:xquery@attbi.com] > Sent: Saturday, May 31, 2003 5:31 PM > To: public-qt-comments@w3.org > Cc: Ashok Malhotra > Subject: [F&O, May 2] : error in definition of deep-equal > > The definition of deep-equal means that two empty document nodes always > compare false: > > deep-equal(document { () }, document { () }) > => false() > > because "...if neither node has element children, then the result is true > only if the other node also has simple content..." and document nodes > never > have simple content. > > I think "the other node also has" should have been "both nodes have", but > in > any case, this definition seems to preclude empty document nodes from > comparing equal. This comment may also apply to empty element nodes, > depending on whether they are considered to have simple content or not > (even > when typed with a complex content model?). > > The definition could be fixed by collapsing the last two cases ("If > neither > node has element children..." and "Otherwise, the result is true if and > only > if the children...") into a single case: > > Otherwise, the result is true only if the children of both nodes are > all > pairwise deep-equal, ignoring comment and processing-instruction node > children in both cases. > > fn:deep-equal(($parameter1/(* | text()), data()), ($parameter2/(* | > text()), data()), $collation) > > > > Also, I think the whole definition for the node case could be reduced > significantly by negating it and making some minor rewrites: > > fn:node-kind($parameter1) eq fn:node-kind($parameter2) > and > not(fn:node-name($parameter1) != fn:node-name($parameter2)) > and > (if (fn:node-kind($parameter1) != ("element", "attribute", "document")) > then fn:compare(fn:string($parameter1), fn:string($parameter2), > $collection) eq 0 > else ((count($parameter1/@*) = count($parameter2/@*)) and > (every $a1 in $parameter1/@* satifies > (some $a2 in $parameter2/@* satisfies fn:deep- > equal(data($a1), > data($a2), $collation)))) > and fn:deep-equal(($parameter1/(* | text()), data()), ($parameter2/(* | > text()), data()), $collation) > ) > > > And finally, because namespace nodes cannot be selected or constructed > alone > by any XQuery expression, and because the recursive deep-equal definition > for element skips namespace nodes, why are they included in the list ("If > the two nodes are ... namespace nodes...")? Just in case? > > > > Cheers, > > Michael Brundage > Writing as > Author, "XQuery: The XML Query Language" (Addison-Wesley, to appear 2003) > Co-author, "Professional XML Databases" (Wrox Press, 2000) > > not as > Technical Lead > Common Query Runtime/XML Query Processing > WebData XML Team > Microsoft >
Received on Tuesday, 22 July 2003 09:04:38 UTC