Re: Q: Relative paths in xsl:import Was: [xsl] Parameter in "xsl:include"

[Peter Flynn <peter@xxxxxxxxxxx>]

At 03 April 2001, you wrote:

>"Michael Kay" <mhkay@xxxxxxxxxxxx> writes:
>
>> Lots of people want to do this, and you can't. xsl:include is a
>> compile time thing: you can't build a stylesheet that varies
>> depending on its data, any more than you can build a Java program
>> that depends on its data.
>
>Sorry, some might find that comparison a bit confusing, because Java
>programs most definately can load classes by name while running. 

Not only that, but a programming language can write a file of code
in its own or another language, place a call to the OS which will 
compile it, save the binary, execute that, and have that write 
something else which is compiled into (say) a runtime library which 
won't be asked for resolution until later in the first program's 
execution...
It can even write to the end of its own binary and execute that, if
you know what you're doing (and sometimes if you don't :-)

>Is there any practical way to give a "relative" location in the
>xsl:import's href attribute? As far as I can understand, the current
>working directory during the compilation of the style sheet can not be
>known beforehand. Therefore, relative paths can not be used. 

I would have thought that this is precisely why relative paths *ought*
to be used. If I give "foo/bar" as a href value, I mean "foo as a 
subdirectory
of whatever directory you happen to be executing in". What actually
happens if you say xsl:import href="bar/foo.xsl"? 

I was appalled to find that XT returns a fully-qualfied absolute URL
for the unparsed-entity-uri function, so my entity declaration for
SYSTEM "foo.gif" comes back as file://u/usr/peter/foo/bar/blort/foo.gif
instead of just foo.gif, which plays merry hell with a subsequent 
process
reading the output of a text transform where it's expecting a filename!
(does Saxon do this?)

>However,
>if I need to compile the stylesheet on some arbitrary environment, I
>can not use absolute file locations.

<troll>PUBLIC identifiers and a catalog? :-)</troll>

>For now, all my imported style sheets have been hardcoded to reside on
>http://localhost/foo/bar/xslt/.
>
>XML entities, maybe?

Ipse dixit. That extra level of indirection can be very useful.

///Peter







 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list