Re: Implementing Equality Expressions...

James Clark wrote:

> I don't understand exactly what the problem you're having is, but there
> are a couple of tricks you can use to parse And/Or expressions:
>
> - one is to keep some state in the lexer; this is the way the spec does
> it: "An OperatorName token is recognized only when there is a preceding
> token and the preceding token is not one of @, /, |, (, [ or an
> OperatorName."
>
> - the other is to parse a BooleanExpr as if it were
>
> BooleanExpr ::= BooleanPrimaryExpr (Name BooleanPrimaryExpr)*
>
> and then check separately that each Name is either "and" or "or" and are
> not mixed in a BooleanExpr (this is what I do in XT)/

In the meantime, I have since found a third solution that works nicely as
well.  Essentially, for Equality Expressions, simply check for "and" or "or"
if there is an equals number of '(' and ')' characters (in other words when
boolean expressions are no longer nested inside).  If an occurrence of "and"
or "or" is found before finding a "=", then the expression is not an equality
expression but merely a test expression.  This works provided that none of the
expressions in the "and" expression or "or" expression are test expressions
with element expressions with names of "and" or "or".

Anyways, as usual thanx for the heads up.  However, as per my last post, I am
a bit unclear as to whether the problem with having element expressions inside
a test expression that is all contained within one "and" expression or "or"
expression.  I really don't see any way around this problem other than to nest
each expression in an "and" expression or an "or" expression inside boolean
group expressions or else outlaw use of the names "and" and "or" in element
expressions.

Tyler


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