Saxon

Legacy ID: #7523858 Legacy Poster: Michael Kay (mhkay)

I would think it's almost certain that the files are being written, but not where you expect them. You haven't shown enough of your code for me to be sure what the Base Output URI is. This is the base URI used for resolving a relative URI in the href attribute of xsl:result-document. If you set FeatureKeys.TIMING to true on the Configuration, Saxon will log the full filenames that it writes to System.err. Alternatively, supply an OutputURIResolver, which is called by xsl:result-document and can be used to monitor or to set the way the file is written.

Legacy ID: #7524232 Legacy Poster: W. Eliot Kimber (drmacro)

Thanks--I'll try those debug approaches. Cheers, Eliot

Legacy ID: #7524850 Legacy Poster: W. Eliot Kimber (drmacro)

I turned on the TIMING flag and saw, not surprisingly, that the missing files are being output relative to the JVM dir, rather than relative to the specified destination file, e.g.: Writing to file:/Applications/eclipse/Eclipse.app/Contents/MacOS/topics/topic_d8e705.dita So my question: what should I be doing, either in setting up the transformer object, or in my XSLT, to set the correct base URI for result-document? Thanks, Eliot

Legacy ID: #7525350 Legacy Poster: Michael Kay (mhkay)

I'm slightly suprised to discover that XsltTransformer doesn't have a setBaseOutputURI() method. In its absence, you can dive into the Controller: trans.getUnderlyingController().setBaseOutputURI(). However, if the Destination that you supply to the XsltTransformer has a URI or system ID associated with it, this should be used automatically as the base output URI. I don't think you've show the part of your code that sets the destination.

Legacy ID: #7525945 Legacy Poster: W. Eliot Kimber (drmacro)

Ok, here's how I'm setting up and running the transform (error checking omitted for clarity): XsltCompiler compiler = getSaxonXsltCompiler(context, messageListener); XsltTransformer trans = null; XsltExecutable xsltExe = null; XsltExe = compiler.compile(style); trans = xsltExe.load(); Serializer result = new Serializer(); result.setOutputFile(resultFile); trans.setDestination(result); trans.transform(); So I am definitely setting the output file on the Destination, which I would expect to set the output base URI. Thanks, Eliot

Legacy ID: #7553810 Legacy Poster: W. Eliot Kimber (drmacro)

Pinging on this issue. I've been on vacation but I'm back now and resolving this is a high priority for me. I'm sure I can find a workaround but what I'd like to know is what the Saxon code should be doing. Given that knowledge, I can try to dig into the Saxon code more deeply to find any bugs, if the current behavior is in fact not correct per the original intent. But certainly my naive expectation is that setting an output destination that has a file would have the effect of setting the base output URI for xs:result-document and that doesn't appear to be happening. But I'm not 100% sure I'm using the API correctly. Thanks, Eliot

Legacy ID: #7553982 Legacy Poster: W. Eliot Kimber (drmacro)

I traced through the code and I think I have discovered the nature of the bug, although I'm not sure what the right code fix would be. The problem is that the UncommittedResult created from the StreamResult I pass in is not using the systemId of the passed-in Result to set its own systemId value. Thus when the Controller goes to set the principalResultURI value, it gets null. If I manually set the principalResultURI value to match the systemId of the wrapped Result in the debugger, then I get the result I expected (the output files are generated relative to that URI). I think that must be a bug. I was already working around this bug (although I didn't realize it) by passing in the output directory as a parameter--I just wasn't using it in this case because I wasn't thinking clearly at the time. Cheers, Eliot

Legacy ID: #7574839 Legacy Poster: W. Eliot Kimber (drmacro)

Should I log this as a bug in the bug tracker? Cheers, Eliot