[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: () eq () vs () = ()
On Sat, Oct 1, 2011 at 12:01 PM, Andrew Welch <andrew.j.welch@xxxxxxxxx> wrote: >> deep-equal(A, B) means (count(A) eq count(B) and every $i in 1 to count(A) >> satisfies A[$i] eq B[$i]). Therefore deep-equal((), ()) is true. > > Is it fair to say deep-equal could mean: > > every $i in 1 to max((count(A), count(B))) satisfies A[$i] eq B[$i] > > which would then return false, as its only the length check that is > causing it to return true (and thats only there to avoid also checking > every item in B is equal to A) Even if this is a reasonable definition for deep-equal (disregarding the fact that, as Michael pointed out, it doesn't properly handle values such as NaN or nodes), your assertion that it would return false for deep-equal((), ()) does not hold, since "not(every $i in ... satisfies f($i))" is equivalent to "some $i in ... satisfies not(f($i))", so: every $i in 1 to max((count(()), count(()))) satisfies ()[$i] eq ()[$i] = false() {{{ asserted }}} some $i in 1 to max((count(()), count(()))) satisfies not(()[$i] eq ()[$i]) = true() {{{ negate both sides }}} some $i in 1 to 0 satisfies ... = true() {{{ simplify range and elide condition }}} At this point, the left side is trivially false, regardless of the condition, since the range has no members, so there can't be some member for which the condition is true. I'd echo the comments of others regarding the purpose of deep-equal (identifying an equivalent structure with equivalent values, node names and/or node kinds), the structural equivalence of two empty sequences, and the very much non-intuitive results that would occur if it didn't work the way it did in this case. That said, I agree that () eq () not returning false() is not necessarily intuitive or always convenient for the XSLT crowd, but as a nod of compatibility for the database/SQL community, which drives much of XQuery, it seems a reasonable thorn to bear, given the seemingly rare situations in which it might cause issues. For what it's worth, you said in your description of the case where you ran into this issue that "I couldve changed eq to = to get the same result, but as I know both sides will be single items...", revealing an assumption that was actually violated by your input, for which the left side return no items, leading to an error message which accomplished precisely what the typing of the result as xs:boolean should do: help the processor tell you when things didn't go as you planned. Really, if () eq () were to do anything besides returning (), I'd say it should throw an error, just like it would for a sequence of more than 1 value. -Brandon :)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|