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(_dot_)onwuka(_at_)googlemail(_dot_)com]
Sent: Wednesday, April 11, 2012 2:36 PM
To: xsl-list
Subject: [xsl] 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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--