Re: [xsl] debugging document() call

Subject: Re: [xsl] debugging document() call
From: Lars Huttar <lars_huttar@xxxxxxx>
Date: Wed, 30 Jun 2010 15:30:37 -0500
On 6/30/2010 2:20 PM, Michael Kay wrote:
>
>> I just found
>> http://saxon.sourceforge.net/saxon7.9/extensibility.html#Writing-a-uri-resolver
>>
>> which says, "Saxon allows you to write your own URIResolver to handle
>> the URIs of input documents, as defined in the JAXP 1.1 specification.
>> Such a URIResolver is used to process the URIs used in the |xsl:include|
>> and |xsl:import| declarations as well as the |document()| function. ..."
>>
>> That sounds like a step in the right direction...
>> but how do I tell Saxon to use my URIResolver?
>>
>>    
>
> At the Saxon level, you call setURIResolver in any one of a number of
> places: the TransformerFactory, the Transformer, the Configuration,
> the Controller etc.
>

I guess the easiest way for me to do this is to download the Saxon
source code, modify StandardURIResolver (uncomment the initial println
in resolve()), build Saxon, and use the modified jar within Cocoon.
Unless I'm missing something obvious?

> Unfortunately, though, it looks as if in this case Saxon is buried
> under several tons of other software sitting on top of it, and I can't
> help you drill down through that. It's almost certain that this
> superstructure has something to do with the problem, as well, since it
> all affects how relative URI references get resolved.

Understood.
However, at this point indications from Cocoon's logs are that the
superstructure hasn't even been notified about the URI reference, so
there's little to go on when it comes to tracing a problem in Cocoon.
If I can get Saxon to tell what base URI it's using, and maybe other
diagnostic information about its attempts to get data from the resolved
URI, I'll have more ammo to take back to the Cocoon side and be able to
help them know for sure whether the problem lies in Cocoon's territory
or Saxon's.

Thanks again for taking time to help.
Lars

Current Thread