Re: Why XSLT and not just Perl?by Arguile (Hermit)
|on Jun 15, 2003 at 01:52 UTC||Need Help??|
Many good points have been raised about why XSLT exists, I won’t rehash them. I’d like to focus on this specific statement:
It just seems crippled compared to more robust languages (if XSLT can be considered a true language since there are no for or while functions, only for-each).
XSLT is not meant as a procedural language. Lisp, Scheme, Haskell, Prolog; are these not programming languages because they don’t include procedural loop constructs? When you create an XSLT document (script? program?) you don’t worry about the how of it, you just say what you want done. XSLT is a declarative language, and it's power lies in that.
Notice all the how bits; variables controlling when to loop and when to stop looping, the loop contructs themselves, conditionals to see if we’re in the tag or out of it, etc. Notice also that the program resembles the layout of the HTML document. What happens if the elements we want are three deep? Four? What about multiple distinct operations? Specification changes?Now let’s look at an XSLT example of the same procedure (we’ll just imagine the encode_enties function exists):
None of the how is needed in XSLT. You simply state what section of the document you’re interesetd in with XPath, what to do there, then apply the directive. Gone is the overhead (pre-amble, variables, loops, etc), the ties to the document structure, and problems with adding new rules. The how has been removed.
I'm not saying XSLT is the be-all or end-all, but it fits it's problem space well. Not being procedural can be a strength, you just have to learn to use it.
* Please note I'm not in any way insulting the answer, ‘trivial’ refers to the scope of my example.
Note: This obviously isn’t the only way to do XML transforms in Perl. However, it does illustrate (I hope) some of the differences between general and task based languages, as well as procedural vs. functional/declarative approaches.