36 messages in com.mulberrytech.lists.xsl-listRe: What will be the future improveme...
FromSent OnAttachments
Tangi VassSep 15, 1999 1:34 am 
Kay MichaelSep 15, 1999 2:52 am 
James ClarkSep 15, 1999 3:27 am 
Oren Ben-KikiSep 15, 1999 4:16 am 
Sebastian RahtzSep 15, 1999 5:04 am 
Tangi VassSep 15, 1999 6:12 am 
David CarlisleSep 15, 1999 6:38 am 
Miloslav NicSep 15, 1999 7:13 am 
Sara MitchellSep 15, 1999 7:24 am 
Sebastian RahtzSep 15, 1999 7:32 am 
Sebastian RahtzSep 15, 1999 7:36 am 
Tim McCuneSep 15, 1999 7:49 am 
Didier PH MartinSep 15, 1999 8:53 am 
Chuck WhiteSep 15, 1999 9:21 am 
Tangi VassSep 15, 1999 9:27 am 
Khun Yee FungSep 15, 1999 12:25 pm 
Simon St.LaurentSep 15, 1999 1:07 pm 
Steven LivingstoneSep 15, 1999 1:24 pm 
Hunter, DavidSep 15, 1999 2:27 pm 
David CarlisleSep 16, 1999 1:19 am 
Kay MichaelSep 16, 1999 2:42 am 
David CarlisleSep 16, 1999 3:04 am 
DPaw...@rnib.org.ukSep 16, 1999 3:24 am 
Miloslav NicSep 16, 1999 4:38 am 
DPaw...@rnib.org.ukSep 16, 1999 4:41 am 
David CarlisleSep 16, 1999 5:28 am 
zu...@falconwing.comSep 16, 1999 5:57 am 
Oren Ben-KikiSep 16, 1999 5:57 am 
DPaw...@rnib.org.ukSep 16, 1999 7:10 am 
Khun Yee FungSep 16, 1999 7:29 am 
Kay MichaelSep 16, 1999 8:13 am 
David CarlisleSep 16, 1999 8:22 am 
Earl BinghamSep 16, 1999 11:08 am 
James ClarkSep 16, 1999 11:14 am 
Kay MichaelSep 17, 1999 10:41 am 
David CarlisleSep 20, 1999 1:48 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: What will be the future improvements of XSLT?Actions
From:James Clark (jj@jclark.com)
Date:Sep 16, 1999 11:14:53 am
List:com.mulberrytech.lists.xsl-list

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