- From: Kay, Michael <Michael.Kay@softwareag.com>
- Date: Thu, 19 Jun 2003 19:01:04 +0200
- To: Eric Johnson <eric@tibco.com>, public-qt-comments@w3.org
> I encountered a problem of a somewhat similar nature using XSLT 1.0, > using the document function. In certain scenarios, using > Java, the user > could make a "document()" reference to a document that might not be > there, or might not parse correctly, and I wanted to be able > to handle > the error in the XSLT, not in the Java code. > > My work-around was to always return a document via the > URIResolver, just > that sometimes it would have special "error" content. The document() situation is certainly one of the main use-cases for this capability, but it is not the only one - XSLT 2.0 and XPath 2.0 define many more dynamic errors than 1.0 did. Most of these are preventable (this is why we added the "castable" operator, so that you could preempt errors in casting) but not all. It's true that writing your own URIResolver gives you a way of handling the document() errors, assuming you are in the Java world. Michael Kay
Received on Thursday, 19 June 2003 13:01:13 UTC