Altova Mailing List Archives

RE: [xml-dev] XSLT2 - which parts solve real 1.0 problems,whichmakes coffee? - was Re: [xml-dev] Streaming XML

From: Uche Ogbuji <uche.ogbuji@-----------.--->
To: Michael Kay <mike@--------.--->
Date: 1/1/2005 6:35:00 PM
On Fri, 2004-12-31 at 10:31 +0000, Michael Kay wrote:
> > > and try/catch.
> > 
> > Ooh.  Intriguing.  We had a discussion about such extensions in the
> > 4Suite mailing list a few years back.  My own proposal was for special
> > XSLT error templates that could "match" or trigger on error 
> > conditions,
> > assuming a very simple XML vocab for XSLT error communication in the
> > first place.  Then there could be some sort of error mode so that
> > explicitly scoped try/catch constructs were not necessary.  Rather,
> > simple heuristics would provide for matching current error and error
> > mode to error template.
> > 
> > Do you know of or have any references to any particular exception
> > handling proposals from the XSLT 2.0 development process?
> There were a number of iterations within the WGs on this. Try/Catch was
> initially tackled as a joint item between XQuery and XSLT. Then XQuery
> decided that it would be a mistake to define try/catch before defining
> transaction semantics, which are part of the post-1.0 update proposal. The
> XSL WG then looked briefly at various ideas for an XSLT-only solution,
> either at the XPath level or the XSLT level, but it foundered partly because
> of the difficulty of defining the semantics precisely enough, partly because
> it's not clear how far one should go in terms of catching specific errors
> versus general errors: in the end it probably didn't get in because no-one
> was able to produce a really complete and convincing proposal, even though
> the WG liked the idea in principle.

If the WG ever gets back to this, I would suggest not trying to mimic
try/catch flow-of-control in traditional languages.  Notice how in my
error template example you don't have to do any wrappering or the like
in the XSLT that might throw an exception.  The exception cases would be
declared in the spec, or in extension semantics, and the declared error
templates would just be invoked accordingly.

> I do in fact have a user-written Saxon extension in this space waiting to be
> integrated, but like many such contributions it contains code changes only,
> no documentation or tests or design, so it's not all that useful. In the
> meantime Saxon SA does contain a very simple saxon:try() pseudo-function:
> see

Interesting idea, but not really what I have in mind in terms of
capability.  For one thing, it only handles individual XPaths.  For
another, the only handler action permitted is returning a string.

Uche Ogbuji                                    Fourthought, Inc.
Use CSS to display XML -
Full XML Indexes with Gnosis -
Be humble, not imperial (in design) -
UBL 1.0 -
Use Universal Feed Parser to tame RSS -
Default and error handling in XSLT lookup tables -
A survey of XML standards -
The State of Python-XML in 2004 -


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.