Re: [xsl] stylesheet organisation

Subject: Re: [xsl] stylesheet organisation
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 03 Sep 2011 09:54:19 -0400
In my haste I described my two examples in the text backwards: in fact B.xsl includes A.xsl and C.xsl imports A.xsl. The template rule in B.xsl is overridden by match priority by the template rule in A.xsl. The template rule in C.xsl overrides by import precedence the template rule in A.xsl.

The stylesheet fragments are still correct illustrating the difference between import and include, I just wrote the description of the example incorrectly.

Please forgive my oversight due to my haste.

. . . . . . . . Ken

At 2011-09-03 09:45 -0400, I wrote:
At 2011-09-03 15:31 +0200, Jesper Tverskov wrote:
I'm sorry that I dropped "as far as I know" from my posting right
before I hit the Send button, but I some times take chances in order
to stir up things that makes it possible for all of us to learn
something.

I still feel that the spec pretty much says what I'm saying,
http://www.w3.org/TR/xslt20/#import, and that most of the differences
are due to the simple fact the xsl.import must be the first child.

I disagree, and I think it is misleading for readers of the archive to be told this repeatedly in your posts.


Why
is it important that it is the first child (there could be other
reasons)? I am wondering if that is also how xsl:include and
xsl:import are some times implemented in XSLT processors?

Then they would not be conformant.


I'm
wondering if some of the finer details, some of you mention, are
actually questions of implementation?

False. The specification is clear that <xsl:import> introduces a level of precedence that trumps priority. In the classroom I call this "importance" as it helps the students better understand what is going on. Built-in template rules have lesser importance than all of the user's stylesheet fragments.


My rule of thumb analysis has worked well for me in all trivial use
cases, and if things are not trivial or if I have doubts I always test
things. As a generalization, easy to remember, I have until now not
been able to get anything closer than what I have already said.

Basing the understanding of powerful features on trivial use cases is an unacceptable way to learn the wealth of functionality available to solve real world problems.


Certainly it is acceptable to test powerful concepts with trivial examples, but that is different than trivial use cases.

Consider this trivial example that illustrates the difference between <xsl:import> and <xsl:include> that refutes your trivial analysis: fragment A is imported by fragment B and included by fragment C and stylesheets B and C produce different results. If readers of the archive believed your assertion that they <xsl:include> and <xsl:import> are trivially the same except for the position in the stylesheet, then B and C would produce identical results.

t:\ftemp>type A.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
  version="1.0">

<xsl:template match="/" priority="1000">
  Stylesheet A
</xsl:template>

</xsl:stylesheet>
t:\ftemp>
t:\ftemp>type B.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
  version="1.0">

<xsl:include href="A.xsl"/>

<xsl:template match="/" priority="1">
  Stylesheet B
</xsl:template>

</xsl:stylesheet>
t:\ftemp>
t:\ftemp>type C.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
  version="1.0">

<xsl:import href="A.xsl"/>

<xsl:template match="/" priority="1">
  Stylesheet C
</xsl:template>

</xsl:stylesheet>
t:\ftemp>
t:\ftemp>xslt A.xsl B.xsl con
<?xml version="1.0" encoding="utf-8"?>
  Stylesheet A

t:\ftemp>xslt A.xsl C.xsl con
<?xml version="1.0" encoding="utf-8"?>
  Stylesheet C

t:\ftemp>

You can see that B.xsl and C.xsl produce different results using the same input.

Your assertion that <xsl:import> is simply an enforced location for <xsl:include> is patently false and misleading to readers of the archive.

But maybe some of us can come up with some solid test cases that work
across implementations to see if it is possible to make an even better
rule of thumb analysis, still easy to remember as a first shot that
works in most cases except in situations where we need testing anyway.

Specifications don't work that way. They don't work only for the trivial cases. If you only think of the trivial, you lose sight of the powerful.


If the above example test case produces different results for a particular processor, then that processor is not conforming to the specification.

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