Subject: Re: [xsl] () eq () vs () = () From: Andrew Welch <andrew.j.welch@xxxxxxxxx> Date: Fri, 30 Sep 2011 12:28:18 +0100 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] () eq () vs () = (), G. Ken Holman | Thread | Re: [xsl] () eq () vs () = (), G. Ken Holman |
Re: [xsl] () eq () vs () = (), G. Ken Holman | Date | Re: [xsl] () eq () vs () = (), G. Ken Holman |
Month |