W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > May 1997

Re: ERB votes on error handling

From: Bill Smith <bsmith@atlantic-82.Eng.Sun.COM>
Date: Wed, 7 May 1997 19:02:38 -0700 (PDT)
To: w3c-sgml-wg@w3.org
Message-ID: <libSDtMail.9705071902.6425.bsmith@atlantic-82>
Gavin Nicol wrote:

> Assuming that you are stream-based, the processor might see two stories,
> and an illegal end tag.

But according to the XML spec, 

  "There is exactly one element, called the root, for which neither the
  start-tag nor the end-tag is in the context of any other element."

That statement is rather clear and when taken in conjunction with the recent
"vote" would indicate that on seeing the second story, an error must be
raised and further XML processing aborted. It seems to me, that any 
streams-based application can not use XML unless it is encapsulated in
yet another protocol wrapper. Sad that otherwise simple applications
must be so complicated.

> This is not a good example though. Obviously you cannot hope to tune into
> a stream of structured information in the middle without some necessity
> for synchronization (jump to the middle of a frame of MPEG data, and see
> what you get).

Why not? I do it all the time with TV, radio, movies, theater, etc. These
are all "structured information" but at present require a human to make 
sense of the structure. (We all recognize commercials, credits, etc.)
What the draconian model says is that you are not *allowed* to perform the
synchronization anywhere but at the beginning of an XML document even if 
you could reasonably do so. I'm not sure where the beginning is in the 
simple brodcast model I've outlined.

> This is particularly interesting to me, because I have a proposal for
> exactly what you outline above: realtime delivery of HTML and XML. An 
> application built using my proposal would not suffer from the above
> problem.

I believe it is possible to build such a system - if you avoid XML or
needlessly complicate it by encapsulating it in another protocol layer.
The draconian model either precludes certain applications or makes them
more difficult than they need to be. And for no obvious advantage.
Received on Wednesday, 7 May 1997 22:02:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:26 UTC