SGML WG status

[Paul Prescod:]

| I apologize for bringing things up out of order but it isn't yet clear
| to me what we are supposed to be discussing

I'm sorry that our order of work wasn't clear; this is partly my
fault.  I am trying to juggle the logistics associated with this
effort *and* monitor the creation of a TC to 8879 at the WG8 meeting
in Barcelona *and* participate in an HTML coordination effort within
W3C *and* proselytize XML and DSSSL inside and outside of Sun, and my
inability to do a proper job on all fronts at once is becoming fairly
obvious.

Here's a summary of where we are right now.

1. A Technical Corrigendum to 8879 is being formulated (literally as I
type this) at the meeting of ISO/IEC JTC1/SC18/WG8 in Barcelona this
week.  The goal of the WG8 meeting is to have a draft out for
discussion by the end of the week.  This is important to us because
XML needs some changes made to 8879 in order to be strictly compliant
with SGML.  SGML-ERB members Jon Bosak and Eliot Kimber are
representing the XML effort at this meeting.  If WG8 succeeds in
producing a draft TC by the end of the week, I will copy it to this
list for your information.  This is not something that concerns the
SGML WG yet, but you can imagine that it's demanding a fair amount of
our attention at the moment.

2. The ERB is thrashing out a policy regarding error handling.  We
seem to be converging on a position that doesn't go quite as far as
"halt and catch fire" but comes pretty close to it.  Since I haven't
said much about this, allow me to express a couple of personal
opinions; please put replies, if any, under a new subject line.

<EXCURSUS>

(a) I've been a bit annoyed at times over the past couple of weeks
with the repeated assertions that the major implementors will ignore
standards for error handling, so please indulge this brief outburst:
IT'S THE MAJOR IMPLEMENTORS WHO ARE ASKING US TO DO THIS.  Got that?
Good.

(b) You can't specify standard error recovery without ipso facto
making the recovery behavior an implicit extension to the language.
If an application can recover from an omitted end tag, for example,
then you have just made omitted end tags part of the language spec.
The HTML experience over the last few years has proven this point
beyond any doubt (and is one of the key reasons that we are being
asked by the Big Guys to take a hard line on error handling).

(c) Some people who understand the necessity for a compiler to refuse
to produce an executable from broken code seem to think that it's
perfectly OK for a document processor to pass over bad spots in a
document and carry on.  Maybe you have to be part of a group that
produces support documentation for hardware and software that really,
truly does run nuclear power stations and air traffic control systems
to understand this, but take it from me that it is *not* acceptable
for pieces of language to silently disappear from documents or appear
in ways that could be misinterpreted by the user.

People who insist that there is a customer requirement for "forgiving"
document applications overlook the fact that we already have those:
they are called HTML browsers.  The text/html media type or .htm(l)
file extension says "I don't know (or don't care) exactly what I'm
doing, this could be anything, do the best you can with it."  Fine.
We all know that this is the behavior to be expected from HTML.  The
text/xml media type or .xml file extension (or embedded XML tag in an
HTML document, if that ever happens) says "I really do know what I'm
doing here, I'm serious about this, I'm not kidding, I mean exactly
what I say, please treat this the way that you would treat a program
and don't do me any favors by pretending that my errors aren't there."

XML is a power tool.  It's not for beginners.  It is perfectly
consistent with its market positioning to require a different set of
error-handling behaviors from XML processors.

</EXCURSUS>

3. Another issue currently pending is how to handle simple stylesheet
linking.  The ERB decided a couple of weeks ago (and I apologize for
failing to report this in a timely manner) to separate simple
stylesheet linking -- apply this stylesheet to this document -- from
complex linking of a document with various resources (in the non-Web
sense) needed for processing.  We tentatively arrived at a decision to
use James Clark's PI method for the simple case (it works, it's easy
to understand, it's easy to implement) and something like SGML Open
catalogs for the complex case, the exact mechanism to be decided
later.

Since then, however, several people, including one member of the ERB,
have expressed a desire to use hypertext links for the simple case,
and the W3C has given me an action to check with the w3c-sig group to
see whether something that they call "manifests" are, in fact, just
what we need for the complex case.  So the simple case is on the ERB
agenda (I think that partisans of the linking method have already made
their case on this list, but feel free to post more if you have
something new to add), and the complex case is in the background
pending further research into possibly related parallel efforts.

4. Immediately after we finish deciding the error-handling question
and the simple stylesheet-linking question, we are going to resolve a
long list of items relating to xml-link.  The xml-link editors (Tim
Bray and Steve DeRose) have already accumulated a number of items from
various sources, most of them from messages posted to this list, but
everyone needs to review the current xml-link spec over the next
couple of weeks.  This is what I was trying to direct your attention
to in my previous message.

(On the subject of error reports, by the way, please don't take
silence as an indication that your message has been ignored.  Not a
sparrow falls in the grove that fails to be duly noted by our draft
editors.)

I would ask you all to please concentrate on xml-link right now,
because whatever gets published on July 1 will be what people begin to
implement, despite the completely provisional official status of the
draft.  We also need to hear about editorial corrections (*not*
requests for enhancement) that need to be made to xml-lang, which is
also due for a fresh version on July 1.  If you have nothing useful to
contribute to the task of finishing up (not adding to) xml-lang and
xml-link, it's OK not to post anything to the list!  There are at
least two other forums (xml-dev and comp.text.sgml) where you can talk
about XML subjects that are not specifically related to finishing up
xml-lang and xml-link.

In addition to xml-style (aka dsssl-o), things that we *know* that we
will be talking about after July 1 include:

  - strong data typing
  - data declaration facilities beyond the DTD
  - linkage to behaviors
  - multiple name spaces

Feel free to say whatever you want about these subjects, but please
keep the debate off this list until we have the next xml-lang and
xml-link drafts out of the way.

Jon

Received on Tuesday, 6 May 1997 18:26:31 UTC