Re: Notes on the process

[Bill Smith:]

| It is likely that cars will have IP addresses and will carry GPS
| devices.  But cars will still be involved in accidents - even in
| remote locations.  The good news is that by combining the input from
| the GPS device, accelerometers, and motion sensors my car will know
| where it is, that there has been an accident, that it is likely that I
| am unconscious, and will report these facts to www.911.com - using
| XML. It might do so repeatedly.  The bad news is that as a result of
| the accident, the onboard system is unable to send a well-formed
| document. [...]

| I would term this a "mission critical" application. It is also one
| that *must* be fault-tolerant. As a result of the recent ERB vote and
| proposed language, this application will *not* (I hope) be implemented
| using XML.  If it were, I might not survive what might have been a
| survivable accident.

Take it easy.  Read the text of the error handling resolution.  The
processor is required to behave in the manner we've described only as
long as it's calling itself an XML processor.  This is an advertising
issue.  In the scenario Bill describes, the processor sees the broken
message, and this being what he calls a "mission critical"
application, it has been programmed to respond to such a message by
saying to itself, "This is broken, so it must not be an XML message,
and therefore I'm free to stop being an XML processor and to do what I
need to do, which is to recover the message the best I can and get it
to the receiver in the best shape that I can manage."  So the parser
has to take off its figurative "XML approved" hat for a minute to save
your life.  Big deal.

This is not the kind of processor that is going to care about strict
XML conformance because no one is going to object to its behavior.
Its manufacturer will lose zero sales from technical nonconformance,
because no one will mind it.  And even if the processor were Simon
pure, the conformance language allows the processor to simply pass all
the data to the application; there's nothing at all that says that the
*application* can't attempt error recovery.

Editors are another class of applications that fall into this
category; their input processors have to be strictly nonconforming
under the new error handling rules in order to bring in malformed
documents to be worked on.  So what?  No one cares that their input
modules are nonconforming; they are only going to care if their
*output* is nonconforming.  So the technical nonconformance of their
input modules has no market consequence.

The case we're addressing with the recent decision about error
handling has to do specifically with the competitive landscape in Web
browsers.  There is nothing in the new language that prevents Web
browsers from handling error recovery any way they like.  What they
can't do is to behave in a way that doesn't conform to the spec and
*advertise themselves* as XML browsers.  In other words, it gives the
browser vendors a stick with which to beat each other up if they start
playing games with the XML specification.

I confess to being a little disappointed with the inability of some
people in this group to understand that this is not a technical issue
but rather a unique opportunity to change our industry's competitive
landscape.  The major browser vendors are saying, in effect, that they
would rather compete on the basis of conformance than on the basis of
nonconformance.  Whether they sincerely mean this or not (I have no
more confidence in this than anyone else does) will become apparent in
the fullness of time, but it would have been irresponsible in the
highest degree not to have seized our only opportunity to find out.

Jon

Received on Friday, 9 May 1997 13:17:19 UTC