Lists Home |
Date Index |
- From: James Clark <firstname.lastname@example.org>
- To: email@example.com
- Date: Thu, 17 Sep 1998 13:02:30 +0700
Tyler Baker wrote:
> One thing that is slightly confusing with select patterns is selecting
> elements containing parent anchors.
> For example, say I have:
> <xsl:template match="book">
> <xsl:process select="../../../heading"/>
> >From what I understand, this would say first go to the third parent node
> of the current node
ie the grandparent's parent.
> and select all heading elements and process them.
ie all heading children of the grandparent's parent
> This would seem to be an error since another template may already have
> processed these heading elements.
It would only be an error if they had already been processed (because
that would get you in a loop).
> Match patterns seem to be pretty straightforward in how you use them as
> all you need to really do is start at the right-most pattern component
> and work left. If everything matches up then finally make sure that the
> anchor matches up with the parent of the node that matched the left most
> pattern. If everything still holds, then apply the template rule to
> this particular element in the source tree when spitting out the result
Only if the element was selected for processing by an xsl:process or
> Now select patterns it seems from first glance that you would instead
> start from the current node and work left to right instead of right to
> left as in the case of match patterns. Essentially, you would start
> from the current node and recursively process all of the descendants
> that end up matching the ancestry pattern from left to right.
A variety of strategies are possible. For example, if you have
you can walk the children and process those which are of type foo or
bar. If you have
you can walk the children and then for each child that's of type foo
walk its children and process those which are of type bar or baz. If
you could walk all descendant elements and process those that are of
> ancestry patterns that do not contain an immediate ancestor operator
> this process would be rather cheap.
> But in the above example, what do you do when relative or absolute
> anchors withing select patterns anchor a node which is an ancestor of
> the current node in context. In this case, it seems as if you can have
> multiple template rules acting on the same elements.
> Another question is what to do with Absolute Anchors. I would think
> that for select patterns it would not make sense for this to be allowed
> as the entire template match then has nothing to do with the actual
Not so. Typically you would be using document level information in the
processing of some element.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)