Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: Why XSLT and not just Perl?

by Arguile (Hermit)
on Jun 15, 2003 at 01:52 UTC ( #265989=note: print w/ replies, xml ) Need Help??

in reply to Why XSLT and not just Perl?

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.

A great example of the difference is an answer to a question asked today. Granted it’s a trivial example but it illustrates a larger point*.

# Copied from node 265898 by valdez. Cut and modified slightly. use HTML::TokeParser::Simple; use HTML::Entities; my $parser = HTML::TokeParser::Simple->new( 'filename' ); my $in_body = 0; while ( my $token = $parser->get_token ) { if ($in_body) { # we are inside BODY if ($token->is_text) { # it's text, convert it print HTML::Entities::encode_entities($token->as_is); } else { if ($token->is_end_tag( 'body' )) { # we've found the end of the BODY $in_body = 0; } print $token->as_is; } } else { if ($token->is_start_tag( 'body' )) { # we've found the beginning of the BODY $in_body = 1; } print $token->as_is; } }

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):
<xsl:stylesheet version="1.0" xmlns:xsl=" +ansform"> <xsl:template match="body//text()"> <xsl:value-of select="encode_entities(.)"/> </xsl:template> </xsl:stylesheet>

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.

Comment on Re: Why XSLT and not just Perl?
Select or Download Code
Re: Re: Why XSLT and not just Perl?
by mirod (Canon) on Jun 16, 2003 at 17:04 UTC

    In fact the difference you are showing stems from 2 things: mostly that XSLT uses a tree-model while HTML::TokeParser::Simple uses a low-level pull model. The fact that XSLT has an encode_entities function instead of the longer HTML::Entities::encode_entities also makes the XSLT code look nicer.

    Using a tree-based module, XML::LibXML or XML::Twig for example, would lead to code that would look very similar to the XSLT one.

    As for the vaunted difference between what ("state the section you want") and how (select the section you want by navigating, or by using XPath)... frankly I don't see whatthe big deal is.

      Since you bring it up - I though that XSLT was normally handled by SAX which I didn't think would be normally fed into a tree structure. Or is XSLT going to always be stuck with the DOM problem of having to have everything in memory all at once to satisfy random access?

        XSLT does not mandate the implementation, but pratically XSLT processors build the whole tree in memory. In any case, if you want to be able to use arbitrary XPath expressions on a document, you pretty much need to have it all in memory.

        It would be theoretically possible to build really smart XSLT engines that would look at the code and do some clever optimization to only build parts of the tree, but I am not aware of any one that actually does this.

Re: Re: Why XSLT and not just Perl?
by zby (Vicar) on Jun 17, 2003 at 07:37 UTC
    It seems to me that the whole argument is more in favour of the XPath language than the whole XSLT. XPath for sure is usefull - it's a very ellegant way of addressing parts of an XML structure. But you can have XPath without XSLT (an example: Template::Plugin::XML::XPath).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://265989]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (9)
As of 2014-07-23 09:06 GMT
Find Nodes?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:

    Results (138 votes), past polls