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. ;)

~ Scott


-----Original Message-----
From: Abel Braaksma [mailto:abel.online@xxxxxxxxx]
Sent: Thursday, January 03, 2008 6:02 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] document() function and error-handling

Nassar, Anthony wrote:
> [.....]
>
> -----Original Message-----
> From: Scott Trenda [mailto:Scott.Trenda@xxxxxxxx]
> Sent: Thursday, January 03, 2008 1:02 PM
> To: Nassar, Anthony
>     ^^^^^^^^^^^^^^^
>

Please keep the discussion central (you send it to Anthony directly).
Your (Scott's) comment is important for us to understand your problem.
By sending all your replies to the list you ensure yourself of the best
responses and we can more easily follow the discussion.

> Subject: RE: [xsl] document() function and error-handling
>
> Thanks, this actually helps a lot. A question on the subject: our
> proprietary preprocessor that I'm using accesses MSXML's IXSLProcessor
> in C++; do you know if the XmlResolver class is available outside of
the
> .NET framework? If so, I can just tell our developer who maintains the
> preprocessor to force file-checking on physical paths, and to use the
> same mapped-path resolution for (local) logical paths. That seems like
> it'd be the better solution overall, and it'd fix some headaches of
mine
> in other places.  :)
>
> Again, thanks for the reply!