Sam, Karen, et al --
I believe that I've found the source of this problem but, unfortunately,
I don't have the time to check it out thoroughly since I'm not set up to
do builds of FOP at the moment.
When I download the stylesheets involved, and try to transform things
from the command line using:
java org.apache.xalan.xslt.Process -in
./build/src/codegen/allprops.xml -xsl ./build/src/codegen/genconst.xsl
-edump
everything works fine with the latest XalanJ build.
I think the problem lies in the org.apache.fop.tools.xslt.TraxTransform
class and its callers.
Before the change, XalanJ incorrectly interpreted the expression
"document(node-set)" to load a document relative to a base URI which was
basically the URI of the stylesheet. Since all of the XML files were in
the same directory as the stylesheet, this worked. However, the XSLT
Recommendation requires that, for each node in the node-set, XalanJ use
the base URI that is the base URI of that node.
Your custom Ant task creates a DOMSource from a w3c Document but never
sets the systemID of the DOMSource which expresses the URI from whence
the document originated. It is this systemID that XalanJ uses as the
base URI of the nodes in the DOMSource. Since it was not supplied,
XalanJ really has no choice but to pick some arbitrary directory to use
as the systemID for the DOMSource and it picks the working directory
which is why it fails since the XML files referenced by document(....)
are obviously not in the working directory.
To get around this, you'll need, I think, to rework your Ant tasks and
the supporting classes to either carry along the URI of the Document or
build your Source from a StreamSource or something.
I'm sorry I don't have time to explain this further but I hope this is
clear enough for the FOP people to look in the right place. I'm off to
a funeral and can't really do much more right now.
If there are specific questions about what the problem is, please come
back to the Xalan-dev list and we'll try to help.
Gary
Gary L Peskin wrote:
>
> I'd be happy to look into this since Myriam is away.
>
> Gary
>
> Sam Ruby wrote:
> >
> > Steven Coffman wrote:
> > >
> > > Can you do a clean checkout? We now include (and use) the Avalon
> > > Framework and LogKit 1.0b4. In addition, we reorganized a few things. It
> > > should build fine if you do.
> >
> > This looks like the same problem that I tracked down on the 18th and reported
>here. Namely that the following change:
> >
> >
>http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xalan/templates/FuncDocument.java.diff?r1=1.23&r2=1.24
> >
> > ...causes the following build failure:
> >
> > http://jakarta.apache.org/builds/gump/2001-08-18/xml-fop.html
> >
> > My purpose of running Gump is to get people to actually talk. When FOP
> > recently made a change that broke Cocoon, the right thing apparently was to
> > change cocoon. In this case, Xalan has recently made a change that will
> > ultimately break FOP's build process.
> >
> > Karen Lease did some more analysis of this problem, and came to the conclusion that
> > >
> > > I think the FOP XSL is correct, but of course, I could be wrong...
> >
> > I would be interested in hearing what other Xalan developers think...
> >
> > - Sam Ruby
