W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2003

RE: [F&O, May 2] : error in definition of deep-equal

From: Ashok Malhotra <ashokma@microsoft.com>
Date: Tue, 22 Jul 2003 06:04:27 -0700
Message-ID: <E5B814702B65CB4DA51644580E4853FB09841225@red-msg-12.redmond.corp.microsoft.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:56:48 UTC