If you're generating the main XSLT document, why not give it an xml:base
attribute on the xsl:stylesheet element pointing to the current
directory? Alternatively, why not generate absolute URIs for its
xsl:include and xsl:import directives?
On 16/05/2011 07:41, Ed Avis wrote:
> Thanks for your answer. If I understand rightly, the XSLT file is
> specified as a URI
> not a filename, even when mentioned on the command line. Because it's a
> URI, to conform
> with the spec, relative URIs such as those in my xsl:include directives
> must be resolved
> relative to that base.
> My use case is that I want to run the command line from a script. I
> would like to
> programmatically generate both the input XML and the XSLT, although the
> XSLT may contain
> include directives. (In fact, it's intended as a test suite which gets
> different versions
> of the XSLT from the version control system and checks the result.)
> For the input XML there is no problem - it can be passed on standard
> input. For the XSLT
> I had hoped to write a file in /tmp and use that as input - but doing so
> changes the path
> used for relative URI lookups. I would prefer not to write a file in
> the current directory,
> since it may not be writable.
> My next question is whether it's possible to pass the XSLT on the
> command line so it can be
> piped in. It appears that the '-' syntax for standard input, while
> recognized for the XML
> argument, doesn't work as an -xsl:- option.
> Or, ultimately, to divorce the 'URI' of the XSLT file, which affects the
> semantics used to
> process it, from the filename that the command line tool should read
> from to get the contents
> of that URI. For command line use this would be handy.