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
just:
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:
http://www.w3.org/TR/1999/REC-xslt-19991116#apply-imports
...
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:
http://www.w3.org/TR/1999/REC-xslt-19991116#built-in-rule
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(_at_)CraneSoftwrights(_dot_)com
|
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers: http://www.CraneSoftwrights.com/legal |
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--