I guess as a maintainer of an XSLT Module I had better get my oar in here.

I'm certainly with mirod on the matter of showing the code - both the Perl and the XSLT, and there are threads out there where This is the case. This is after all a technical environment where I would have thought code speaks stronger than words.

XSLT is not a panacea for XML -> HTML, XML-> XML or XML -> (anything else you care to suggest) conversion (hey I have used it to create SQL in the past - but I would.) but for a quite large set of these conversions it is certainly something that should be considered - it's strength mostly comes to the fore where the presence of the XSLT processor can be taken for granted ( such as with some web browsers or mod_xslt for Apache) of course this part would it put it beyond the scope of a purely Perl discussion. Where you are creating perl code that performs XSLT processing (probably using some module) it is likely that you are creating some sort of framework where you wish to delegate the formatting of output to something external to your code - in this respect it is similar to a templating mechanism such as that embodied by Template. I would rather suggest that a web designer (for instance) fiddle with XSLT than with a bunch of Perl code (they are used to dealing with all those angle brackets after all ;-)

Stylesheet as a term in computing is probably too heavily overloaded - it has been used with respect to wordprocessing documents at least since WordPerfect started using it - but in one sense it does capture what XSLT does: given some input document it will determine what is output. After all we are talking about Extensible Stylesheet Language Transformations here - for myself I would always call it an XSLT Stylesheet to make it clear that it is is something different from CSS or something that takes that hard work out of formatting a Word document. As for whether the use of the term should trivialise the effort in the mind of some PHB, to be honest I haven't really seen it - but it certainly does make it easier to sell to the management rather than "we are going to write this complicated code in Perl using $some_module that will munge the XML in such and such a way..." - but there again in my working life these days I am a business analyst and project manager first and only a Perl programmer when the need arises; I see XSLT as an opportunity to separate the development of a system into three separate concerns: the design of the data (XML) that is to processed, the mechanism by which that data is to be managed and processed (the program or programs themselves), and the actual processing and presentation of the output (XSLT). YMMV however.

So to the original point. For myself, if I were to see a question which warranted it I may very well suggest the use of XSLT, however I certainly would endeavour to provide an example and also suggest an alternative if only as a counter-example as to why you might not want to munge XML with custom perl code (which in my experience is often the case.)

/J\