Subject: Re: No side effects holy cow. ( Re: process order (still...) ) From: David Carlisle <davidc@xxxxxxxxx> Date: Fri, 14 Apr 2000 10:39:30 +0100 (BST) |
> I was trying to find some rationale behind some statements I found > in W3C documents. Rationale in press releases? Surely not. > 2. 'Ordinary developers' are not very happy when I explain to them > that they have no variables, so they need to re-iterate over the tree > with 'count()' function instead of just incrementing the counter. Perhaps it's the way you describe it:-) If you don't like the language it's likely that you put a `spin' on it that makes students suspicious. > Are you saying 'ordinary persons are not happy with variables', I consider myself ordinary, and I'm quite happy without them. I can't speak for other people. > That means people *will* use extension functions and > extensions functions *will* have 'side-effects'. This is unfortunately probably true. I think XSL is an experiment in designing a declarative side effect free language for document translation. You may be right that current machines or current people are not ready for that and want or need a more procedural language to do these translations. That is not an unreasonable point of view, but I would say that it is unreasonable to produce such a language by taking the current XSL design and bolting on constructs from a different paradigm. If a procedural language had been the aim the whole language would have looked different. Of course you may also be right that political pressure to call the transformation language `XSL' will mean that designing a different language is not an option and so the pressure to pollute XSL will not go away. I'm just glad I'm not a politician. As for current unextended XSL only being suitable for small documents I don't know what you mean by small (or by a document). The MathML spec runs to about 400 pages printed and is produced in a single run with xt. (one for the html version and one for tex) This is reasonably large as a traditional document goes. If you mean sucking gigabytes of database into a single XML tree to be held in memory by the JVM then true the current `all in memory' approach of xsl implementations breaks down rather fast. David XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: No side effects holy cow. ( Re:, Paul Tchistopolskii | Thread | Re: No side effects holy cow. ( Re:, Paul Tchistopolskii |
RE: The XSL-List Digest V2 #598, Richard Bell | Date | RE: mailing list, FINLEY, Mike |
Month |