Good info, makes sense.
 
Just to clarify, I'm writing a servlet that has a UI allowing you to select a source xml file (located in the same directory as the servlet) from a dropdown list of several different source xml files, and a button to execute the transform against fixed xsl files. Multiple html files are generated from a single xml source file. The resultant html files are placed in a subdirectory accessible to the end user.
 
I'm not that particular about where the resultant html files are placed. They are simply placed in a subdirectory relative to the source xml file. Users may have access to the resultant subdirectory and files. An entire directory tree containing several different html files is generated from a single source xml.
 
In my case the file structure looks like:
 
<root>/mywebdir/mysource.xml
<root>/mywebdir/mytransform.xsl
 
The resultant files are placed in an mtest subdirectory like:
 
<root>/mywebdir/mtest/index.htm
<root>/mywebdir/mtest/file1.htm
<root>/mywebdir/mtest/file2.htm
...
 
You comment: "If you're running on a hosted machine then you'll have to write the files to
a directory where the servlet has write permission" seems to be the key for me. This is what I'm not familiar with. Thanks for your suggestion how to go about it, I think you've answered my question.
 
Corby Morris
 
----- Original Message -----
From: Michael Kay
To: saxon-help@lists.sourceforge.net
Sent: Saturday, July 10, 2004 4:20 AM
Subject: RE: [saxon] Beginner: Must use full path in xsl:result-document?

>
> It appears that I must use a full path when using the
> xsl:result-document
> command from a saxon servlet.
>
> For example: <xsl:result-document href="file:/c:/mywebdir/myfile.htm"
> format="web">
>
> rather than: <xsl:result-document href="file:/../../myfile.htm"
> format="web">
>
> Is this true, or is it possible to use a relative path?

Although it's possible in principle to use a relative path, this isn't
likely to be convenient in a servlet environment. Any relative URI is
resolved relative to the base URI of the principal output document, which in
the servlet case is going to the servlet output streat, which doesn't have a
meaningful URI. You could, when you allocate the principal output
destination, give it an arbitrary URI for this purpose:

ServletOutputStream out = res.getOutputStream();
StreamResult tout = new StreamResult(out);
tout.setSystemId("file:/c:/some/uri/");
transformer.transform(new StreamSource(sourceFile), tout);

However, I'm wondering what you're actually trying to do here. Where do you
want to put the extra output files? Is it a location associated with the
individual end user, or a location associated with the source document, or
what? Are you trying to split the source document into multiple result
documents the first time it is accessed, and cache the results for later
use? Do you actually want to serialize the multiple output documents to
disk, or do you really want them in (application or session) memory?

> Also, there is no
> 'c:' on Unix\Linux, so would I use something like
> 'href=file://mywebdir/myfile.html' ??

I think the correct syntax is file:///usr/dir/file.xml to reference the UNIX
file /user/dir/file.xml
>
> I'm new to the Servlet environment.. I'm not sure how to
> obtain the full
> path if I'm running my Servlet on a hosted machine. Do I have
> to ask the
> host provider and hard code the path or is there a dynamic
> way to do this?
>

If you're running on a hosted machine then you'll have to write the files to
a directory where the servlet has write permission. A Java call such as

getServletContext().getRealPath(source);

will give you path names to files within the directory structure visible to
users via a browser - it's not clear whether you want the XML files you
generate to be directly accessible to users or not.

Michael Kay



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
saxon-help mailing list
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help