This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
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 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