XSLT document(), logging URI resolver

[Lars Huttar <la...@sil.org>]

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

Re: XSLT document(), logging URI resolver

[Lars Huttar <la...@sil.org>]

Hi everybody,
Just FYI, the problem was not with Cocoon, nor with Saxon.
The problem was a bug in the implementation of Schematron that I was
using, that affected the <iso:include> element, when the href attribute
had no '#' in it.
The latest version of this implementation does not have this bug.

Thanks to those who took time to help me troubleshoot this.

Lars



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

Re: XSLT document(), logging URI resolver

[Lars Huttar <la...@sil.org>]

On 6/30/2010 10:45 AM, Lars Huttar wrote:
> 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.
>

OK, I tried that...treating the base URI as that of the stylesheet. I
added a match pattern to the relevant sitemap to handle the URL as it
would be resolved relative to the stylesheet's URL.
There was no change in the result. The document() call returned nothing,
and the Cocoon logs showed no attempts to access that new match pattern
via any sitemap.

Lars

Re: XSLT document(), logging URI resolver

[Lars Huttar <la...@sil.org>]

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.

Lars


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

Re: XSLT document(), logging URI resolver

[Jos Snellings <Jo...@pandora.be>]

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
>