in reply to Re: Why XSLT and not just Perl?
in thread Why XSLT and not just Perl?

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.

Replies are listed 'Best First'.
Re: Re: Re: Why XSLT and not just Perl?
by diotalevi (Canon) on Jun 16, 2003 at 18:07 UTC

    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.

        Directly as a DOM tree or something less prosaic like a collection of SAX events or an infoset?