> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
<snip/>
> >>You can do many things with XSLT, but also with Java, C,
> Assembler...
> >>It's just a matter of picking the right tool for the right job.
> >
> > That's right - that's why we shouldn't tell people "never
> use XSLT for
> > inclusion". That's too dogmatic. Sometimes XSLT is the right tool.
>
> It's correct if I tell you not to write your web application in
> assembler, IMO it's not dogmatic.
> The fact is that IMO XSLT is not the right tool for this job.
Well XSLT is not VERY much like assembler ;-)
I've often found it necessary to use XSLT to transform a source document to
use <xi:include>, but the tricky thing is when you need to do this
recursively: to aggregate an entire grove of documents starting from a root
document ... at each document the XSLT has to identify documents to include,
and use <xsl:apply-templates select="document(@href)/> to include them
recursively, or it can create the xi:include elements, but in that case
(using xi:include) then you must invoke XIncludeTransformer and again the
XSLT and again the XIncludeTransformer, until the tree is complete.
In the worst case (this is an actual case I had, in fact), you have a
linked-list of documents. If using the XIncludeTransformer, to traverse the
list n documents long (I had n>100, sometimes >200), requires n simultaneous
invocations of the sitemap, XIncludeTransformer, XSLT transformer, etc. In
most cases though you would be traversing a much shallower grove.
I've lost the code I wrote, but I'll recreate it and post it to the list ...
it was very small and tidy and worked pretty well (apart from the caching
problem) - it didn't violate SoC in any signifant way I could see.
> Well, the main problem with using XSLT for aggregation is
> that you can
> simply use also the other things that don't only aggregate,
> and this is
> really asks for abuse ;-)
>
> Instead, if I define my XSLTI xml syntax, limited to defining
> tags that
> include, and then use XSLT underneath as a motor, but without
> having the
> user use it directly, I have effectively wrapped it.
Hmmm ... I think this is an interesting idea. It could be implemented as a
compiler, with its own pipeline:
<map:match="xslti-to-xslt/**">
<map:generate src="xslti/**"/>
<map:transform src="xslti-to-xslt-compiler.xslt"/>
<map:serialize/>
<map:match>
<!-- and to call the compiler, e.g. when aggregating a website: -->
<map:match="traverse-website/**">
<map:generate src="{1}" type="html"/>
<map:transform
src="cocoon:/xslti-to-xslt/html-post-order-tree-traversal.xslti"/>
<map:transform src="
</map:match>
