cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Huttar <>
Subject Re: XSLT document(), logging URI resolver
Date Wed, 30 Jun 2010 15:45:29 GMT
On 6/29/2010 10:08 PM, Jos Snellings wrote:
> Hi Lars,
> I would say that the reference URI is the one of the xslt script itself.

Jos, thanks for your reply.

Why do you think that the reference (base) URI would be the URI of the
XSLT stylesheet in this case?
Ah... I just looked up the spec for XSLT 1.0. I had been looking at XSLT
2.0, where the base URI is taken from the document from which the
(single) argument to document() belongs. But in fact the XSLT
stylesheets I'm running declare themselves as version="1.0". So it could
well be that the base URI here is that of the stylesheet.

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

Yes, there is, if the base URI is what I thought it should be.
But if it turns out to be the base URI of the stylesheet, the situation
is a little different.
I will try proceeding on that assumption and see if anything changes.

However, recall that even when I used a correct, absolute URL for the
include, the thing still didn't work.
So I don't have much hope that using a different relative URL will help.
Even if it resolves to a correct, absolute URL, I've already found that
not to work.


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