RE: Incorrect handling of x-path substring-before and substring-a fter?

[Daryl Beattie <Da...@screamingmedia.com>]

Dear David (and other Xalan Developers),

	Hmm... Well, according to Kay's book, page 349, which describes
comparisons involving RTFs;

" The equivalent node-set will always contain a single node. It can never be
empty, because the value of an <xsl:variable> element that is empty is not a
result tree fragment; it is a zero-length string."

	I don't see how RTFs are thus guaranteed to be non-empty. And with
slight modifcations to the XSL sheet I included in my previous e-mail, the
sheet can test:

<xsl:if test="$bob &gt; 0">
	<xsl:text>hello!</xsl:text>
</xsl:if>

	In which case everything works. So, if $bob was a zero-length
string, as Kay's book suggests it is, then why does it evaluate to be true?

Sincerely,

	Daryl.


> -----Original Message-----
> From: David_Marston@lotus.com [mailto:David_Marston@lotus.com]
> Sent: Friday, March 09, 2001 3:22 PM
> To: xalan-dev@xml.apache.org
> Subject: Re: Incorrect handling of x-path substring-before and
> substring-after ? XalanJ2 error messages?
> 
> 
> 
> I think the substring functions are okay. We have tests for 
> the various
> null-string situations. Here's the real issue:
> <xsl:variable name="bob"><xsl:value-of
> select='...'/></xsl:variable>
> creates a result tree fragment (RTF). This RTF is guaranteed to be
> non-empty. Therefore,
> <xsl:if test="$bob">
> is always true. Try using
> <xsl:variable name="bob" select="..."/>
> instead.
> .................David Marston
> 

Re: Incorrect handling of x-path substring-before and substring-after?

[Gary L Peskin <ga...@firstech.com>]

Daryl Beattie wrote:
> 
> Dear David (and other Xalan Developers),
> 
>         Hmm... Well, according to Kay's book, page 349, which describes
> comparisons involving RTFs;
> 
> " The equivalent node-set will always contain a single node. It can never be
> empty, because the value of an <xsl:variable> element that is empty is not a
> result tree fragment; it is a zero-length string."
> 
>         I don't see how RTFs are thus guaranteed to be non-empty.

I think what Mike Kay is saying here is that if you have an
<xsl:variable> element and that element has non-empty content, it will
always be an RTF and this can never be empty.  What he is saying, I
think, is that the statement

  <xsl:variable name="bob"></xsl:variable>

does not produce an empty RTF but instead produces a zero length string,
which it does.  He is saying that there is no way to generate an empty
RTF.  Even the construct:

  <xsl:variable><xsl:value-of select="never"/></xsl:variable>

produces a non-empty RTF.  The equivalent node-set consists of just a
single root node that has no children (assuming that there is no <never>
element) but it is not empty.

So, to paraphrase, I think what the section you quoted on page 349 means
is that, if you have an RTF, it can never be empty.  There is no way to
generate an empty RTF.

> And with
> slight modifcations to the XSL sheet I included in my previous e-mail, the
> sheet can test:
> 
> <xsl:if test="$bob &gt; 0">
>         <xsl:text>hello!</xsl:text>
> </xsl:if>
> 
>         In which case everything works. So, if $bob was a zero-length
> string, as Kay's book suggests it is, then why does it evaluate to be true?

I don't think he's saying that $bob is a zero length string because it
was defined as part of an xsl:variable that had content.  He's saying
that 

  <xsl:variable name="bob"/>

would be a zero length string but not an RTF.

HTH,
Gary