Re: XSLT document(), logging URI resolver
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 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
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
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
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
XSLT document(), logging URI resolver
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