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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--