Re: [xsl] The identity transform and attributes

Subject: Re: [xsl] The identity transform and attributes
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Mon, 21 Jan 2008 15:16:43 -0500

At 02:33 PM 1/21/2008, Andrew wrote:
On 21/01/2008, David Carlisle <davidc@xxxxxxxxx> wrote:
> select="child::foo selects the parent of the current node,
>  match="child::foo" asks if that node is the child of anything.
> So unless you find it surprising that something can both have a parent
> and be a parent, I'm not sure what is surprising here?

Well when you put it like that... :)

The bit I found non-intuitive (note the past tense now...) was that a
match pattern can be only attribute:: or child::  something that
doesn't get talked about much.

Well, or it can be one of a couple of functions such as "id('x')", or it can be something like "forebear//progeny".

Which seem to complicate things a bit, without really doing so, due to the rationale David is explaining.

For example:

apply-templates select="parent::foo"


template match="foo"

That looks fine - I'm happy with that.  "foo" on its own looks right.
But when you realise that the match pattern is actually:

template match="child::foo" gets a bit harder to understand why it's like that.

... at least as long as you assume there to be some sort of "stateful" relation between an expression used to select nodes, and the criteria used to match nodes to templates (that is, the rules for pattern matching, precedence and priority).

Such an assumption may be natural enough in other processing paradigms, but as David has explained, in XSLT it's simply wrong.

And indeed, XSLT gets much of its famous flexibility and power from this unlinking.

To (seem to) change the topic, I recently learned that in Docbook, bibliomixed/link is invalid according to the schema, but it works just fine in the distributed stylesheets. Nor is this sort of thing uncommon in XML/XSLT.

Why the discrepancy? Since, given the unlinking between selecting and matching, it's easier to write and maintain a stylesheet that "does the right thing" for a construct that is formally invalid, than it is to write a stylesheet that refuses. (In this case, an extra template would be required just to trap the invalid case.)

This is because a robust stylesheet, in most cases, is actually easier and simpler to write than a brittle one. Underlying this fact is the simplicity of the match/select relationship and how much it does *not* assume about processing context.

  If you say
it as "foo that is a child of some node" then it makes slightly easier
to comprehend.  And then when you think about it, all elements are
children of either another element, or the root node (correct?) it
makes sense that child:: is the default.

I think.

Well, child:: isn't actually the default; rather, "child::foo" is the expanded form of "foo", which is a very normal (the most normal) sort of pattern to write, by design.

What's especially interesting to me is how the rule for matching ("given node N and pattern P, does there exist in the tree some node X, from which, as context, node N would be selected using pattern P as a select expression?") is so intuitively workable that even experts can rely on it without being able to explain it. Notice that the rule says nothing about any expression ever actually used to select node N.

I *think* that's a successful design. :-)


====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================

Current Thread