W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > May 1997

Re: Notes on the process

From: Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU>
Date: Thu, 08 May 97 18:10:30 CDT
Message-Id: <199705082333.TAA19447@www10.w3.org>
To: W3C SGML Working Group <w3c-sgml-wg@w3.org>
On Thu, 8 May 1997 18:13:54 -0400 Todd Freter said:
>Moreover, neither the current state of the Internet nor the availability
>of other protocols or data representations invalidate Bill's argument,
>which is about XML, fault-tolerant applications, and how the current ERB
>decision makes XML beg off from processing them.

Well, it makes XML processors not attempt the error recovery.  Which
is, I think, all to the good.  If an automobile accident reporting
system or other life-and-death systems wish to build in error
tolerance, they should do so using some well founded, well designed
system of error recovery.  They should *not* base it upon some parser
writer's SWAG about whether


is more likely to mean which of the following:








  <l>Mary had a little lamb</l>
  <l>little lamb, little lamb</l>
  <l>Mary had a little lamb</l>
  <l>whose fleece was white as snow.</l>

If a life and death application can't rely on parser heuristics to
recover from errors in the input, then the error recovery should
probably be in the downstream application, not the XML processor as
described in the spec, in any case.  So I don't see that the decision
has made any difference to the plausibility of XML as a choice for such

I could be wrong, of course.  Wouldn't be the first time.

But are you willing to bet me your life that the average parser writer
will correctly guess which well-formed string from among those given
(and from the infinite number of other well-formed strings that could be
transformed into the original string by interruptions in the
transmission) was 'intended' by whatever created the original ill-formed

-C. M. Sperberg-McQueen
 ACH / ACL / ALLC Text Encoding Initiative
 University of Illinois at Chicago
Received on Thursday, 8 May 1997 19:33:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:09 UTC