| The idea of negotiation got discussed at the IETF meeting last March.
| People considered it very messy, making it too hard to write Web pages.
| For example, if there were eight variants of available features, you
| might have to generate 2^8 different flavors of a page.
|
| The consensus seemed to be thus:
| 1) Work on extensions independently: tables, math, etc.
| 2) As extensions get approved, assign the next higher number.
| 3) New versions of HTML comprise all the previously approved extensions,
| plus the latest one.
| 4) At some point an HTML 3.0 will be specified that incorporates the
| previously (separately) approved extensions.
|
| So, if tables are approved first, then math, HTML 2.1 would support
| tables, and HTML 2.2 would support both. If math got approved first,
| 2.1 would support math, 2.2, both.
|
| The scheme is simple. You always know a given version supports all the
| preceding extensions.
That exactly sums up the decision that was arrived at in March and is
my understanding of the rules under which we are currently proceeding.
[Bert Bos:]
| - I didn't ignore the results of the conversation, I just don't think
| there were many results. Before he went off-line Dave Raggett
| proposed a series of alternatives, none of which seemed to satisfy
| many people. I tried to measure how much people agreed with each of
| the alternatives, but got no response.
This is not my understanding of the situation at all. Dave originally
proposed a table model for 3.0. This received a *great* deal of
discussion and some vital input from the table experts at SGML Open,
culminating in a pivotal meeting at Danvers that achieved buy-in from
everyone involved and brought the model to a new level of
functionality. Dave presented the new model during developer's day at
the WWW meeting in Darmstadt. He then refined the model further and
published it to this list just before he went offline to arrange his
move to Boston. I think that the relative silence since then has been
out of respect for Dave's temporary absence from the list rather than
any fundamental disagreement with the table model. The draft as it
stands represents some very hard work and a lot of consensus-building.
To substitute a different model now would amount to setting this
effort back a year. I am very much opposed to this.
Subsetting that model, however, is a different question. One of the
important things that the current draft table model achieves is
backward compatibility with minimal implementations of the old model.
By "minimal implementations" I mean ones that simply identify rows and
cells without using spans or setting column widths, relying entirely
on the Web client to "do the right thing". Such implementations will
suffice for the great majority of simple real-world tables and work
quite well with current Netscape and Mosaic browsers. (See the tables
served out by the Novell Publications Server at
http://occam.sjf.novell.com:8080 for examples.) I could easily
envision the quick addition of minimal tables for 2.1 if we felt it
important to standardize this basic functionality. But the full table
model as it currently stands in Dave's latest draft of the fragment is
in my opinion fundamentally sound, and we should implement nothing
that could possibly be incompatible with it while we are working out
the last details of its specification.
Jon
========================================================================
Jon Bosak, Novell Corporate Publishing Services jb@novell.com
2180 Fortune Drive, San Jose, CA 95131 Fax: 408 577 5020
A sponsor of the Davenport Group (ftp://ftp.ora.com/pub/davenport/)
------------------------------------------------------------------------
The Library is a sphere whose consummate center is any hexagon, and
whose circumference is inaccessible. -- Jorge Luis Borges
========================================================================