On 03/12/2007, Florent Georges <lists@xxxxxxxxxxxx> wrote:
> Scott Trenda wrote:
>
>   Hi
>
> > That's a decent philosophy, but the real-world problem is
> > that you usually have large chunks of data within your
> > source document that you don't want in your output.
>
>   First I didn't say that was THE answer.  But that's a way
> of developing with XSLT that one doesn't have usualy when
> coming from imperative languages, and that helps to fight
> complexity.
>
>   Of course the point is not to not control what the
> stylesheet does, but to define what it does in places that
> ease maintainability.
>
> > If you apply-templates to all children indiscriminately
> > when you only actually want to process a certain subset of
> > child nodes, then you have a high probability that the
> > built-in templates will catch that unwanted data,
> > resulting in unwanted text everywhere in your result,
> > interspersed with the text you did want.
>
>   If the default template rules don't do what you want,
> don't use them.




On 03/12/2007, Florent Georges <lists@xxxxxxxxxxxx> wrote:
> Scott Trenda wrote:
>
>   Hi
>
> > That's a decent philosophy, but the real-world problem is
> > that you usually have large chunks of data within your
> > source document that you don't want in your output.
>
>   First I didn't say that was THE answer.  But that's a way
> of developing with XSLT that one doesn't have usualy when
> coming from imperative languages, and that helps to fight
> complexity.
>
>   Of course the point is not to not control what the
> stylesheet does, but to define what it does in places that
> ease maintainability.
>
> > If you apply-templates to all children indiscriminately
> > when you only actually want to process a certain subset of
> > child nodes, then you have a high probability that the
> > built-in templates will catch that unwanted data,
> > resulting in unwanted text everywhere in your result,
> > interspersed with the text you did want.
>
>   If the default template rules don't do what you want,
> don't use them.

If I've followed the thread I think you're discussing the choice of
filtering the nodes to be processed using a predicate:

<xsl:apply-templates select="some-nodes[some-filter]"/>

with:

<xsl:template match="some-nodes"> ....

or using a filter at the template match level with no-op templates:

<xsl:apply-templates/>
<xsl:template match="some-nodes"/>
<xsl:template match="some-nodes[some-filter]">....

?



> > Also, as I had said in the previous response, template
> > match patterns must be context-free. If you need to select
> > a node-set that requires a context, you're limited to
> > apply-templates.
>
>   I must confess I don't understand this paragraph.

I kind of understand what Scott means but I'm not sure I agree - in
the above example doesn't the template match pattern in the latter
method give you same level of context as the select in the former?

match="foo" has no context as it will match any <foo/>, but
match="/root/foo" will only match <foo> children of the single <root>
element - which I think is the context you mean.

As for the two techniques, the latter gives you more scope for
overriding, and suits the one-template-per-element design that some
people like (for each input element there will be  at least one
non-default template).  Also in an IDE you would see all the match
patterns together, which you don't get if the logic is in a predicate
in the select of an apply-templates somewhere.

I tend to use the former, but I can definitely see the merits of using
the latter.

cheers
andrew