Re: Notes on the process

Tim Bray wrote:

> I claim consensus *was* reached.  Because you will discover that the
> ERB members, having worked through this, will be out evangelizing
> XML, whichever way we voted on one issue or another.  I do, and I
> dissented loudly on all sorts of important stuff ("ambiguous" content
> models, grrrrrr).  There has been no significant design decision on 
> which there were no dissenters.  Simultaneously, the ERB contains no 
> misfits or malcontents.  In the case of this effort, we have used 
> voting as a mechanism to establish consensus.

Consensus on XML? Perhaps. This particular issue? No. We do not have the 
"general agreement, concord, or harmony" of the WG on this issue. What we
have is a simple majority of those participating in the last ERB vote.

> One weird and slightly worrying thing is that as soon as it becomes
> obvious which way the ERB is heading on any issue, the volume of
> WG traffic in opposition quickly becomes much larger than that in 
> support.  A behaviorist might have an explanation.  The effect is
> that I never have the slightest idea what the *majority* opinion on
> anything is out there - this is aggravated by the fact that the 
> traffic is too high for many people to read.  Thus one can only
> safely attend to the quality of argument, not its volume. -Tim

Why is this unusual? It seems to me that in rational conversation and debate,
the parties listen to arguments and respond. If the ERB is perceived as
heading in a particular direction, those opposed to that direction have
an obligation to voice their concerns *prior* to ERB action. Those in favor
may be less inclined to contribute to the volume of traffic for a very
simple reason, they expect the ERB to adopt their position.

That you don't "have the slightest idea what the *majority* opinion" might
be on any issue is of concern. If others on the ERB are similarly
unaware, on what basis are votes cast and decisions made? The ERB has
a responsibility to understand both the issues *and* the opinions of
members of the WG - individually and collectively. If not, why do we bother
with this mailing list and all the traffic it creates?

Many of us in the WG have day jobs and are unable to respond to all of the
postings to this list. I recently "raised my voice" on the error handling
issue because I envisioned applications that could not be implemented if the
draconian model were adopted. That seemed like something of import to me.
I don't recall any discussion refuting that position.

Based on Tim's last statement, I must assume that neither my arguments nor
Eve's statement on novel applications were of sufficient "quality" to warrant
discussion. I can only apologize for not having the time to prepare more
eloquent arguments expressing my strong desire that we develop a standard
that is inclusive rather than exclusive and can be employed in a variety of
applications that will be both easy to use and of benefit to those who use
them.

It is clear that there is disagreement on error handling. However, there
should be no misunderstanding that the recent ERB vote precludes reasonable
use of XML in certain applications, some might even be termed "mission
critical". I will offer one final scenario of such an application and then
be gone.

I believe that in the not too distant future that the Internet will be
ubiquitous, at least to the same extent as the telephone system in the
industrialized world. I also expect that XML could be the lingua franca. 

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. What is transmitted is:

<ACCIDENT>
  <LOCATION>
    <LATITUDE>
      <DEGREES> ... </DEGREES>
      <MINUTES> ... </MINUTES>
      <SECONDS> ... 
    </LATITUDE>    
    <LONGITUDE>
      <DEGREES> ... </DEGREES>
      <MINUTES> ... </MINUTES>
      <SECONDS> ... 
    </LONGITUDE>
  </LOCATION>
  <OCCUPANTS>1</OCCUPANTS>
  <INJURY>Probable. Likely unconscious </INJURY>
</ACCIDENT>

(The GPS devices was damaged and is unable to properly form it's component of
this rather important message.)

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. The technologies used in this scenario are well-known and
relatively commonplace. XML could be commonplace too, but only if 
application developers and users determine acceptable use and appropriate
error handling mechanisms.

The ERB-proposed error handling language not only attempts to legislate
error processing, it indirectly precludes use of XML in many applications.
This seems contrary to our desire to make SGML easier and broaden it's
appeal.

I urge the ERB to reconsider this issue. At minimum, it is appropriate to
see some acknowledgment that the ERB understands that it is limiting
the use of XML to those applications that can abide by the draconian measures
required by the proposed language.

Received on Thursday, 8 May 1997 16:43:50 UTC