Hi Lars,
I would say that the reference URI is the one of the xslt script itself.
So putting the document to fetch in the same directory should help.
A common problem is that there is uri-wise nothing to fetch:
if you use a relative URI, this would hide the fact that the protocol is
http;
if you recompose the absolute URL from there, would there be a way that
the document
would make it through the pipeline definitions in your sitemap?
Cheers,
Jos
On 06/29/2010 04:20 PM, Lars Huttar wrote:
Hello,
I'm wrestling with the following in Cocoon 2.1.11.
I have an XSLT that uses document() to retrieve a source document
other than the one coming through the pipeline. I remember that the
use of document() isn't encouraged in Cocoon, at least because Cocoon
then doesn't know when to invalidate the cache for that pipeline.
However, I don't have much choice in this case... the XSLT is someone
else's. (It's the common XSLT implementation of Schematron, and I'd
rather not modify it any more than I have to, because then upgrading
it will be difficult.)
When I run this stylesheet, the document() call is apparently
retrieving nothing. The argument to document() is a relative URI.
So I figure that between the base URI that is being used, and the
relative URI (which is a simple "filename.sch"), the result is not a
URI than Cocoon is able to resolve to the right file.
According to the XSLT spec, the base URI should be either the input
document or the stylesheet, depending on where the relative URI comes
from.
I believe it is considered to come from the input document in my case.
However I don't know what the XSLT processor considers to be the URI
of its input document.
I think if I could turn on verbose logging of the URI resolver, I
could find out what the XSLT processor thinks is the base URI, and
then maybe fix the problem. But I can't get that to happen. Btw I've
tried this with both xalan and Saxon for the XSLT processor.
I'm looking at
http://wiki.apache.org/cocoon/ConfiguringTheLogs
and
http://wiki.apache.org/cocoon/UnderstandingCocoonLogging
and I added a "resolver" target to logkit.xconf, and a category to
send core.resolver messages to resolver.log file.
That works, for URLs processed by the sitemap: The file
WEB-INF/logs/resolver.log appears and has content.
But there is no message for the xsl:include processed internally to
the XSLT.
Maybe this is a Saxon / Xalan issue rather than a Cocoon issue. But
the xsl:include works fine outside of Cocoon, e.g. in Oxygen. Granted,
in that case I know what the URL of the input document is; it's a file
URL. And the relative URL in the xsl:include works relative to the
file URL of the input document.
Surprisingly, even when I gave xsl:include an absolute URL, e.g.
"http://localhost:8080/mount/...";, the document() statement seems to
still fetch nothing.
This URL works fine in the browser (same machine). So this would
suggest that the base URL of the input document is not the whole problem.
Can anybody suggest how to debug this?
Thanks,
Lars
