[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] () 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 :)

---