Andrew Welch wrote:
Something simple like:
<xsl:include href="library.sar"/>
where library.sar is "stylesheet archive", a standard zip with
some kind of meta pointing to the primary stylesheet.
I think this is the opposite of the approach where the URI is
used to identify WHAT (which module) instead of WHERE (where to
find the *.xsl file or the pre-compiled one.) Don't forget we
use uniform resource identifiers now, and not locators
anymore ;-)
If the library.sar contains the *.xsl modules and a little
descriptor telling which modules to expose (something like "the
module library.xsl in the ZIP file must be published at the URI
http://example.com/xsl/library.xsl, other modules are private",)
the processor within which it is "deployed" (or "installed," for
instance by copying the *.sar to a specific directory) can then
map:
<xsl:include href="http://example.com/xsl/library.xsl"/>
to:
<sar-repository>/library.sar!library.xsl
(or any other place it unziped or compiled the module to.) More
in the way catalogs operate, but everything packaged in a single
file (that's what users want, I guess.)
Regards,
--
Florent Georges
http://www.fgeorges.org/
--~------------------------------------------------------------------
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>
--~--