>>  While I agree on the benefits, I do not think that's an effect
>> of being able to /compile/ libraries, but more generally of
>> having a standard /packaging/ format (kind of a JAR containing a
>> set of XSLT modules and a descriptor of them, for instance.)
>>
>
> Both have a great effect. Whenever a developer considers producing an
> XSLT application, which uses an XSLT library, often the blocking
> factor is the necessity to distribute to the customers not only the
> application itself, but also hundreds of files that are part of the
> XSLT library being used.
>
> I agree that even a mechanism to provide something like a zipped
> archive in a single file solves this problem and this would be
> sufficient if it were not less - performant than having the stylesheet
> modules already compiled.

Im not too sure compilation is a big deal, the user can always compile
the lot themselves.

Some kind of archive format would be really good - is anything in the
pipeline for 2.1?

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.


-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/

--~------------------------------------------------------------------
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@l...>
--~--