Re: () eq () vs () = ()

> I'm trying to understand where your frustration with the specification or
> the behaviours lies.

The main 'frustration' is returning the empty sequence from eq... this
started off as:

<xsl:variable name="foo" select="/foo eq 'bar'" as="xs:boolean"/>

which when /foo selected nothing gives the error:

"An empty sequence is not allowed as the value of variable $foo"

So, to be good and continue to specify the boolean sequence type I now
have to do:

<xsl:variable name="foo" select="boolean(/foo eq 'bar')" as="xs:boolean"/>

That's because boolean(()) will return false given an empty sequence,
which xs:boolean will now be happy with.  (xs:boolean(()) causes the
error)

Alternatively, I couldve changed eq to = to get the same result, but
as I know both sides will be single items, that seems wasteful (but as
I mentioned in the original post, that could be the wrong assumption).

And then you get to the 3-value-logic of 'eq', which is beyond me, I
can't see any benefit of the third value... returning false would've
at least been consistent.

Regarding deep-equal(), the first bullet seems wrong: "If the two
sequences are both empty, the function returns true." It's well
defined, but doesn't seem to follow the rest of the spec where one
side is ().  I wonder if it could easily be as well defined as
'false'.

So, changing that to false, making the comparison operators return
false instead of (), and xs:boolean behave like fn:boolean... not too
late is it?  :)


-- 
Andrew Welch
http://andrewjwelch.com