Re: [xsl] aborting element creation

Subject: Re: [xsl] aborting element creation
From: David Carlisle <davidc@xxxxxxxxx>
Date: Fri, 11 Feb 2005 11:22:14 GMT

  I never took a good look at it, but IMHO I think the idea of letting the  
  implementation decide what to do with xsl errors is rather bizar. It  
  should at least be controllable.

You have to remember that the original use case for XSLT was that it was
a companion to the original use case of XML. Instead of doing it the
"old way" down-converting SGML on the server and sending html over the
wire, the "new way" would send XML (Originally SGML-online) over the
wire and couple it to a powerful client side XML styling language (which
became known as XSL(T)).

In a browser world there is a long history of supporting essentially
arbitrary error recovery. If you are looking at a page written by
someone else in another continent, there's not a lot of point in being
told that there is an error on line 10001, you just want to get as much
of the real information as possible.

So XML has "draconian" error recovery where more or less every error is
fatal, this was supposed to constrain authors into getting it right in
the source, but XSLT was designed to allow implementations (presumably
to be used by XSLT developers) that generated errors but also to allow
implementations in browsers that essentially never give a run time error
and always do "something sensible".

It may look bizarre now, but the world didn't turn out quite as people
thought, evidence the number of times people are told on this list and
elsewhere that it is often better to run the transformations on the
server rather than on the client. Which is probably true but was exactly
the thing which XML was developed to avoid.


This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:

Current Thread