cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jos Snellings <>
Subject Re: XSLT document(), logging URI resolver
Date Wed, 30 Jun 2010 03:08:56 GMT
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 
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?


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
> and
> 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

View raw message