I'm writing a processor based on the Java implementation of Xalan,
drawing on the examples provided at XML-Apache. I'm currently developing
on Macintosh (which may or may not be significant).

The aim is to take an XML file that contains an embedded stylesheet
specification, i.e.

   <?xml-stylesheet type="text/xsl" href="articlenotes.xsl" ?>

and transform the XML document using that stylesheet. Drawing on code
from the UseStylesheetPI example (which, incidentally, works fine), I
have:

   TransformerFactory tFactory = TransformerFactory.newInstance();
   Source stylesheet = tFactory.getAssociatedStylesheet(new
         StreamSource(sourcepath), media, title, charset);
   Transformer transformer = tFactory.newTransformer(stylesheet);

The 'sourcepath' is a string consisting of the full pathname to the XML
file, i.e.

    /Code/WWW/XTest/sources/test.xml

The problem is that getAssociatedStylesheet apparently returns a Source
object that refers to a bogus 'file://' URL, which causes
'newTransformer' to error out. The URL it generates consists of:

   "file:///" + full path to Java app + full path to stylesheet

So with my Java application sitting in

   /Code/Java/Applications/Processor/

and the stylesheet residing at:

   /Code/WWW/XTest/sources/articlenotes.xsl

I get a URL of:

   <file:////Code/Java/Applications/Processor//Code/WWW/XTest/
    sources/articlenotes.xsl>

rather than the:

   <file:///Code/WWW/XTest/sources/articlenotes.xsl>

that I expect. It looks as if the URL is always computed relative to the
location of the application (rather than relative to '/'), resulting in
unusable URLs and "file not found" errors as soon 'newTransformer' tries
to read from the URL.

Why is 'getAssociatedStylesheet' creating a Source object with a bogus
URL of this type? Is this a bug, or am I being bone-headed? And in either case, is there anything I can do to work around this?


Thanks in advance,

   Angus
--
[EMAIL PROTECTED]                             http://pobox.com/~angus

Reply via email to