Re: XSL Working draft question

[James Clark <jjc@xxxxxxxxxx>]

Ray Cromwell wrote:
> 
> > Square brackets do selection. An expression of the form e[b] evaluates
> > b returning a result X and for each node in X evaluates b; it returns
> > the set of nodes from X for which b evaluates to true. b is a boolean
> > expression which is an expression that takes an input set of nodes and
> > returns true or false.  Any query can be used as a boolean expression
> > and will evaluate to true if it returns an empty node set.
> 
>   How does the current XSL child qualifiers fit with this though?

Perfectly.

> book[excerpt] seems wrong to me. It should be book[has-child(excerpt)]

"excerpt" as a query expression selects child elements of type
"excerpt".  So if you use it in a boolean context it's true if there's a
child of type "excerpt".

> Is XSL going to support boolean logic?
> 
> book[has-child(excerpt) && attribute(child(excerpt), "foo") = "bar"] ?
> 
> (book nodes that have a child named 'excerpt' which has a foo
> attribute with the value bar?)

I would expect so, though the syntax you would get from the current
draft would be:

  book[excerpt, excerpt/attribute(foo) = "bar"]

> It seems to me like this is the wrong way to go about things. Either
> XSL patterns should be equivalent to regular expressions on a tree
> (i.e. one can view chapter/section/title  as "match a chapter token,
> followed by a section token, followed by a title token), and indeed,
> it is very efficient to compile a whole bunch of patterns into
> a finite automaton. Or, XSL patterns are basically assertions in
> a scripting language about DOM properties.
> 
> In the second case, why invent a new language? Why not simply use a
> subset of ECMAScript with some kind of DOM-hash convention.
> 
> The problem I have with the idea of a qualifier being an arbitrary
> boolean expression is that it prevents optimizations.

I never said arbitrary boolean expression.  I said "boolean expression"
meaning it's some syntax that evaluates to a true or false value. 
There's nothing about that which inherently prevents optimization.

James



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