Comparison of current DITA and Exchange table models

[Don Day <dond@us.ibm.com>]

To help the DITA TC in assessing the impact of selecting between the current full DITA table model based on full CALS and the OASIS Exchange table model, I asked one of IBM's DITA tool developers to look into the practical differences and consequent migration hits between the two DTDs. For the Exchange definition, we specifically referred to this resource: http://www.oasis-open.org/specs/tm9901.html .

His reply follows between the "=====" separators. He refers often to IBMIDDoc, an SGML DTD from which much of IBM's current DITA content has been migrated. This migrated content tends to have most of the unique characteristics of the full CALS table model; DITA tables created afresh per the current DTDs tend to have slightly different issues with going to the Exchange model. I added a few editorial comments [within square brackets].

======================================
Let's see... I'll come up with migration hits as I scan the definition.

I would say that we cannot migrate to any model that leaves off table's @rowheader attribute, unless it provides another way to do the same thing. We added that to meet accessibility requirements, and I don't see how we could justify taking away that ability now.

* As you mentioned, the new model would get rid of tfoot. That's probably not too heavily used in DITA, but I'm pretty sure I've seen it used, at least in IBMIDDoc.

* Getting rid of spanspec would be a hit, though most topics authored in DITA would not see it because [the current table insertion macro] automatically uses namest/nameend. Documents that have migrated from IBMIDDoc would hit it more often.

* They get rid of @char and @charoff on tgroup. We've already done this in moving from IBMIDDoc to DITA, so should not be a problem (unless that was a mistake on our part).

* [On the other hand, ] Their colspec allows char/charoff, but ours does not (just a difference, not a migration hit)

* The model has a "normative statement" to forbid tables within tables. I don't know if people have tried this yet in DITA (we allow it), but I know it is forbidden in IBMIDDoc, so it should not be much of an issue [that is, for IBM's content migrated from IBMIDDoc, which disallowed nesting].

* The table starts with an optional title. Would the TC be willing to add <desc> to that? If not, this would be a migration hit -- I'm not sure where the desc would go, and a lot of groups use it.

* Coming from IBMIDDoc to DITA, we switched from @pgwide to @expanse. Looks like they go back to @pgwide with a numeric value, so we'd have to move back.

* While checking content models, I saw that we allow <colspec> to start both <thead> and <tfoot>. Surely this is a bug on our part?

* To match our [DITA-enriched] model, [the Exchange] table would need to add %univ-atts;, (%select-atts; + %id-atts; + @translate + @xml:lang), %global-atts; (@xtrf + @xtrc), and @class, as well as the @rowheader attribute and @scale. Tgroup, thead, tbody, and row would also need the %univ-atts;, %global-atts;, and @class values; entry would need %global-atts; and @class. [In addition, the DITA-unique <desc> element would need to be added in; this element enables more consistent presentation of both figures and tables.]

The rowheader thing seems the biggest catch. There's no way to use it [in an unenhanced Exchange DTD], with or without an automatic migration.

Ignoring the rowheader issue: a lot of groups would have to do some sort of migration, especially groups that have migrated from IBMIDDoc. The changes would not be very significant, but regardless of the difficulty, I think there would have to be a program to update the files. Most large groups would have to run the program just to catch the few files that have problems.
======================================


Regards,
--
Don Day <dond@us.ibm.com>
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
11501 Burnet Rd., MS 9037D018, Austin TX 78758
Ph. 512-838-8550 (T/L 678-8550)

"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot