Re: [dita] Which CALS Table model should we specify?

[Paul Grosso <pgrosso@arbortext.com>]

At 15:58 2004-06-28 -0500, Don Day wrote:

>DITA currently borrows its table definition from the OASIS CALS table definition, mostly a subset (more restricted attribute value choices) of the Exchange Table Model. This model was designed for highest interoperability among vendors known to have CALS table support in the 1995 timeframe. 
>
>Has anything changed since then? Should DITA use the full CALS Table Model (<http://www.oasis-open.org/specs/a502.htm>http://www.oasis-open.org/specs/a502.htm or the interoperable subset, Exchange Table Model (<http://www.oasis-open.org/specs/a503.htm>http://www.oasis-open.org/specs/a503.htm)?

See the latest XML version of the Exchange table model at:
http://www.oasis-open.org/specs/tm9901.html

The most powerful table model around these days is the XSL FO one,
but I doubt most folks would want to edit in that.

Interoperability-wise, I suspect one gets a bit more with the Exchange
table model, but probably only trivially so, as there aren't that many
non-HTML table editing tools out there anyway these days.  There are
some details (the "cruft") of the CALS table model that would be
difficult (but not impossible) to implement in XSLT.  

Unless there is a dire need to footers (and I believe most uses of
table footers are bogus--like trying to fake getting table footnotes),
I think the Exchange Table Model is sufficient and avoids some of
the cruft of the CALS table model.

However, I wouldn't object if other folks felt a strong need for the
CALS table model (as long as I don't have to write the XSLT code to
support spanspecs).

> Do we need to formally change anything about DITA's CALS table definition in the file, tbl_xml.mod?
>
>Note that the DITA-specific content model for this table is based on the parameter entity %tblcell.cnt;, which is defined in the file topic.mod. Also, some DITA attributes were added to the table definition to support conref and conditional processing similar to other topic elements. These augment the base table model by adding DITA behaviors to the base table model, which still has the same features handled by all editors, such as spanning of rows and cells.
>
>Also since 1995, enablement for accessibility has become even more critical. Has anything been done for the CALS table model to allow writers to indicate fully accessible HTML output? 

Nothing has been done to the CALS model since 1995.

>IBM uses special transforms to put some level of accessible functionality into their HTML output;

What sorts of accessibility functionality is there in HTML tables?

> has your company experienced similar issues with your CALS table content being output as either HTML or PDF? 

I didn't even think PDF was accessible.

>Did you solve the problem by extending the source table DTD for authors to manage the necessary level of accessibility, or by adding the accessibility features during transforms (as IBM did), or by other means?

I don't think we've broached this yet, but we are working in the accessibility
area.  I'd be interested to hear more about what kind of accessibility IBM adds
via the transforms.

paul