Re: Can solve the N-queens - but can't count!
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format