Re: Error Handling

Since Jon is in Spain, I'll take this up.

At 06:46 PM 5/6/97 -0400, Paul Prescod wrote:

[Jon is talking about draconian models of error handling]
>> IT'S THE MAJOR IMPLEMENTORS WHO ARE ASKING US TO DO THIS.  
>
>Let me see if I can put this politely: is the major implementor who 
>has traditionally had the most trouble with correctness (and not 
>coincidentally the largest market share) part of this group?

Politeness not required.  Jean Paoli of Microsoft is 100% in favor
and has consistently taken the Draconian position so far.  Netscape
has also made it very plain that this is the behavior that they want.  
Netscape is not yet a member of the group, but is taking active steps 
to put a qualified representative in place.  In the interim, they have 
made their concerns on this front very clear to several members of the
ERB and WG, including me.  Yes, it would be better if they were
here and could say it themselves.

>Anyhow, if they are all agreed that they want to be tough on errors,
>why don't they just DO SO and let the editors and other tools do the
>Right Thing for their customers?

Because the technical people are very aware of the dangers of some
marketing droid seeing a possible competitive advantage in incorrect
behavior and launching us down the HTML poop-chute again.  We are 
trying to achieve a big cultural change, we need all the ammo
we can get.  Or were you proposing doing this for HTML?  It's too
late for that (and I would argue that the forgiving behavior for
HTML is just fine, and a major reason for the Web's success).

>There is a big gap between specifying mandatory error recovery and 
>specifying mandatory error non-recovery. In the middle is: 
>"specifying/requiring error reporting and leaving error recovery
>upto the best judgement of the vendor.

Right; we understand this very clearly.  There is a strong feeling
among vendors of commercial authoring and display software, and serious
information providers, that we want mandatory error non-recovery.

>Nobody wants the
>errors to be "passed over". They want them to be reported. And then they
>want the vendor and user to work together to decide what is the best
>thing to do from that spot.

Error reporting has been tried in HTML-land, and failed.  Nothing less
than a draconian policy has a chance of making it clear that we're
serious.  The theory is that error reporting will be taken seriously
only if it is accompanied by an absence of data.

>> People who insist that there is a customer requirement for "forgiving"
>> document applications overlook the fact that we already have those:
>> they are called HTML browsers.  
>
>And SGML editors. Doesn't every SGML editor you have ever used do its best
>with incorrect data? How about Jade? Right this very minute I am processing
>invalid and non-well-formed documents with it. 

There's no reason that should stop.  We have to make it clear that
there is a place, in authoring systems, for all sorts of weird noncompliant
documents, in transition to being XML.  The comformance of an authoring
system is only measurable in terms of its output - which HAD BETTER
be well-formed.

In fact, one of the reasons why Jade/SP are so big, and why it takes
a superhuman like James Clark to write them, is because they have
had this kind of wizardry built in.  One of the goals of XML is to
enable the creation of lightweight tools that can flit about the
web; while SP is wonderful and appropriate in support of editing
environments, we'd like something a lot smaller and simpler to
run in our JVM's.

If, on the other hand, you are saying that you like Jade/SP because
you want to produce and publish non-WF documents, then you are correct;
you will not be able to use XML because no popular browsing tool will
support such a practice.

There's one last key point:  If Netscape and Microsoft jump on board,
as they say they will, then no major browser will display non-WF
docs.  So the publishing model can be about the same as it is now;
create the doc, see if it looks OK in Navigator or Explorer, and if
so, ship.  With the knowledge that it's well-formed.  Which means:

- No information provider who does even the most cursory checking
  will publish non-WF docs
- No user will ever be in the position that he can't see an "interesting"
  doc just because it's non-WF, because there won't be any
- And if there are, they will be evidence of either serious breakage
  in the delivery system, or a provider who is so contemptuous of
  quality that 
  (a) they can't master balanced-tag + quoted-attribute syntax, and
  (b) don't bother with even a single basic usability check before
      publishing.
  In other words, a bozo, whose output can safely be ignored anyhow.

Cheers, Tim Bray
tbray@textuality.com http://www.textuality.com/ +1-604-708-9592

Received on Tuesday, 6 May 1997 19:20:18 UTC