- From: Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU>
- Date: Fri, 09 May 97 09:32:52 CDT
- To: W3C SGML Working Group <w3c-sgml-wg@w3.org>
On Thu, 8 May 1997 23:03:50 -0400 Liam Quin said: >> 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 > >No. But the application may be able to, given enough information. >I have in the past (a long time ago!) used versions of YACC that did >optional error recovery by inserting or deleting symbols. A C compiler >that used this technology did not generate code if there were errors, >but it _did_ give much better second and subsequent error messages. > >Most modern C compilers do this sort of error recovery, >now forbidden in XML. It is *not* forbidden in XML! The wording proposed and adopted says explicitly that the XML processor may continue to process the data stream and report further errors. It is required only to stop feeding the garbled data to the downstream application. This seems to me entirely analogous to the behavior of a compiler whose lexer and parser trudge on seeking errors while no longer bothering to feed the parsed source to the code generator. >Even SGML does not forbid error recovery. In fact, SGML's behaviour Nor does XML, in cases of errors other than WF errors. >on incorrect input isn't defined in the standard. This is why >Author/Editor can do error recovery and still be a conforming SGML System >(it says it is, on the splash screen, Eve!) -- and so can NSGMLS, >SPAM, Panorama, Omnimark and HoTMetaL ... Yes. On the other hand, the quality of error recovery exhibited by the SGML software I've used when confronted with the equivalents of WF errors is -- how can i say this delicately? -- not the world's most persuasive argument for SGML or for error recovery. It always surprises me when any error message after the first is even coherent. If your mileage varies, then good luck to you. -C. M. Sperberg-McQueen
Received on Friday, 9 May 1997 10:45:42 UTC