Re: [xsl] Referring to stylesheet itself, possible in XSLT 1.0, but how

Colin Adams wrote:
> I don't exactly understand your problem.
> Why can't you use a system-rewrite entry in an XML catalog?
I know of the existence of XML Catalogs, but I have no clue as to how to 
use/utilize them. But it may fit my needs, indeed.
Here's the full story of why I go through all this trouble of uris and 
uri resolution.
Our system contains several hundredths of stylesheets (user override 
templates). Anyone user or company usually only has a few of them and 
won't see the other stylesheets. All stylesheets are in some local 
directory. All common stylesheets, includes and sources are inside a 
global directory. That global directory structure is recreated each time 
a particular process is started.
I want all stylesheets to act as if they are inside this general 
directory. And that works, using xml:base. Perhaps I did not choose the 
right technique, but anyway, it works. This way, all user-defined 
stylesheets can simply refer to the paths relative to the general base. 
Which is what they should do.
There are some flaws in this system. I.e., when a use wants to create a 
stylesheet that is an include to another stylesheet. His only option is 
to use either an absolute path or a relative one, relative to the base dir.
For logging purposes, all stylesheets can use a set of generic functions 
during their process. One of which (should be) is outputting the 
currently used stylesheet. Something like the following:
// Stylesheet      : streamserve-tbl.xslt 
// Processor       : SAXON 8.7.3 from Saxonica 
// Processing date : 17 October 2006 
// Processing time : 17:37:02.640 

For illustration, here is the (simplified) structure of the files as it 
is currently (but it is likely to change, which is all the more a reason 
for having a general solution):
common
common/dtd
common/functions
common/unparsed

xslt-def-import
xslt-def-import/format-a
xslt-def-import/format-b
xslt-def-import/format-c
xslt-def-import/format-x/ext-y
xslt-def-import/format-x/ext-z
xslt-def-export/format-a
xslt-def-export/format-b/ext-x
xslt-def-export/format-c/ext-z
xslfo/format-a/pdf
xslfo/format-a/afp
xslfo/format-b/pdf
other/user-a/own-formats
other/user-b/own-formats

etc. Any xslt stylesheet in one of the other-than-common directories, 
receives an xml:base to the common location so as to 'think' as if it 
where there. That way, all logic is in one place, while retaining the 
possibility to keep specialized parts together as well.
As an added benefit, in each specialized directory, there's a playground 
area that mimics the input/output of the common location, giving 
developers a kind of sand box, without having to change anything once 
the xslt stylesheet is used in production.
It is strictly organized this way. And it works. Except for finding the 
xslt itself that is currently being executed.
Cheers,
-- Abel Braaksma

--~------------------------------------------------------------------
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>
--~--