## Re: URL decomposition - Some things are better done outside of XSL!

 Subject: Re: URL decomposition - Some things are better done outside of XSL! From: David Carlisle Date: Thu, 25 May 2000 14:19:18 +0100 (BST)
> Find some non-xsl way of doing this, mate. XSL may be great, but it is
> not a panacea.

I agree with that but actually I don't think using recursion in this
case is at all bad. It looks verbose because, well because XSL syntax
for passing parameters is painfully verbose. But given some standard
libraries of named templates for doing while loops, for loops, file
component of a url etc, does it really matter if there are a few tens of
lines of recursive calls sitting behind the template? (and really efficient
implementations might cheat by implementing some named templates
directly) Of course, a standard library doesn't exist yet but it's early
days.

For those of you who know the latex typesetting system (which is a
formatter that essentially works by macro expansion)
try

\tracingall
\documentclass{article}
\begin{document}
\section{hello world}
test
\end{document}

If you do that, you get 30797 lines of tracing in the log file, almost
all of it tracing nested recursive macro expansion calls.

If users really thought that's what was happening when they type
\section
then they'd never do it, but of course that's not how you do think of
it, you just think of it as declaring a section heading.

It is the same with XSL, except that at the moment, rather than saying
(in latex-speak)
to get a section heading load the article class library of macros and
then use \section

people are being told to get a section heading here is 100 lines of
code that implements what you want.

The danger is that if people reach too quickly for extensions then all
hopes of portability between XSL implementations is lost.

Of course a cross platform extension mechanism/namespace would help a
bit, but still doing things within xsl is the surest way of having
portability across xsl systems.

David
[having said all that, doing string handling in XSL without a standard
set of regexp search and replace functions is in general not a good
idea]

XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list