Re: Notes on the process

>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.

I guess if the only tool you have is a hammer, everything looks like
a nail....

For mission critical applications, realtime constraints and data
redundancy are generally required. This to me implies higher level
protocols than those codified in the data. XML doesn't solve this 
problem, and shouldn't pretend to. Let's take Bill's example to the 
limit, and say that the obboard computer sent out:

  <ACCIDENT>
  <VEHICLE>sd;ghligk;db/lflgniupg nbpppv</VEHICLE>
  <LATITUDE>klnsfvouvjisbdfubfibdbufubufbf/LATITUDE>
  <`340-968gn]0984588y873**(&&E$*(&& m8qf9hnc 
  </ACCIcore dumped, your fault!

would you still expect it to work? What about if it sends out the
wrong vehicle identification, and the wrong positional data? Suddenly
you have an ER team rushing out to the wrong place, looking for
the wrong person.

For the situation Bill outlined, I would expect a simple radio
transmitter to work far more effectively: you can use triangulation
to locate the source, and encode the radio signals to include a
great deal of data redundancy in a much smaller number of bits.

This is not to say that I don't sympathise with some of Bill's
concerns. To me, a more valuable example is that of pressing the
cancel button while downloading a document.

Received on Friday, 9 May 1997 09:21:25 UTC