This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: My favourite XSLT enhancement requests
> There are many proposals for additional features that would convert XSLT
> to the complete (and let's be honest, the *procedural* rather than
> *declarative*) programming language.
Personally I am not interested in that great a revision. I think the
language as it is now is very good. I'd prefer some syntactic sugar and
added power in a few wisely chosen places: something like xsl:function
for another way of having a named template -- not even escaping to a
scripting language, and perhaps evaluate(). (And the already agreed
conversion of RTF to node-set and known issues like regexps.)
I think dynamically scoped parameters would be useful, but I recognise
they have drawbacks. Someone wiser decide if they should go in.
If anybody knows how to get back to the original documents once you've
done apply-templates on a document(), I'd appreciate a hint. Best I've
been able to come up with is two passes, using RTF->node set to gather
all the necessary interesting details into one big variable and consult
that as I go. Then again, that might give the best performance anyway
since I'll have to generate index, glossaries, biblio and TOCs on the
fly anyway. :-/ Multi-document() keys/indices with ability to restrict
them to node subsets on lookup would be a help.
Hmm, this is starting to sound like I really ought to be using a
database and one of the database-aware XSL engines... But for now, I
need to stick to files.
Cheers,
//lat
--
Whoever said that love is blind was dead wrong. Love is
the only thing on earth that lets us see each other with
the remotest accuracy. --Martha Beck
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list