Re: [xsl] document() function and error-handling

Subject: Re: [xsl] document() function and error-handling
From: Abel Braaksma <>
Date: Fri, 04 Jan 2008 01:36:28 +0100
Scott Trenda wrote:
Sure, usually I'd reply to the list, but at the point where you're
redefining the XmlResolver used in the .NET XSLProcessor instance used
for an admittedly fringe case, in order to get around a limitation that
the XSLT specification clearly says it defines no control over... isn't
that getting a little implementation-specific? My reply to Anthony was
more one of curiosity, a tangent that would help me at work in other
ways, but not really related to the topic at hand.

Damned if you do and damned if you don't, eh? Although I suppose this is
not so harsh when compared to being reprimanded by the list owner for
*not* following list guidelines. ;)

Haha, no surely not. It wasn't meant as a reprimand anyway, I know you are a regular poster to the list. Anyway, I think even implementation specific solutions have a place here when they serve a generic need. Saying that someone can be solved by using the XmlResolver may hint somebody else using a Java processor to use the URIResolver, which is in general the same thing.

On a different level, being not sure I read every single letter on this thread yet, was it already proposed to use a proxy? Because with a proxy (which has hardly anything to do with XSLT of course), you can just do whatever you want.

I.e., suppose you create a proxy HTTP server that resides on the same server as your Coldfusion stuff, suppose that http://localhost:123456/proxy? runs a proxy script and that you call it as http://localhost:123456/proxy?url= Now your proxy script must do two things:

1. test if the url exists and if not, reply with an XML compatible error
2. test if the result is a valid XML document and if not reply with an XML compatible error, if yes, reply with the XML result itself.

By doing something like that, you've taken the burden of your XSLT and you do not need to result to complex platform specific solutions. In fact, the solution will be very portable (and is close to what you would've done if you implement the XmlResolver solution, which however is in practice much harder with MSXML alone).

-- Abel Braaksma

Current Thread