Re: Implementing Equality Expressions...

Subject: Re: Implementing Equality Expressions...
From: Tyler Baker <tyler@xxxxxxxxxxx>
Date: Sat, 02 Jan 1999 01:30:33 -0500
"eduardo.gutentag" wrote:

> "Tyler Baker" <tyler@xxxxxxxxxxx> wrote on Fri, 01 Jan 1999 18:31:06 -0500:
>
> > So instead of having a boolean expression
> >
> > [foo and @bar="baz"]
> >
> > You would always have:
> >
> > [(foo) and (@bar="baz")]
> >
> > This construction I have found is a lot easier to parse than the way
> > things currently are defined.
>
> That may be acceptable from a parser implementation point of view,
> but talk about user-hostile...

Another issue I forgot to note is more problematic with how things are
currently defined...

What do you do if you are searching for an element in the source tree that
matches "and" or "or".

For example:

[and and and]

or else something like:

[foo / and / or / and / bar]

e.g:

[foo/and/or/and/bar]

As I understand things, '/' are considered to be pattern tokens and therefore
follow the rules of pattern whitespace.  If you were to nest all primary
boolean expressions inside a boolean group expression for an "and" or an "or"
expression, then you would not need to worry about this problem that results
from the operators matching the same grammar as what you might find in a
PathExpression.

Tyler


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


Current Thread