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=http://test.com/doesnotexist. 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).
Cheers,
-- Abel Braaksma
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--