Re: [xsl] The identity transform and attributes

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

Hi,

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"
>
> and
>
> 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"
>
> ...it 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. :-)

Cheers,
Wendell


======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
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
======================================================================