Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Just use an XSLT stylesheet

by mirod (Canon)
on Apr 12, 2004 at 11:31 UTC ( #344355=perlmeditation: print w/replies, xml ) Need Help??

Twice in the last week, and many times before, I have seen a question about XML answered by a short post saying in essence just use an XSLT stylesheet.

This irks me to no end, and, after thinking a bit about it, I thought it deserved a meditation.

My first comment would be: show me the code! Here on Perlmonks we tend to answer questions with Perl code, showing ways to solve the poster's problem. For some reason, invoking XSLT seems to absolve people from doing so. Please, if it is so easy to use XSLT, then show us how. After all most questions here ould be answered with a short "just use Perl" comment. Or "just use assembly language" for what matters. Posting some code would indeed show how easy it would be to use XSLT to solve the problem... or not. XSLT is not an appropriate tools for all XML transformations. It would also educate us about XSLT, and generally be a lot more useful than just waving the magical XSLT wand.

I also have a problem with the word stylesheet. It might be the usual designation for a piece of XSLT, but I think it hides the fact that XSLT is code. XSLT is a programing language and you code in it. Stylesheet is a great word for PHBs to use: it implies that the task is simple, should take very little time, and that the skill level involved is minimal. As programers I think we should consider it a very dangerous word. A long time before XML even existed, there was a language called FOSI, used to format SGML documents. My company used it to format aircraft manual. It was a real tough battle to get the powers that be to admit that writing a proper FOSI stylesheet for a complex manual took about a month. After all it was only a stylesheet. Don't let this happen to you.

Finally, my, admittedly limited, experience with XSLT is that it doesn't offer much that Perl + a good module would: on the plus side it leads to safe, side-effect free code, that is easy to reuse. On the minus it is very verbose, the language gets in the way a lot more than Perl, both syntactically (processing XML with an XML syntax is a sure way to lead to delimiter collision) and semantically (as a drawback of the no-side-effect philosophy) and it lacks the wealth of modules that CPAN offers. Overall the select-with-XPath => transform pattern is very similar in XSLT and in XML::LibXML, XML::XPath or XML::Twig code.

In short, yes coding in XSLT can be an option for XML transformation, but if you want to recommend it, then just prove it!

Replies are listed 'Best First'.
Re: Just use an XSLT stylesheet
by liz (Monsignor) on Apr 12, 2004 at 12:38 UTC
    ...and it lacks the wealth of modules that CPAN offers.

    Please note that XML::LibXSLT, the XSLT companion to XML::LibXML offers the "register_function" functionality which allows Perl functions to be called from stylesheets. An example (directly from the XML::LibXSLT documentation):

    XML::LibXSLT->register_function("urn:foo", "bar", sub { scalar localt +ime });
    and then later in a XSLT stylesheet:
    <xsl:stylesheet version="1.0" xmlns:xsl="" xmlns:foo="urn:foo"> <xsl:template match="/"> The time is: <xsl:value-of select="foo:bar()"/> </xsl:template> </xsl:stylesheet>

    This implies that CPAN modules can be made available at least in stylesheets using XML::LibXSLT.

    I've used this approach for a client, who is now running about 40 syndicated websites out of a single database in production using this approach. Even the associated CMS is using XML::LibXSLT with special custom functions for handling forms and updating the underlying database.

    Typical modules that I've made available that way (directly or indirectly) are DBI, LWP::UserAgent, POSIX, Digest::MD5, Email::Valid, Time::ParseDate, etc. etc. etc.


      But then, what is the upside of using this versus using perl + XML::LibXML for example?

      I understand that you simply offer custom functions, and that the users only have to know XSLT and those functions, not Perl in general, but is it really worth it? Is it so much easier to code XML processing in XSLT? Or is it a way to take the full power of Perl off the hands of inexperienced coders, using XSLT as a way to limit what they can do? That is a real question by the way, not a devious way to put down XSLT ;--)

        Or is it a way to take the full power of Perl off the hands of inexperienced coders, using XSLT as a way to limit what they can do?

        That's one way of putting it. This website started in 1995 originally, with a mixture of pregenerated pages from an Access database and pages that were kept up to date manually.

        The 1998 incarnation used Perl and MySQL, but did not have seperation of layout and content. Which meant, that as changes in layout were needed, I was needed to make changes to the underlying Perl code.

        The 2002 incarnation used the old database (which also generated XML) and XML::LibXSLT.

        The 2004 incarnation uses XML::LibXSLT and MySQL for everything. Now I don't have to worry about layout anymore. And the client can change layout whenever and however they feel like. Even for the CMS!

        I'm happy. The client is happy.

        I'm not saying it is the end to all means. But it was the right solution in this case. The other day they even added an RSS feed without me having to do anything!


•Re: Just use an XSLT stylesheet
by merlyn (Sage) on Apr 12, 2004 at 11:58 UTC
    I hate typing angle brackets to begin with. XSLT just requires that I type even more. {grin}

    As Yet Another Alternative in your list of "things that select XML parts and reformat them", look at XML::XSH, which is a nice hybrid between Perl and XPath, and even makes a good domain-specific scripting language. Of course, I've written columns on it as well.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

Re: Just use an XSLT stylesheet
by CloneArmyCommander (Friar) on Apr 12, 2004 at 15:48 UTC
    I completely agree with mirod :). I think some of us forget Perl's function as a glue language. If we keep redirecting other monks to solve their problems with other languages, such as XSLT, and I've even seen PHP, then we are slowly abandoning Perl, and even the Perl motto, "there is more than one way to do it." Instead of redirecting XSLT questions and saying the only way is XSLT, we should be looking into how can I find other ways to do it with Perl, as mirod says. This is what attracted me, and most likely other perl programmers, to this wonderful language.

      No. TMTOWTDI shouldn't be abused to say "More than one way, as long as that way is in Perl". If XSLT could show sizeable benifits for XML manipulation over Perl + (insert CPAN module), then people's statements to suggest XSLT over Perl would be completely justified.

      However, XSLT is often far more verbose than a similar solution in Perl would be (there's an excelent article on comparing XML manipulation in XSLT, Perl, and Haskell). That's the reason why people should avoid blindly suggesting the use of XSLT over Perl, not because it's not Perl.

      Being a good coder means knowing your tools and how best to apply them. Perl happens to be one of the most flexible tools you can find, but sometimes it isn't the one that should be used.

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

      I don't see that its good for anyone to advocate anything blindly. Perl is not the only solution, and in some cases, it is the wrong solution. I enjoy programming in Perl too, but I don't want to live next to a nuclear power plant where the control systems are written in Perl.

      mirod's point is that there are often solutions to problems with XML other than "just use XSLT". Many of the modules listed above often can handle the problems seen in SOPW. There, people are looking for suggestions or sample code to solve problems that they are running into. He's not blindly advocating Perl as the only solution, he would just like some code from people advocating an XSLT-based solution.

        Perl is not the only solution, and in some cases, it is the wrong solution.

        ..Now that is just crazy talk, Perl is the only solution, well 95% of the time...okay I'll give you that whole nuclear plant scenario.

      To clarify my point: I am actually not saying that you should not use XSLT, I happen not to like it, but that's a purely personal opinion.

      Really, if anyone feels like it offers a good solution for a specific problem, then I am all for them proposing it. I would just like to see the code, exactly the same way we usually post code to show how we would use Perl. Hey, if I see enough code, and if it makes easy things that are hard to do in Perl, I might even start using it!

      On the other hand there may be those who actually want the best solution to a problem (or maybe need it and just don't realize). I would imagine there are few here who would disagree that Perl is a powerful and expressive language with application in a wide range of problem domains, however there are going to be times when writing a Perl program, however cool and elegant, is not the best solution given the statement of the problem. This of course is not isolated to questions which may elicit the response 'use XSLT'.

      I'm not sure mirod was saying "how can I find other ways to do it with Perl" I think it was more like "give me an example that shows this is better than doing it with Perl" with which I heartlily concurr.


Re: Just use an XSLT stylesheet
by gellyfish (Monsignor) on Apr 16, 2004 at 09:44 UTC

    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.)


Just use an XPathScript stylesheet
by bronto (Priest) on Apr 15, 2004 at 17:16 UTC

    Good point, mirod.

    I recently replied to an XML-transformation-with-perl question suggesting to use XML::XPathScript, without giving any further information. Mh... right. Next time I'll try to show an example along with the suggestion!

    I am an happy user of XPathScript. When I started playing with AxKit I didn't have time to learn all the XSLT that I needed to do the things I had to do, but I knew enough Perl and I read enough XPath to get the job done

    Well, XPathScript is not standard as XSLT is, so I won't reccomend to use it for portability. But if one knows some Perl and has the need to transform XML in something else from time to time, I'd give XPathScript a chance. I think we should suggest it more often as a pure perl solution.


    The very nature of Perl to be like natural language--inconsistant and full of dwim and special cases--makes it impossible to know it all without simply memorizing the documentation (which is not complete or totally correct anyway).
    --John M. Dlugosz

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://344355]
Approved by jmcnamara
Front-paged by calin
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (7)
As of 2017-01-23 15:54 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (194 votes). Check out past polls.