Subject: Re: [xsl] stylesheet organisation From: "Mark" <mark@xxxxxxxxxxxx> Date: Sat, 3 Sep 2011 06:41:59 -0700 |
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.
Mark asked:
"Is there a significant difference between xsl:import and xsl:include worth learning?"
The only difference between xsl:import and xsl:include is that xsl:import must be the very first child of xsl:stylesheet.
<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.
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.
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.
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."
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.
<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.
-- 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] stylesheet organisation, G. Ken Holman | Thread | Re: [xsl] stylesheet organisation, Tony Graham |
Re: [xsl] stylesheet organisation, Jesper Tverskov | Date | Re: [xsl] stylesheet organisation, G. Ken Holman |
Month |