Saxon

Legacy ID: #3973930 Legacy Poster: Michael Kay (mhkay)

I find it very implausible that the behavior should change when the stylesheet is compiled. I'd like to see concrete evidence of this please: that is, a complete working example that I can reproduce. Given the expession (@a eq 'v'), if @a is an empty sequence (that is, if the attribute doesn't exist), then the result of the expression is an empty sequence. You can regard this as the equivalent of "null" in SQL, if you're familiar with SQL 3-valued logic. When you use an empty sequence in a boolean context, like the condition of an if expression, then the effective boolean value of an empty sequence is false. If you apply the not() function, this also takes the effective boolean value of the argument, so not(@a eq 'v') is true - this differs from SQL, where not(null) is null. With "=" the behavior is similar in this case. The expression (@a = 'v') is true if any item in the node-set @a is equal to 'v'. So if @a is an empty sequence, the result is false. And of course not(false) is true. The thing that sometimes throws people is that (@a != 'v') is also false when @a is an empty sequence - as indeed is the effective boolean value of (@a ne 'v'). All this is well covered in my book. If you have questions about the XSLT specification, as distinct from questions about Saxon, I do suggest that you use the xsl-list at mulberrytech, rather than this forum.

Legacy ID: #3981069 Legacy Poster: Henryk Hecht (henrykhecht)

It can be quite discomfiting to be confronted by that which is implausible but nevertheless true; certainly I found the results below difficult to accept. I think I understand the semantics of boolean-valued expressions in XPath adequately, though I do own your book (which is quite useful). Contrary to your explanation, an empty sequence is simply false, not at all like a ternary logic null-which makes Python or some lisps a closer comparison than SQL. I believe I've done a reasonable job of keeping my posts compatible with the purpose of "getting help with the Saxon product, or report suspected bugs". More to the point, if the following is test_eq.xsl: <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="text"/> <xsl:template match="xsl:stylesheet"> <xsl:value-of select="if (@id eq 'a') then 'true' else 'false'"/> <xsl:text>&#x0A;</xsl:text> <xsl:value-of select="if (not(@id eq 'a')) then 'true' else 'false'"/> <xsl:text>&#x0A;</xsl:text> <xsl:value-of select="if (@id = 'a') then 'true' else 'false'"/> <xsl:text>&#x0A;</xsl:text> <xsl:value-of select="if (not(@id = 'a')) then 'true' else 'false'"/> <xsl:text>&#x0A;</xsl:text> </xsl:template> </xsl:stylesheet> $ java -cp saxon8.jar net.sf.saxon.Transform test_eq.xsl test_eq.xsl false true false true $ java -cp saxon8.jar net.sf.saxon.Compile test_eq.xsl test_eq.sxx Serializing compiled stylesheet Finished serializing stylesheet $ java -cp saxon8.jar net.sf.saxon.Transform -c test_eq.xsl test_eq.sxx false false false true A result which I consider rather surprising. This is still with java 1.5.0_07 on Linux, but I am now using the snapshot jars posted to the mailing list. I can provide you with the "compiled" stylesheet if you think it may be a JDK serialization bug, and of course am quite willing to perform any other tests you may suggest if you believe it to be environmental. Hopefully, however, you will have little difficulty reproducing this problem. -- HH