RE: strict error handling (was include vs. xsl:import)

[Kay Michael <Michael.Kay@xxxxxxx>]

I wasn't a party to the discussions, but it's fairly evident from reading
the spec that there were two schools of thought on the XSLT group: the
"strict" school who want all errors and ambiguities to be reported, and the
"liberal" school who think the transformation should try to struggle on and
produce some output whatever goes wrong. There are good cases on both sides:
the strict approach helps the developer produce a good stylesheet, but can
be rough on the end user who sees messages about errors that aren't his
fault.

Saxon generally takes the "liberal" approach where the standard offers a
choice, but I don't defend this as a correct decision. I think Xalan's
approach of producing warnings is better in many cases. There are some cases
which I don't really think should be errors at all, like outputting a
comment containing "--": at present, the stylesheet author needs to check
that the comment doesn't contain "--" to avoid an error, and the XSLT
processor needs to do the check again to report or recover from the error.
That seems wasteful.

Mike Kay

> -----Original Message-----
> From: Evan Lenz [mailto:elenz@xxxxxxxxxxx]
> Sent: 02 August 2000 00:37
> To: xsl-list@xxxxxxxxxxxxxxxx
> Subject: RE: include vs. xsl:import
> 
> 
> As Mike Kay points out in his book, the W3C spec says, "It is an error if
this
> leaves more than one match. An XSLT processor may signal the 
> error; if it
> does not signal the error, it must recover by choosing, from 
> amongst the
> matches that are left, the one that occurs last in the 
> stylesheet."  My
> question is, why have this as an option at all?  It seems 
> like for every
> option, there's a whole 'nother slew of headaches.
> 
> Evan Lenz
> elenz@xxxxxxxxxxx
> 
> 


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