You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Daryl Beattie <Da...@screamingmedia.com> on 2001/03/09 23:18:51 UTC
RE: Incorrect handling of x-path substring-before and substring-a
fter?
Dear David,
> This issue about RTFs was debated pretty heavily a while
> back.
Oh, sorry. :( I did look through the archives, but I was looking
more for something to do with substring-before/after. So if you don't feel
like explaining this to me just this once, that's okay... I don't mean to be
a pest.
> From the XSLT recommendation, section 11.1:
>
> Variables introduce an additional data-type into the expression
> language. This additional data type is called result tree
> fragment. A
> variable may be bound to a result tree fragment instead of
> one of the
> four basic XPath data-types (string, number, boolean, node-set). A
> result tree fragment represents a fragment of the result
> tree. A result
> tree fragment is treated equivalently to a node-set that
> contains just a
> single root node.
Yes, that much is understood. Yet it seems we have to wonder which
came first, the chicken or the egg. Because if the result tree comes before
the result, then we should have a non-empty result tree fragment (with only
the root node). Yet if the result comes before the result tree is built,
then it should not be built (according to Kay's book) and instead we should
have an empty string. Another thing to notice (as a colleague of mine
pointed out) is that the recommendation says that a result "may be" bound to
an RTF -- it's not automatically bound to an RTF, which seems to indicate
that the result comes before the RTF.
I'm sorry I can only find references in Kay's book, it seems
whenever I look anywhere else I either can't find anything or get some
really convoluted response. So I am just "trusting" Kay's book.
> Your example with xsl:if is a slightly different case -- "$bob > 0"
> causes $bob to be converted to a number before doing the
> comparison. That
> means it's first converted to a string, then converted to a
> number. The
> conversion to string results in an empty string, which converted to a
> number results in NaN. Comparing NaN with anything is always
> false, so no
> matter what you do, if $bob is an RTF with no child nodes,
> "$bob > 0"
> will always evaluate to false. Just for fun, you can try other
> combinations as well, for example, "$bob = 0" is also false,
> as is "$bob
> < 0", etc.
This was a BIG mistake on my part, I meant to have
"string-length($bob) > 0". That's what I had in my style-sheet, I just
decided to type it into the e-mail instead of cutting and pasting, and I
made a typo. Sorry for the confusion. So we should have:
<xsl:if test="string-length($bob) > 0">
<xsl:text>hello!</xsl:text>
</xsl:if>
[This time I did cut-and-paste. :)]
What this should illustrate is that, if Kay is right (if not in
implementation, then in the concept of comparing result tree fragments),
that this empty result tree fragment "is not a result tree fragment; it is a
zero-length string". Normally, it would make a difference if I used the
select="..." instead of the RTF expression that defines the value of the
variable; but in reality I believe it should be the result that is converted
into the tree, and not the other way around.
There is no doubt that, for a result tree fragment, the behaviour is
correct. I am really wondering why we have a result-tree fragment at all
returned by the comparison.
>
> Isn't XSLT fun!!!!????
Oh, God....... Sometimes doing just the simplest thing takes me half
a day or more!
>
> Hope that helps...
It does. Thanks for your help. :)
Sincerely,
Daryl.
>
> Dave
>
>
>
>
>
> Daryl Beattie
>
> <DarylB@screaming To:
> "'xalan-dev@xml.apache.org'" <xa...@xml.apache.org>
>
> media.com> cc: (bcc:
> David N Bertoni/CAM/Lotus)
>
> Subject: RE:
> Incorrect handling of x-path substring-before and substring-a
> 03/09/2001 03:51 fter?
>
> PM
>
> Please respond to
>
> xalan-dev
>
>
>
>
>
>
>
>
> 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 > 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
> >
>
>
>
>