OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: DOCBOOK: Exchange or Full CALS Table Model?

At 18:52 2002 12 26 -0500, Norman Walsh wrote:
>Years ago, the DocBook TC decided that in DocBook V5, the Exchange
>Table Model[1] rather than full CALS[2] would be supported. This
>decision was made at a time when there were several competing
>authoring applications that purported to support a subset of CALS. The
>Exchange Table Model was developed to document the subset that nearly
>all the vendors supported.
>It's been a long time since I heard anyone discussing CALS support as
>a distinguishing criterion between applications. Certainly, I can't
>remember anyone asking about it in years.
>I now wonder if there's any value to be had from adopting the exchange
>model. AFAICT, it would introduce backwards incompatibilities, remove
>some features that people probably use (like spanspec),
>and provide no obvious benefits. 

The two biggest benefits of the Exchange model were (1) agreed upon
interoperable semantics (which the CALS table model didn't have at
the time) and (2) interoperable tool support.

As far as semantics, SGML Open did finally provide definitive semantics 
for the CALS model [3] that one can now follow.

>On the flip side, I think the XSL stylesheets only
>really support the exchange model (just because I was being forward
>looking for XML, not because I think the full model can't be
>supported), and few people have complained.

Actually, they do support tfoot which is not in the Exchange model.

>Does anyone feel strongly that the exchange model is the way to go?
>That full CALS is the way to go?

I don't see any need for spanspec.  Support for spanspec would
be a pain; though perhaps doable by someone like Norm or Bob, I
don't see the point.

The Exchange model also doesn't have tfoot.  Personally, I've never 
been a fan of tfoot (most people mistakenly think it has something 
to do with table footnotes which it doesn't--it allows for a 
"thead-like" thing at the bottom of a table, and I've almost never 
seen such a thing in practice), but the HTML table model and the 
XSL FO table model do both include tfoot.

The Exchange model is a subset of CALS, so the differences are
things in the CALS model not in the Exchange model.  It might 
be helpful to outline the key omissions from the Echange model.
Here's my attempt (I've omitted things that aren't really 

1.  tfoot
2.  spanspec (another way in addition to namest/nameend to indicate
    column spanning as well as another place to put column-level
    alignment and ruling information)
3.  colspec* within thead and tfoot (i.e., allowing the thead
    and/or tfoot to have completely different column configurations)
4.  entrytbl (i.e., the ability to have a table nested within a
    table cell)

There are also some more attributes allowed in various places in
the CALS model, but none of them are really table-related.  (They
include things like rotation, ToC entries, and tabstyle attributes.)

The DocBook XSL stylesheets have supported tfoot for a while now.

I personally see no point to adding spanspec support (though I wouldn't
spend energy opposing it if others felt it important).

I personally see no point in allowing colspec* in thead/tfoot.  I've
just never seen the need.

Nested tables is probably going to be the big question.  HTML and
XSL-FO both allow them.  Few CALS table authoring tools support them.
It might be "nice" to support nested tables, but I have to wonder in
practice if they are really needed--since DocBook has existed happily
for this long without them.  I'm not sure what I think here.


>[1] http://oasis-open.org/specs/tr9503.html
>[2] http://oasis-open.org/specs/a502.htm

[3] http://oasis-open.org/specs/tm9502.html

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC