GNOME Bugzilla – Bug 489627
A non-existent XML element does not work correctly in boolean expressions
Last modified: 2007-10-29 12:26:06 UTC
Please describe the problem: Given this XML file: <doc> <full>of junk></full> <empty></empty> </doc> These complementary boolean expressions referring to a non-existent element both fail: <xsl:if test="/doc/noElement =''">this does not output</xsl:if> <xsl:if test="/doc/noElement!=''">neither does this!!!</xsl:if> Steps to reproduce: 1. make xml file as above --snip-- <?xml version="1.0" encoding="ISO-8859-1"?> <doc> <full>of junk</full> <empty></empty> </doc> --snip-- 2. make a xsl file with the above statements --snip-- <?xml version='1.0'?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version='1.0' <xsl:output method="text"/> <xsl:template match="/"> <xsl:if test="/doc/noElement =''">this does not output</xsl:if> <xsl:if test="/doc/noElement!=''">neither does this !!</xsl:if> </xsl:template> </xsl:stylesheet> --snip-- 3. execute xsltproc xslfile xmlfile Actual results: No output is seen even though the two test expressions appear to be complementary. Expected results: hmmm. I don't know what the standard mandates. Probably that the /doc/noElement='' test should succeed. IE: a non existent element should be considered as a null string in a string comparison. Does this happen every time? yes Other information: Workaround is to change the boolean expressions as follows: string(/doc/noElement)='' - this must force a type conversion which works concat( '[' , /doc/noElement , ']' )='[]' -- ditto
> hmmm. I don't know what the standard mandates. Answer is very simple: http://www.w3.org/TR/xpath#booleans could you please read it first, before assuming a behaviour, and reporting as bug something you don't understand ? Paragraph 6 explains why it's not a bug, I let you go and read it. Daniel
Hi Daniel, thanks for your prompt reply. I apologize for wasting your time. As I wrote, having read the specific section of the standard that you kindly provided, I can not see how the standard speaks to my example. None the less I accept your classification that it is not a bug. Is this the relevant sentence from paragraph 6: "Otherwise, both objects to be compared are converted to strings as if by applying the string function. The = comparison will be true if and only if the objects are equal; the != comparison will be true if and only if the objects are not equal."?
Again very simple: the relevant sentence is: "If one object to be compared is a node-set and the other is a string, then the comparison will be true if and only if there is a node in the node-set such that the result of performing the comparison on the string-value of the node and the other string is true." since there is no node in the node set, the comparison can never return true. Both tests fails, XPath is a bit weird in this respect, but it does actually make sense. Daniel
Ah! Paragraph 5. So, there is no node in the empty node set /doc/noElement and so taking its string value must be undefined (although no error is generated). Therefore comparing it to an empty string (or anything?) fails. If, however, the string value of an empty node set was defined then the equality or inequality comparison would be true. But, string(/doc/emptyNodeSet) actually does return a null string. So if my reasoning is correct then I would disagree that it makes sense. I checked xalan and 4xslt and they agree with xsltproc.
I cut and pasted the definition for that case. The definition is given in nearly mathematical terms. "If and only if" as a very precise meaning. Don't try to reinvent a definition on top of it, it *does not* define the comparison in terms string value of an empty node set (that's defined somewhere else !). There is one definition and that's the point of a standard everybody use the same.
OK. Daniel, thanks again for your explanations. I can accept the standard but I obviously don't understand it. I'll not bother you further on this point as I fear I have wasted enough of your time already. Thanks again.