Slashdot Mirror
Going from Perl to XSL?
linderdm queries: "I am a perl web programmer who has taken a new job that requires me to do web 'programming' using XML, XSL, and Oracle XSQL. My minor experience with XSL so far has been horrible! It is so hard to do things that were very easy in Perl (looping!?!) and just seems incredibly verbose. I am curious to find out what the Slashdot community's experience has been with web programming in procedural languages (Perl, Java, etc) then switching to tag based XML/XSL. Am I wrong to be trying to do procedural programming with XSL?"
It is important to remember that XML is not a programming language, it is a data format. XSL is also not a procedural language, it is a language for formatting data into a stylesheet. I refer you to the XSL page of the w3 :
XSL is a language for expressing stylesheets. It consists of three parts: XSL Transformations (XSLT): a language for transforming XML documents, the XML Path Language (XPath), an expression language used by XSLT to access or refer to parts of an XML document. (XPath is also used by the XML Linking specification). The third part is XSL Formatting Objects: an XML vocabulary for specifying formatting semantics. An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary. For a more detailed explanation of how XSL works, see the What Is XSL page.
So the short answer to your question is : no, XSL is not the right choice to do procedural logic. If you are doing something with your data other than displaying/formatting it, use something other than XSL. (Perl, Python, JSP, ASP, etc)
Going from Perl to XSL is like going from Water to Potatoes.
;)
They solve different problems.
As a programmer, your toolset should include more than one tool. Perl simply cannot be beaten for text processing. XSL is probably the best out there for processing XML into other XML, but this space is immature so be on the lookout for better solutions. Java (and C#) is great for building large enterprise applications or applications that benefit from a lot of object-orientation. C is good for programming close to the metal. Python is excellent for development speed, prototyping, and general-purpose code. Fortran is still among the best out there for heavy-duty numerical programming. Prolog rules for AI. Functional languages are great for solving complex algorithmic problems. Basic is good for, well, nothing
Learn as many different languages as you can find. Then use the right tool for the job. If you find yourself worrying that a particular thing you need to do is hard in the language you're using, you're either taking the wrong approach to the problem (I believe XSLT allows some kinds of problems to be solved *without* looping even where they'd require looping in Perl) or you're using the wrong tool.
Note: I can't say I've met all these requirements myself. My own programming experience is conspicuously missing Lisp, Scheme, Fortran and XSLT, and I only learnt one semester's worth of Prolog and never used it since; ditto ML which is the only functional language I know. And I haven't gotten as far into Python as I'd like.
But I do know enough of each to know when I'm faced with a problem that one of them might be best for.
XSL is a transformation language. Don't think in loops, think in templates.
I see horrible XSLT work where people try to use evil for-each constructions...
And the fact that XSL is an XML application ('tag-based' as you call it) has nothing to do with it being procedural or nonprocedural, it's just a syntax issue (which can annoye me when writing more complex transformations, I think we will see more powerfull transformation languages like stratego in the future).
Yes.
I get the impression that you're not familiar with the functional programming style. Functional programming is a style in which the entire program is defined as a function. There are a number of languages which support functional programming. (Lisp and Haskell are probably the most famous, but XSLT is a functional language as well.) I'm not going to explain the entire theory behind functional programming at this stage. I'll just say that if you wan to be able to use XSLT as anything more than a glorified template system, you'll have to learn about functional programming.
You ask where looping is in XSLT. Well, functional languages tend not to do looping. You have to do it all using recursion.
If all you've done is procedural programming then it will seem very weird for a while. It takes some time to get good at it. I experienced a period of frustration when I first started with XSLT, but once you realise that it's functional, it suddenly becomes quite a powerful language.
Functional programming requires a completely different mode of thinking than procedural programming. Anybody who understands the definition of "procedure" in ordinary English understands the procedural programming paradigm, even if they don't know the technical details. But the functional programming paradigm is a lot less commonplace, and takes some getting used to. Before tackling XSLT, it might make sense to try to pick up some fundamental FP concepts. One way to do this would be to work through the leading functional programming textbook. (It says a lot about MIT that they've gone and made the entire book available online!)
It is kind of irritating that XSLT's creators decreed that a syntactically correct XSLT program had to be a well-formed XML document -- and thus rather verbose. But that sort of thing rather goes with the FP mindset -- FP source is supposed to be easily transformable using the same language it's written in. That's why there are Lots of Insipid Silly Parentheses -- and so few syntax rules -- in languages like Scheme.
It's worth mentioning that Perl, though basically a procedural language, has some of the same design philosophy as the FP languages. It's easier to code a simple loop in Perl than in an FP language -- but Perl has as many ways to avoid coding a loop as any FP language!
Also worth mentioning that XSLT and XSL are not quite the same thing. XSLT is the transformation language for XSL. It's a relatively recent invention. As originally conceived by Microsoft (yep, the evil empire was the biggest partner in drawing up the original XSL spec), transformation languages were a mix-and-match affair. A lot of early examples had XSL stylesheets with embedded Visual Basic code!
Come to think of it, it wouldn't be hard to do a stylesheet language based on Perl, or to evolve a convention for embedding Perl instead of XSLT in XSL stylesheets. Now, why do you suppose nobody is working on that. Uh, that's a rhetorical/socratic question!