Re: Unravelling Imports

Yeah, if the client wants a monolithic file, combine your stylesheets
by hand and just work with a single stylesheet from then on.

Combining it programmatically is likely to be far more effort than its worth.

(or of course, find out the reason why the client wants a single file,
and then convince them otherwise if it's not a valid reason...)

On 12 April 2012 10:38, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> I think Scott has identified the two restrictions that will be very hard to
> get around: (a) apply-imports, and (b) dependencies on the base URI of
> stylesheet modules (for example, use of document('')). But it's probably
> true that 95% of stylesheets are unaffected by those restrictions.
>
> Combining system-allocated precedence values with user-allocated priorities
> is possible, but it requires parsing of match patterns to determine the
> default priority if no user-defined priority has been set. Dealing with
> union patterns is particularly tricky.
>
> For named templates, global variables, etc, it's a question of recognizing
> the duplicates and dropping all but the last.
>
> There's a lot of messy detail for edge stuff such as xsl:output and
> xsl:decimal-format: it's a classic case where you can get a 90% solution
for
> 10% of the effort of a 99% solution.
>
> Michael Kay
> Saxonica
>
>
> On 11/04/2012 20:55, Scott Trenda wrote:
>>
>> Ihe,
>>
>> As much as it sounds like a bad idea on the surface, I can understand
>> where you could be coming from. For example, if you have an intricate
>> client-side XSLT architecture with highly modularized stylesheets, then
the
>> overhead cost of HTTP requests to download/cache-verify the individual
>> stylesheets could start to add up to a non-negligible overhead, especially
>> on a bad/slow connection.
>>
>> I thought I was in a similar situation a few years ago, and at the time, I
>> actually mapped out what the transformation would look like and how it
would
>> work. I never got around to implementing it due to the potential risks,
but
>> if you have a very compelling reason for it, I do know it's possible, at
>> least with XSLT 1.0. It involves a lot of mapping out the exact
priorities,
>> applying and copying, sorted by the computed priorities
(for<xsl:import>s),
>> and copying only the topmost elements in the priority list to avoid
>> duplicate definitions. If you're only using<xsl:include>s, it should be
>> easier, because your XSLT processor would throw stylesheet errors if there
>> were any duplicate definitions, due to the single-level nature of
includes.
>>
>> There are some specific functionalities that may not be available in a
>> monolithic model (<xsl:apply-imports/>, for one), and others for which I'm
>> honestly not certain of the behavior of XSLT 1.0 processors (e.g. the
scope
>> of document('') in an imported or included stylesheet). But I do know it's
>> possible and feasible within a limited scope.
>>
>> ~ Scott
>>
>>
>> -----Original Message-----
>> From: ihe onwuka [mailto:ihe.onwuka@xxxxxxxxxxxxxx]
>> Sent: Wednesday, April 11, 2012 2:36 PM
>> To: xsl-list
>> Subject:  Unravelling Imports
>>
>> 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
>> haven't.
>>
>> 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
>> XML.
>>
>> I'm thinking it would involve alot of use of priorities at the very least.
>>
>> Ihe
>



--
Andrew Welch
http://andrewjwelch.com