> 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?
book[excerpt] seems wrong to me. It should be book[has-child(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?)

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. With the
regular expression approach, I can compile a whole bunch of XSL
rules into an efficient data structure and "match all simultaneously"

But with the boolean expression approach, I end up having to actually
evaluate an expression for each rule. Worse, I have to write a 
parser and evaluator for a totally new language. 

I guess the main question that keeps popping up for me is, what's
wrong with CSS-style selectors? What kinds of queries is XSL going
to allow that are really useful that I can get already with CSS?

If there is a query that a CSS style selector can't do, then XSL
should simply allow the user to use ECMAScript as a hook to feed
XML nodes into the back end formatter. XSL's pattern matching
should handle the 90% most common queries, and leave the other
10% for a low-level mechanism or extensible hook.


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