[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] xsl:apply-imports behavior wrong in Saxon?

Subject: Re: [xsl] xsl:apply-imports behavior wrong in Saxon?
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 04 Apr 2013 13:11:17 -0400

At 2013-04-04 09:10 -0700, Bob Stayton wrote:
I have uncovered a significant difference in the way xsltproc and Saxon (both 6 and 9)
handle xsl:apply-imports when using a template mode. It seem that Saxon
is doing the wrong thing here, but I wanted to ask if others interpret it
this way. I cannot find anything in the archive on this subject.

I go to the specification and I can see the Saxon behaviour in the words of the specification, but not in the words you quote from Michael.

I'm processing this simple document book.xml:
with this stylesheet (modetest.xsl):
And the imported no-mode.xsl stylesheet is:
When I apply modetest.xsl to book.xml using xsltproc, the message output is

Reached apply-imports in modetest.xsl

When I apply modetest.xsl to book.xml using Saxon, the output is:

Reached apply-imports in modetest.xsl
reached fallback in modetest.xsl for element title
reached fallback in modetest.xsl for element para

Yes, those are the results I get with Saxon (I don't have xsltproc installed).

According to Saxon author Michael Kay's website, his description of
xsl:apply-imports is:

"The effect is to search for a template that matches the current node and
that is defined in a stylesheet that was imported (directly or indirectly,
possibly via xsl:include) from the stylesheet containing the current
template, and whose mode matches the current mode. If there is such a
template, it is activated using the current node. If not, the call on
xsl:apply-imports has no effect."

That last bits are what I don't agree with. And it isn't what I teach in the classroom. And the Saxon execution results above mesh with what I teach in the classroom.

There is no template matching on book in mode="inside_mode" in the imported
stylesheet, so the call on xsl:apply-imports should have no effect.

I disagree.

Why is Saxon applying
templates in mode="inside_mode" to the children of book?

This is my read of the specification and what is happening in the above results:

   xsl:apply-imports processes the current node using only
   template rules that were imported into the stylesheet
   element containing the current template rule; the node is
   processed in the current template rule's mode.

In the classroom I paraphrase the above as:

   xsl:apply-imports reapplies the last-matched node in the
   last-matched mode using only the imported stylesheets
   (and it can't be used inside of a for-each).

So, consider that you are reapplying <book> in "inside_mode" using only the no-mode.xsl template rules (per the specification). Well, I understand that the specification says that when there is no template rule that matches the node being matched, the built-in template rules are triggered (which is contrary to the "has no effect" bit in Michael's description). So, in your case, the <book> in "inside_mode" has no match in the imported stylesheet and so is being matched by the built-in template rule, which pushes the child nodes of <book> in the same mode. These children are fresh game ... the <book> node has done its business with the imported stylesheets. Those children are pushed in back at the top of the stylesheet import tree and are being matched by your fallback template.

And so Saxon is producing the results that you see.

So, it looks like xsltproc is doing the "has no effect" bit, and Saxon is letting the built-in template rules handle the node that is not matched by the set of template rules in the imported stylesheets.

Reading the specification, I don't see anything in section 5.8 that says the built-in template rule processing is not engaged:

  There is a built-in template rule to allow recursive processing
  to continue in the absence of a successful pattern match by an
  explicit template rule in the stylesheet.
  There is also a built-in template rule for each mode, which
  allows recursive processing to continue in the same mode in the
  absence of a successful pattern match by an explicit template
  rule in the stylesheet.

I don't see anything in section 5.8 that says the built-in rules are not in play when <xsl:apply-imports> is using as the user's stylesheet only the template rules of the imported stylesheets. The imported stylesheet has its own imported stylesheets and reliance on the built-in template rules.

And I don't see why recursive behaviour would be short-circuited by <xsl:apply-imports/>. I certainly have plenty of cases where what I'm importing is, itself, the apex of a tree of stylesheet fragments and I would want *all* of those stylesheet fragments (and the implicit fragment of the built-in template rules) in play and not just the template rules of the apex stylesheet I've imported.

So I think the Saxon behaviour is consistent with the specification and the xsltproc behaviour and the last two sentences of Michael's description are not correct.

I am open to being convinced otherwise, but I think it would be difficult. I need "full stylesheet behaviours" when I use <xsl:apply-imports/> and not just the one "level" of imported stylesheets. Which is what I'm getting with Saxon.

Oh ... consider this ... I have a working stylesheet with imported fragments or whatever. All the fragments are read-only. Say they are the DocBook stylesheets. If I want to change the behaviour of one construct, I can import the DocBook apex stylesheet into a stylesheet that matches on the construct, does what it needs to, and then uses <xsl:apply-imports/> to recreate the original DocBook behaviours. I certainly would not want *only* the template rules of the top-level apex stylesheet of DocBook to be engaged ignoring the imported stylesheets and built-in template rule behaviours.

I hope this helps.

. . . . . . . . . . . . Ken

Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

Current Thread