Subject: Re: Practical Suggestion for XSLT Performance Improvement From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Mon, 11 Oct 1999 11:24:34 +0200 |
Clark C. Evans <clark.evans@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 10 Oct 1999, Oren Ben-Kiki wrote: > > Actually, it is worse then that. The war is lost if you use > > select="$complicated-path" _anywhere at all_, even in the humblest > > <xsl:value-of>. You also get in trouble by using multiple > > <xsl:apply-templates> on the same input tree fragment > > Oren, thanks for responding! Back from my three weeks military duty for this year :-) > To have one-pass stream > processing (XSLTS), extreme (but not unreasonable) limits > must be placed on the stylesheet: Right. Defining them is a tricky issue. What you described is a bit too restrictive; you can get away with some forms of match clauses for <xsl:apply-templates/> and <xsl:for-each/> - refering just to descendents of the current node, for example. Specifying multiple calls in the same template would be prohibited, except for matching on attributes. Or something. In fact, this is complex enough that if (when...) the need for streaming XSLT becomes pressing, it would be worth while to define this formally - either by the W3C or by someone else. The cause of the problem is that XSLT started with a vision of a language powerful enough to do "most" transformations but simple enough to allow all sorts of automatic reasoning/optimizations implementation techniques. The first requirement has resulted (for good and sufficient reasons) in adding enough features so that it became Turing complete. Therefore, second goal is lost _in the general case_. On the other hand, some restrictions which originated from this second goal were not lifted - in particular, matching on result tree fragments. This means that while you can do "anything" in XSLT, sometimes you have to write pretty convoluted code to achive it. For example, you _can_ pass data from one template invocation to another. You just need to encode it as a string instead of as a result tree fragment. I posted a sample to this mailing list a while back. It was an XSLT program which computed solutions to the N-queens problem. Admittedly people will use such code only as a last resort. The benchmark for sums over a really large document might be a good example for a place where it might be necessary/ Your named-pipe mechanism is one possible way to remove the remaining restrictions. However, as I see it, there's a much minor change to XSLT which would achieve the same effect - removing the restrictions on matching on result tree fragments. It seems to me that anything which can be done using named pipes can be done as easily using such fragments. Unless you have a counter example? > Perhaps there are two ideas here, the first one > describing a limited subset of XSL for stream > procesors Something which is probably wothwhile... > and the second one is more of a > "network of stream processors" working togehter > in a generative manner. So, mabye it is not > at all appropriate to build in a "return-pipe" > mechanism, but it may be more appropriate to > describe a "reaction document" (to use Stefano's > idea in the Coccon project), which documents a > collaboration of stream processors working together > in a recursive manner. Then, some framework would > have to be built which animates this larger structure. Which simply isn't XSLT as we know it. It is impractical to switch tracks at this very late stage of the game. After all, it isn't a draft now - it is already a proposed recommendation. > Does this make sense? Actually it makes perfect sense to me. My master thesis has dealt with a side-effects free, actors-like data-flow language which I still feel is the "one and only right way to write non-sequential code". Think of it as the framework you mentioned. It is a beautiful concept... but it never made it into the mainstream. Yet another casualty of Moore's law... Have fun, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Practical Suggestion for XSLT P, Clark C. Evans | Thread | Schema definition, Eric van der Vlist |
XSL - How do you put a <!DOCTYPE> i, Dylan Walsh | Date | Re: foo ... bar Re: Q: XML+XSL tran, Sebastian Rahtz |
Month |