Subject: Re: What will be the future improvements of XSLT? From: James Clark <jjc@xxxxxxxxxx> Date: Fri, 17 Sep 1999 01:15:15 +0700 |
Oren Ben-Kiki wrote: > Miloslav Nic <nicmila@xxxxxxxx> wrote: > > If reuse of result trees was possible, 90% off my problems and ugly > > hacks would disappear. I would really appreciate to know the rationale > > why the spec says what is says (implementation problems?) > > This was discussed in this mailing list; the main reason given was that by > limiting XSLT to a "single pass" it would be easier to implement > "incremental" XSLT processors. Such processors are deemed important for > editors etc. I don't know whether this was in fact the main reason for it - > and we wouldn't know unless some WG member confirms it. That's the main reason. One important point is that if future experience with implementation of incremental processors shows this restriction to be misguided, then it will be easy to relax it in version 2 whilst remaining backwards compatible with version 1, either by treating result-tree fragments exactly the same a node-sets or by adding a node-set() function to perform the conversion explicitly. The converse is not true. It's possible in the meantime for implementations to legally provide this functionality via an extension function, as Michael Kay observed. I hope that we'll see some sort of informal standardization in the XSL community of common extension functions and extension elements, which can provide the basis for an eventual XSLT v2. James XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: What will be the future improve, Oren Ben-Kiki | Thread | RE: What will be the future improve, DPawson |
procedural style XSL, Earl Bingham | Date | Re: The XSL-List Digest V2 #302, Rodney Waldhoff |
Month |