xml-dev - Re: Processing Select Patterns in XSL...

[James Clark <jjc@jclark.com>]

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">
>   <fo:block>
>     <xsl:process select="../../../heading"/>
>   </fo:block>
> </xsl:template>
> 
> >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
> tree.

Only if the element was selected for processing by an xsl:process or
xsl:process-children.

> 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

  select="foo|bar"

you can walk the children and process those which are of type foo or
bar.  If you have

  select="foo/bar|foo/baz"

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 have

 select=".//foo"

you could walk all descendant elements and process those that are of
type foo.

>  For
> 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.

Huh?

> 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
> processing. 

Not so.  Typically you would be using document level information in the
processing of some element.

James



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)