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

Re: [xsl] Unravelling Imports

Subject: Re: [xsl] Unravelling Imports
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 11 Apr 2012 15:57:16 -0400

At 2012-04-11 20:36 +0100, ihe onwuka wrote:
There is a supposed requirement that we deliver monolithic XSLT with
includes unravelled (there are no imports).

I don't need to be convinced it's a bad and misguided idea but I won't
close off anyone who wants to comment as they may think of stuff that I

The purpose of my post though is this.

Suppose we did go ahead and code with imports, would it be possible to
define a transform that mechanically transformed everything into monolithic

I'm thinking it would involve alot of use of priorities at the very least.

For "includes" it isn't a problem ... simply stream the included fragments in-situ. I cannot think of any changes to the coding.

But for "imports" I think it would be a challenge to do quickly or even at all completely. Any <xsl:apply-imports> that you have could not easily be changed into <xsl:next-match> because you cannot keep the other matches in the original fragment from being engaged. And that is only if you are working with XSLT 2.0.

Then there is the mixing of user-specified priorities with your own imposed priorities that mimic importation precedence. If a user used arbitrarily large priority values, how would you ensure your imposed values would always exceed those?

You would have to aggregate like-named attribute sets in such a way as to eliminate lower-priority like-named attributes.

You would have to cull like-named template rules of lower priority than the highest of each.

Because precedence trumps priority it might be a good first step just to assign higher priorities of the same value to templates higher in import precedence ... adding in any user-specified priorities to the number selected for that fragment.

It would likely work for the simplest uses of XSLT. But if you are using <xsl:import> then it must be for a good reason of overriding constructs, which then makes it a challenge.

I think it would take a lot more thinking than provided for in a volunteer mail list response.

But I hope the above helps somewhat.

. . . . . . . . . Ken

Public XSLT, XSL-FO, UBL and code list classes in Europe -- May 2012
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