[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] re: RE: A call for reason
On 30 Nov 1999 rev-bob@g... wrote: > > >So as it stands, there will exist valid SML documents that are not well > > >formed XML and will therefore trigger a fatal error if given to an XML > > >parser. > > > > I was talking about removing an error reporting requirement > > because I believe XML WG went overboard with the error > > reporting requirements which places a heavy burden on > > the performance of XML parsers. > > In other words, the WG went overboard in specifying that when something is broken, > the parser must say so? I don't consider that overboard at all. > > > IMHO, HTML crowd got burnt badly with HTML's forgivable parsers > > and over-reacted. There are other ways to solve this sort of > > problems without resorting to high tariff on all. > > I think the UA authors finally got sick of having to code bloated "forgiving" parsers > because the HTML spec required a huge amount of tolerance, but I could be wrong. The problem with HTML was that the spec basically said "you can attempt to repair errors in an application-defined fashion." The result was a shitload of "HTML" that was "designed" with "knowledge" of particular applications' (undocumented) error-correction behavior; much of that "HTML" suddenly became unusable when new versions of popular browsers came out. Plenty of Web designers were arguing that they were getting paid to create pages that worked on what the majority of viewers were using, and they didn't care whether the only reason they "worked" was that the browsers' error-correction was giving them the results they wanted. "I'm too busy making money to make sure all my quoted attribute values have closing quotes just so Lynx users can read my pages. They work just fine in Netscape." And so they did, until Netscape 1.0 came out. And so on (*every* major release of Netscape came with a change in error-recovery behavior that broke lots of "they worked" documents). The lesson here is that allowing parsers to implement their own idiosyncratic error-recovery strategies inevitably leads to the proliferation of incompatible "slang" versions of the base language, each of which is understandable to only one parser implementation. In the case of HTML, we were dealing with authors who were either ignorant of the pitfalls of best-case design ("it works for me and works when I demo it to the boss, so it must be OK") or actively hostile to the philosophy of robustness ("when you say that's 'incorrect,' that's just *your* opinion")--the latter was IMHO partially due to an affected artistic-rebel-poseur attitude that couldn't distinguish between esthetic judgments, which, contrary to the moaning of some ultra-conservatives, *cannot* be treated as truth-valued statements, and criteria for formal-language correctness. The requirement that an XML processor not allow application-level attempts at repairing illegal syntax (which does *not*, BTW, demand that any application make a "terminate" system call to the OS if there's illegal syntax; it only demands that the application refuse to process the document in question) may sound harsh, but the alternative is either the creation of languages whose grammars can only be inferred by experimentation, or putting precise error-recovery strategies in the spec itself (which might work for an appllication-specific language where you know what the semantics are, but hardly for a metalanguage). Novice programmers (and non-novice script kiddies) like languages that don't enforce error-checking because, let's face it, error-handling code is tedious and boring to write. But there are only three alternatives: write the error-handling code, sweep errors under the rug (where they eventually catch fire), or use a system that's guaranteed not to generate errors. The latter option assumes that perfection is not only achievable, but has already been achieved. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|