Re: No side effects holy cow. ( Re: process order (still...)

> 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 [expletive deleted] 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