[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: document() function and error-handling

Subject: RE: document() function and error-handling
From: "Scott Trenda" <Scott.Trenda@xxxxxxxx>
Date: Thu, 3 Jan 2008 18:14:52 -0600
RE:  document() function and error-handling
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:  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:  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!

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.