Re: Error Handling

Tim Bray wrote:

> 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.

Has anyone asked the users?!!! We need look no further than current Web 
users to know that something better than "mandatory error non-recovery" is
desired (if not required). The draconian model is extremely uninteresting
to me and a major step BACKWARD in my opinion. This is NOT the way to 
encourage adoption of XML.

> 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.

Authoring systems are the ONLY exception? What about a support system that
enables a remote engineer to view "XML" pages? Of course to be useful,
this system must be able to send/receive XML pages that contain errors. Is
this allowed? If not, we proscribe a class of interesting XML-based 
applications. If it is allowed, who will write the "XML tax code" (substitue 
your favorite bureacratic legal document) that describes the permissible
non-draconian applications.

> 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.

Quite true, we'd like something smaller and simpler than heavyweight
SGML parsers. XML enables that but the draconian model of error
non-recovery is not required. DynaText 1.0 was not big, did not require
superhuman effort, but did have some "wizardry" built in. The wizardry
hindered neither development nor market success. In fact, quite the 
opposite was true - on both counts.

The argument that error recovery is by necessity heavyweight is specious.
It is as light or heavy as the application and users demand.

> 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.  [snip]

Great news! 

Now let them make their product decisions and let the rest of us
small players make our product decisions. I've suggested that there
exist products other than browsers and authoring systems that merit our 
consideration when deciding this policy.  If authoring systems are exempt
from the draconian model (while "processing" the content) then I maintain
that there exist other applications that should be similarly exempt. But I
have no desire to legislate which applications are exempt or non-exempt.

In a prior posting I asked whether an error must be reported when an 
XML page transfer (to a browser) is interrupted by the user or by the 
browser when an auto-link is followed. I'll ask again but based on the
original silence I take it there is little interest in the question. I'm
interested because I'd like to know what behavior this WG is requiring in
such situations. I suspect that Microsoft and Netscape are interested as
well especially if the consensus of this WG is that XML pages be fully 
parsed by applications, always. 

If this is not required, it will be possible to receive an "invalid" 
document but process a portion of it as if it were valid. This seems 
contrary to the goal of the draconian model - which seems to be purge the
Web of invalid content. Perhaps admirable, but unrealistic.

Received on Tuesday, 6 May 1997 20:48:54 UTC