RE: [xsl] debugging document() call

Subject: RE: [xsl] debugging document() call
From: "Robby Pelssers" <robby.pelssers@xxxxxxxxx>
Date: Wed, 30 Jun 2010 10:08:45 +0200
Hi Lars,

Do you have a match pattern (in pipeline) defined in your cocoon sitemap to
matches the relative URI?


-----Original Message-----
From: Lars Huttar [mailto:lars_huttar@xxxxxxx]
Sent: Tuesday, June 29, 2010 10:06 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: [xsl] debugging document() call


I'm wrestling with a problem getting document() to retrieve an XML
document, in the environment of a web application framework (Cocoon 2.1.11).

I'm using the common "skeleton" implementation of Schematron, where a
skeleton XSLT transforms the Schematron schema into another XSLT
stylesheet which performs validation.
When the skeleton XSLT is trying to transform the schema, and it
encounters an <iso:include> element, it uses document() to read in an
external schema and incorporate it into the output validator XSLT.

When I run this stylesheet in the web app environment, the document()
call is apparently retrieving nothing... nothing shows up corresponding
to the <iso:include> element in the output XSLT.
However, when I run it in a debugger such as Oxygen's, the document()
call apparently works, because the output XSLT contains the stuff from
the included schema.

The argument to document() is a relative URI.
So I thought that maybe between the base URI that is being used, and the
relative URI (which is a simple "filename.sch"), the result is not a URI
that the XSLT processor 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, in the web app environment; if it is the output of a
pipeline of generators and transformers, it may not have a URI at all...
or not one that can be meaningfully used as the basis for a relative URI
to retrieve the included schema file.

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 was able to turn on verbose logging of the URI resolver in the web app
framework, but it only logs the URI resolution being performed by the
framework components, not by the XSLT processor. At least I don't see
anything in the logs reflecting an attempt to resolve the URI of the
included schema file.

Surprisingly, even when I give iso: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? I looked for ways to turn on
verbose logging in Saxon but couldn't find any.
Incidentally we are using Saxon 8.


Current Thread