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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Implementing Equality Expressio, eduardo.gutentag | Thread | Re: Implementing Equality Expressio, James Clark |
New XT release, James Clark | Date | XT extension mechanism, James Clark |
Month |