Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • You’re defining two identity copies, one on the root element and one for everything else; why? Next, you write a template for //* which is equivalent to matching * (but I haven’t slept and it’s 6AM, so I might be making a mistake). And finally, you say making the D nodes sort together with all the others would be a lot of work, when actually it’s less work than you’re already doing. Overall:


    • Thanks. Tested and it works. I bow to your superior XSLT-fu (mine needs a lot of work). My only consolation is that I've seen worse code than mine from someone else who was trying to do the same sort of thing (and who wasn't even yet trying to sort by name()). I still find XSLT non-intuitive, e.g., how does it decide which templates to match, does it matter what in what order the templates come, and so why doesn't the first (identity) template above just match and copy everything unchanged?
      • Don’t worry, you’re in good company. Almost no one groks XSLT properly. (This is probably because every single XSLT tutorial is terrible junk.) Most of the transforms I see are seriously suboptimal, and a very large fraction of them are really atrocious. There’s a lot of cargo cult and programming by coincide in the XSLT world. Your attempt was quite decent by those standards. :-)

        Actually, the way XSLT processing happens is very simple, but because of the implicit default templates, it seems very magical.

        First off: XSLT checks all templates for whether they match the current node. It then looks at the XPath expressions of the templates and calculates a priority from each of them based on a simple set of rules (but you can specify the priority of a particular template directly). Then it picks the template with the highest priority. If there are several matching templates with the same priority, this is an error.

        Secondly: the order in which nodes are processed is dependent purely on the order in which they get selected for processing by xsl:apply-templates. There is nothing magical about it; if there is no xsl:apply-templates instruction that picks up a particular node, then it won’t even be looked at.

        Now: these issues are clouded by the are built-in templates that are implicitly part of every transform. They look like this:

        <xsl:template match="*|/">

        <xsl:template match="text()|@*">
          <xsl:value-of select="."/>

        <xsl:template match="processing-instruction()|comment()"/>

        In other words, by default:

        1. Due to the first one of those templates, the root node and all elements will produce no output, but visiting one will guarantee that that processor will visit all its child nodes as well.

        2. When a text or attribute node is visited, it’s value is output due to the second template.

        3. The last template shown specifies that comments and processing instructions are simply thrown away.

        When the processor loads a document, it makes the root node the current node and tries to match a template to it. Unless you’ve explicitly written an template to match it yourself, the first built-in template shown up there is what matches, so xsl:apply-templates is called, which selects the document element of the document and tries to match a template to it in turn. This gets the ball rolling. The processing then proceeds in order of the xsl:apply-templates instructions encountered and the nodes they select, matching templates to those nodes and executing the instructions given in them. Whenever it encounters an xsl:apply-templates, it recurses.

        That’s it. That’s all.

        It’s really very simple and completely non-magical. I remember how much it mystified me when I first started, because no one, and I mean no one, explains these few simple facts in simple terms.

        Once you understand that, it’s all just XPath-fu, which is set based, so making effective use of it (like what I did to consolidate your two different sorts) is somewhat reminiscent of the skill it takes to write effective SQL queries (though not exactly the same).

        I suggest using the XSLT spec [] as a reference; it’s more than sufficiently readable from a language user’s (as opposed to implementer’s) perspective for that purpose. (As is the XPath spec [].)

        • Ugh, even a multitude of previewings did not protect me from submitting the comment with a whole bunch of small grammatical and spelling mistakes. “It’s value?” Argh. My face is melting off. I’m not stupid – I swear!