Re: Final words, I think, on error handling

Time for a Tolerant Draconian to delurk, I guess...

Tim Bray wrote:
> >> I think I am speaking fairly for the draconians when I say that from
> >> our point of view, it works because
> >>  - well-formedness is so easy that it isn't a significant burden on
> >>    anyone,

This was one of the two propositions in the summary I found difficult to
accept. (The other was "conforming editor" becoming an oxymoron.) I like
the concept of WF very much, but I'm by no means confident that what goes
towards WF in XML really meets my intuitive notion. Indeed, I believe that
WF in XML may not be quite as easy to achieve as it's made out.

Michael Sperberg-McQueen wrote:

> It is very important, for the long-term health of XML, that with
> regard to error tolerance and error detection we adopt something more
> like the culture of SGML (there is a spec, and if your document has
> errors, you better fix them pronto because otherwise your software
> may break and you will in any case be laughed to scorn and possibly
> ridden out of the next SGML 'XX conference on a rail) than like the
> culture of HTML as it has developed (where error recovery is in some
> cases just another name for buggy software not noticing the errors).

All true, except that the HTML culture was not entirely perverse. There
was certainly a resistance to The SGML Way, and the sheer complexity of
the requirements to remain on The Path Of Sufficient Virtue had a lot to
do with that. Like it or not, people *will* take the easy way -- a truism
that was acknowledged earlier on this list in the form of The Stoopid
Test. So, basically, I'd prefer the easy way to be the right way...:-)

> In the case of SGML, the banner of Validity has helped everyone a lot.
> (It has a down side, too, but on balance I'd say the introduction of the
> notion of formal validity is a major advance in document processing; one
> of the ways SGML is a step forward vis-a-vis GML and Scribe and so on.)

The down side has had to do with SGML's specification of Validity, not the
concept itself. Even with XML, I think Peter Flynn's Average HomeBrew
HomePager is going find it tough hoeing. And that's bad.

> Requiring XML processors to go on strike when they encounter ill-formed
> input is an important symbolic gesture that says "Come to XML, all ye
> who labor and are tired of dirty data."  It draws a line in the sand
> and delimits a class of data so hopelessly messed up that there is
> nothing useful to be done with it but issue error messages.

> Where we draw the line matters, to be sure.  But *that* we draw such
> a line may matter, in the long run, even more.  Because it establishes
> that formal correctness counts, too, not just pretty pictures and how
> it looks on a 21-inch monitor.

The basic point against the Draconian case is that a single (monolithic?)
policy towards error handling is a recipe for failure. In fact, I believe
the real stumbling block here is SGML's monolithic conception of "Error"
itself. Dare I say ontologically, the conception works better the simpler
the criteria are. The Good News for XML is that DTD conformance is not an
(immediate) issue; the Bad News is that there are nevertheless enough
merely lexical/syntactic gotchas to be fertile sources of errors -- and
not every XML document put on the wire will be the output of a smart
editor.

Unfortunately, it's more than a bit late to start tearing into the
xml-lang spec. But I think it's important to realize that a lot of the
real-life error policy that implementors will have to formulate anyway,
will be dealing with "errors" that could have been avoided in a simpler
spec. In the beginning (8 months ago), I had argued for simple and strong
rules (such as empty endtags); my hidden agenda was to obviate entire
classes of lexical and syntactic errors that would otherwise arise ...
<TULIPS tiptoe="tiptoe"> it's gotta be, quotes and all. Oh Well.

> >We can be totally draconian when it comes to well-formedness and the
> >Web will be just as messy, nasty a place tomorrow
> 
> Here I disagree.  If there are 10 flies in the soup today, then
> insisting on well-formedness may not give us fly-free soup tomorrow.
> But I think going from ten to five -- or even seven -- is well worth
> everyone's while.  At the very least, it calls everyone's attention to
> the notions of fly-in-soup, and the notion of screens that keep certain
> kinds of fly *out* of the soup.
> 
> And on the whole, I think we can safely say that that is progress.

Can this notion be formalized, perhaps?:-)


Arjun

Received on Wednesday, 7 May 1997 23:02:59 UTC