This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
According to XQuery two empty sequences are NOT equal using the = comparison. http://www.w3.org/TR/xquery/ 3.5.2 General Comparisons The result of the comparison is true if and only if there is a pair of atomic values, one in the first operand sequence and the other in the second operand sequence, that have the required magnitude relationship. But http://www.w3.org/TR/xpath-functions/#func-deep-equal says 15.3.1 fn:deep-equal ... If the two sequences are both empty, the function returns true. Two objects that are deep-equal ought to be equal. Suggestion: Fix the definition of = so that two empty sequences are equal to each other. (Fix != also.)
= is defined using existential quantification since XPath 1.0. Redefining the meaning of () = () to be true would break this so I don't think this change request can be accommodated (and I certainly am against this change now). We had long discussions on whether to remove the quantification semantics from = early on (when you were able to participate), but the backwards- compatibility argument won out. Best regards Michael (expressing my personal opinion)
You're trying to fix one inconsistency by introducing another much bigger one. You say that two things that are deep-equal() ought to be =, but you don't say why. It seems to be purely an aesthetic judgement. To achieve this by changing the semantics of "=", which would (a) be backwards incompatible, and (b) destroy the general principle that A = B implies (some $a in A, $b in B satisifes $a eq $b) would not be a net gain. Note also that (() eq ()) is (), which in most contexts (e.g. EBV) is treated as false. Incidentally, it's far too late to be suggesting changes based on usability or aesthetics. We're strictly in bug-fixing mode now. Michael Kay personal response
OK, if it too late and unreasonable to change () = () why not change the definition of deep-equals. (I recall that Mike Kay found this function to be problematic.) What harm would be done by removing this sentence? If the two sequences are both empty, the function returns true. There cannot be a backwards compatibility issue. I think that if this sentence is removed then deep-equal would return false. The general defintion states: "To be deep-equal, they must contain items that are pairwise deep-equal" but since neither sequence contains any items it ought to return false. More specifically it seems to be governed by this rule: "If the two sequences are of the same length, the function returns true if and only if every item in the sequence $parameter1 is deep-equal to the item at the same position in the sequence $parameter2. " Again, if that rule is applied it would return false. P.S. I do regard this as a bug. This would be the one exception to the rule that deep-equals implies equals (=).
The general rule for deep-equal() is that two sequences A and B are deep-equal if count(A) = count(B) and every $n in (1 to count(A)) satisfies deep-equal(A[$n], B[$n]). A consequence of this is that deep-equal((), ()) is true. This is because in mathematical logic (every x in X satisfies C) is always true when X is empty. deep-equal() and = adopt fundamentally different ways of comparing two sequences, both of which are useful. It should not be suprising that they give different results for the empty sequence, since they also give different results for most other sequences. Michael Kay personal response
I understand everything that Michael Kay said in his last post, and it is all true. Howevere it is also true that under the current defintion of deep-equals comparing two empty sequences would be the one exception to the rule that deep-equals implies equals (=). A simple fix to the definition of deep-equals would be to add "A = B", i.e., Two sequences A and B are deep-equal if A = B and count(A) = count(B) and every $n in (1 to count(A)) satisfies deep-equal(A[$n], B[$n]). Of course implementations would know that the first clause only matters in the case of 2 empty sequences.
deep-equal() does not imply =. Consider an element A that has a complex type with element-only content. deep-equal(A, A) is true, but A=A gives an error. There are other exceptions to your proposed rule, for example NaN. Michael Kay
Steve, Thanks for submitting this comment. Your comment was considered by the Query and XSLT working groups at their joint meeting on 01 Feb 2006. The working groups decided not to change the definitions of the = operator or the fn:deep- equal function, but to accept that these two operations are inconsistent in certain cases. The = operator is defined the way it is for backward compatibility with XPath 1.0. The fn:deep-equal function is defined so that any value is deep-equal to itself, to support applications such as grouping. This means that, for certain cases such as the one you describe, deep-equal may be true but = may be false for a given pair of values. If this resolution is acceptable to you, please close this Bugzilla entry. Otherwise, you may submit additional arguments about why this decision should be reconsidered. The issue will be closed by the end of February 2006 if we do not hear from you. Regards, Don Chamberlin (for the Query and XSLT working groups)
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.