Re: Error and Fatal Error

On Sat, 2011-07-16 at 17:09 +0100, Stephen D Green wrote:
> It's a bane to developers that parsers regard errors in XML
> as fatal which need not be fatal, IMO.

An expert system could be used to try to determine what the user might
have meant, but we wanted XML to be embeddable in small devices.

Programs like "tidy" can go a long way.

> e.g. the .NET parser causes me grief when code falls over
> because of illegal characters

You'll find the C# compiler does that too, and so does javac and the C
compiler and many others.

> So it would be better for future versions of XML (influenced
> perhaps by recent discussion related to MicroXML on this list)
> if the specs gave less of a push towards parsers regarding
> errors as fatal.

So if the Microsoft parser accepts attributes without quotes around
them,and the Sun^H^H^HOracle parser accepts </> as an erroneous way of
closing an element, and the libxml open source parser accepts a missing
> in <a><b<c>, how many XML documents will work in all three parsers?

The HTML5 approach was used for HTML 5 (duh) because the authors
basically only really care about 5 implementations. I'd be surprised if
there were fewer than 1,000 XML parsers, and many of them are in
situations where updates won't occur for many years - televisions,
aircraft navigation systems, shoes :-), washing machines, car
engines.... you name it.  This is made possible because of reliable
parsing.

On the other hand, if there's a groundswell _outside_ the Web browser
context, maybe we could say, e.g., xml documents starting
<?xml version="1.0bis"?>
can contain errors, since older (all existing) processors will fail on
them anyway?

My own concern is rather more one of, how do we help people make
documents that don't contain errors in the first place more often.

More on that (I hope) at Balisage.

Liam

--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/