Subject: Re: Can solve the N-queens - but can't count! From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Sun, 20 Jun 1999 11:00:23 +0200 |
James Clark <jjc@xxxxxxxxxx> wrote: >I wouldn't assesss the feasibility of such [incremental] >implementations on the basis >of whether it's possible to create cases that such implementations will >handle very inefficiently: I don't think it's possible to create a >transformation language that does what XSLT needs to be able to do and >yet does not permit such cases. Agreed. >I would instead assess the feasibility >on the basis of how well the implementation does for typical >stylesheets, how well it does on average. This is very hard to >quantify. This is a fine way of assesing implementations, but it is not a good way to assess proposed language features. >There are lots of things in XSLT today that probably make an >incremental implementation harder: xsl:for-each, modes, named templates, >parameters, local variables, absolute location paths, upwards and >sideways axes (ie axes other than descendants and children), result tree >fragment values for parameters and variables. Making a judgement about >where to draw the line is hard. I'll freely admit that I'm worried >about whether XSLT has drawn the line in the right place, but my worry >is not that we've left things out but rather that we've gone too far and >put too much in. However I have a hard time thinking of things that I >would be willing to see left out of the current WD. Once we've given up on XSLT as a language which can be implemented purely "incrementally", I don't see the point in drawing the line at all. Once such a line is breached, it becomes irrelevant. Using it as a criterion hampers the stylesheet writers and doesn't gain anything for the implementers. Instead, I'd rather focus the effort on protecting the remaining lines without hampering the stylesheet writers - for example, how to express side effects free loops. The usual criteria still remain, of course - the usual tradeoff between language complexity and power, usefulness for "real world" applications, ease of implementation, etc. I think in these respects loops and the matching on result tree fragments feature are no worse then, say, modes and some of the more esoteric axes. Share & Enjoy, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Can solve the N-queens - but ca, Kay Michael | Thread | ANN: SAXON 4.3 (XSL interpreter and, Kay Michael |
Re: , Jon Smirl | Date | Re: XSL Optimizations, Lars Marius Garshol |
Month |