Subject: Re: XSL Working draft question From: Ray Cromwell <ray@xxxxxxxxxxxxxxx> Date: Fri, 21 Aug 1998 11:01:17 -0400 (EDT) |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: XSL Working draft question, Gavin Thomas Nicol | Thread | Re: XSL Working draft question, James Clark |
RE: XSL Working draft question, Gavin Thomas Nicol | Date | Re: Any examples of server side XML, James |
Month |