Subject: Re: XSL Working draft question From: James Clark <jjc@xxxxxxxxxx> Date: Sat, 22 Aug 1998 06:21:11 +0700 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSL Working draft question, Ray Cromwell | Thread | Re: XSL Working draft question, Randy Waki |
Re: Any examples of server side XML, James | Date | FOP: A formatting object to PDF con, James Tauber |
Month |