XHTML vs. CALS tables

[Jeff Beal <jeff.beal@ansys.com>]

I already regret writing this message, but I can't help myself.  I wasn't
subscribed to the list until just now (subscribed to enter the fray, so to
speak), but I have read the entire archives of this month related to the
issue of XHTML and CALS table models.  It's been an intriguing discussion,
to say the least.  However, I have yet to hear a really convincing argument
from the XHTML camp as to why we want to.  Their only claim is that it will
be easier for users to understand, but they have yet to detail the areas
where it is easier.  Jirka summarized how he explains the differences, and I
didn't see anybody refute his claims: 
"1. Use row instead of tr
2. Use entry instead of th/td
3. Surround tbody with tgroup and add number of columns here
4. Do colspans in different (and btw more robust) way then in HTML" [Jirka
Kosek: Wed, 19 Mar 2003]

That's not a lot to learn.  So, again I ask, how are HTML tables easier to
learn than CALS tables?  Where is the learning curve?  Other than tag names
and spanning, what are the differences between the HTML table model and the
CALS table model?

I'm not entirely decided on my stance on this issue yet.  I do think that if
we decide to accept the XHTML model, we need to use only the Strict model.
There's too much bad voodoo associated with the Transitional model.  As
somebody else pointed out, if the W3C is deprecating attributes, we should
not be adopting them into our DTD.  They are trying to get XHTML to a
pure-semantic place and we're already there.  Adopting the Transitional DTD
would be a very bad idea.

There are a few things along this thread that nobody has mentioned yet,
chief among them the difference between the HTML 3.2 model and the HTML 4.0
model.  When I think of the "HTML table model", I instinctively think of the
HTML 3.2 model, which was <!ELEMENT table (caption?,tr+)>.  Note the
complete absence of col, colgroup, thead, tbody, and tfoot.  HTML 4.0 added
the model proposed by RFC 1942, which is, interestingly, very similar to the
CALS model, with the exception that it is backwards compatible to the HTML
3.2 model.

If we do adopt the HTML table model, we need to seriously consider whether
or not we will include backwards compatibility to an almost useless table
model.  If we don't include backwards compatibility to HTML 3.2 tables, are
we really changing to the HTML table model, or are we just changing a few
names (to less meaningful names), as Jirka suggests?  If we do include
backwards compatibility to HTML 3.2, how will our tools handle the
transformation to XSL-FO?  

That said, there is one feature of HTML tables that the CALS table model
does not include: being able to specifically associate cells with their
headers, whether those headers are column headers, row headers, or even
header cells at arbitrary locations in the table.  (see
http://www.w3.org/TR/html4/struct/tables.html#h-11.4)  This is, in my
opinion, a potentially very powerful feature, especially where accessibility
and data retrieval are concerned.  However, I think we could just as easily
integrate this functionality to the current DocBook table model, without any
backwards-incompatibility issues.

Again, my mind really isn't made up at all.  I do think that restricting the
usage of the HTML 3.2 table model is a good idea.  I also think that adding
the scope/header/axis attributes is a good idea.  Just a few more things to
add to the fire...


Jeff Beal
Tools Specialist
ANSYS, Inc.
(724) 514-3150