Re: [xsl] stylesheet organisation

Subject: Re: [xsl] stylesheet organisation
From: "Mark" <mark@xxxxxxxxxxxx>
Date: Sat, 3 Sep 2011 06:41:59 -0700
Thanks all for delving into this topic so carefully. I am glad I asked my question.
Mark


-----Original Message----- From: G. Ken Holman
Sent: Saturday, September 03, 2011 5:27 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] stylesheet organisation


I wanted to add to Geert's excellent response with direct comments to
Jesper's items as these misconceptions come up in class from students
who have read the specification.

At 2011-09-03 10:17 +0200, Jesper Tverskov wrote:
Mark asked:

"Is there a significant difference between xsl:import and xsl:include
worth learning?"

Absolutely there is.


The only difference between xsl:import and xsl:include is that
xsl:import must be the very first child of xsl:stylesheet.

False.


<xsl:import> brings in top-level constructs at a lower "level" of
matching that in the classroom I call "importance" (this term is not
used in the spec; "precedence" is used in the specification, and I
mention this in the classroom, but students get confused between
precedence and priority so I use "importance" in the lecture) to
illustrate the difference.  The importing stylesheet is considered
more important than the imported stylesheet.

<xsl:include> brings in top-level constructs at the same importance
(precedence) level.

XSLT's built-in template rules are all less important than the least
important user stylesheet fragment.

When a node is pushed at the stylesheet, the importance of each level
is checked first and the priorities at that level of importance are
checked without regard for the priorities found at lower levels of
importance.  Even if template rules at the lower level of importance
have higher levels of priority, this is irrelevant.

Modes are not irrelevant as these are checked first before priority
is checked. Higher-importance template rules in a mode match before
lower-importance template rules in the same mode. Once all of the
in-play template rules are determined by mode, then importance trumps priority.


This means that if the importing stylesheet has templates that matches
with same priority as the templates in the imported stylesheet, the
templates in the importing stylesheet are sure to win out because they
are after the templates in the imported stylesheet.

False.


They are sure to win out because importance trumps priority.  Only
top-level constructs at a given level of importance are competing
through the means of priority.  If a template is not matched at a
given level of importance, it is matched at the next lower level of
importance.  Once all of the user levels of importance are checked,
the built-in template rule least level of importance will catch anything.

That is you never really need to use xsl:import. If you make sure that
an xsl:include is the very first child of xsl:stylesheet, it works
exactly as if xsl:import had been used.

False.


You need <xsl:import> in your strategy to have some template rules
match at the priorities found in a higher level of importance than
those priorities at existing and lower levels of importance.

This is often used for "tweaking" an existing stylesheet (perhaps
because it is read-only in your source code control system) with an
onion-skin layer around it where the onion-skin template rules are
all more important than the existing stylesheet.  Thus they are
in-play with their own template rules and their own priorities,
trumping the priorities of template rules in the existing stylesheet.

For example, I've used this to create an "editor's rendition"
stylesheet that exploits the "user's rendition" stylesheet:  the
editor's rendition exposes authored information they need to see that
end users don't need to see (names of graphic images,
applicabilities, dates, metadata, author information, etc.).  Amongst
all of this additional information for the editor, the editor can see
the user-visible content.

Two constructs are available in XSLT 2 to re-engage the rest of the
stylesheet constructs without regard for the last-matched template
rule:  <xsl:apply-imports> reapplies the last-matched node using only
the imported stylesheet fragments without regard for the importing
stylesheet fragment.  <xsl:next-match> reapplies the last-matched
node using all of the stylesheet fragments without regard for the
template rule that triggered the last match.

It is not true that "in general the rules and definitions in an
including stylesheet have the same precedence as the ones in the
included stylesheet."

False


It is absolutely true that top-level constructs in the including
stylesheet are at the same level of precedence (importance) than the
included stylesheets.

Using xsl:include simply means that you don't know about precedence
without having to take a look in the merged stylesheets in order to
find out what comes last. That is not necessary when you use
xsl:import because the imported templates must come first.

False.


<xsl:include> order is unambiguously dictated by its position amongst
other top-level constructs.  Only in ambiguous-template-rule-conflict
fallback behaviour will this order be significant.

<xsl:import> order is unambiguously dictated by a different set of
semantics that introduces a higher-level of precedence (importance)
for the importing constructs over the imported constructs.

Please see Geert's response for explicit examples.

I hope this helps.

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

--
Contact us for world-wide XML consulting & instructor-led training
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Current Thread