Re: [xsl] Re: FXPath - A comment on EXSL

Subject: Re: [xsl] Re: FXPath - A comment on EXSL
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Thu, 1 Mar 2001 15:13:17 +0000
Hi David,

Sorry to bang on about this.  I'm just confused.

> Ok, I just wanted to give an example of how precedence rules works.
> The lookahead issue was examplified in an earlier post:
>
> true ()
>
> When the parser sees the 'true' token it cannot yet know if this is
> a node test for the element 'true' or if it will be the 'true'
> function call. It must look one token ahed, '(' in this case, to
> make that decision.

Yup. I get that. I just can't see how it manages with the case that I
put forward.

>> With:
>> 
>>    if and then * else - 2
>
> When the parser sees 'if', it must look one token ahead. If that
> token doesn't continue this subexpression and the end of the
> expression isn't reached, then we know for sure that this is the
> first keyword in a conditional expression.

So with the above expression, then the parser sees 'if', so it looks
one token ahead and sees 'and', so it knows that the 'and' isn't the
end token of the subexpression (that the end of the expression isn't
reached) so it assumes that the 'if' is the first keyword in a
conditional expression.

So if I just had the expression:

  if and then

then the parser would assume that the if was the start of a
conditional expression (by the same logic as above), just by looking
at the 'if' and the 'and', and therefore when it gets to the end of
the expression it would raise an error because the if expression
hasn't been completed.

So if I want to test whether I have both 'if' and 'then' child
elements of the context node, I have to do:

  (if) and (then)

so that the parser doesn't raise an error.

Right?

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread