-----Original Message-----
From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx
[mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of
J.Pietschmann
Sent: Tuesday, May 14, 2002 7:19 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re:  XSLT/XPath 2.0 (was "Identifying two tags...")

bryan wrote:
>> fine, one of the things that I think we should want is a little more
>> control over our error responses, just like any other programming
>> language offers, or at least most that I've seen. This allows us to
>> build apps where xslt functions as the error handler, and the
validation
>> language functions as the error generator.

>Something like trapping or catching excpetions. This would have
>some other interesting applications, in particular regarding
>document() and xsl:document. I don't think we'll get try/catch
>or "on error" in XSLT. For once I'm not sure how try/catch would
>be applied to parsing and validation errors, and "on error" is
>just not as compatible with a language using XML syntax as
>try/catch would be.


This is more in regards to the suggested alternative Schema Validation
integration discussed earlier in the thread. The subject was getting a
returned error response from a failure of Schema validation that one
could access in the xslt, responses like <xsl:message> some sort of
thing here about what happened to give our schema error</xsl:message>

Speaking of which in the example xslt 2.0 with the xsl:text made bad
error, memory was telling me that one could have further processing
inside of xsl:text in xslt 2.0, was confounding that with changes made
to xsl:message


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list