Action 037: Impact on legacy content of CALS to HTML table migration

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

   037 Don -- Find someone to investigate the impact on those with
       legacy content of moving from the CALS model to the HTML
       model.

I asked one of IBM's DITA tool developers to comment on this question.  His response covers both tools and user experience considerations (with my interpretations in parentheses):

* It is a big migration hit (especially for content originally migrated to DITA from books with formerly book-oriented CALS tables) -- everyone will have to update topics.

* Confusion for all of our long time users (case of long familiarity with CALS element descriptions, although again we could argue that editors will hide the messy details and that the authoring experience would remain essentially the same)

* Accessibility concerns -- how do we implement rowheader? Do we add it to the HTML table model? (Ah, this is a DITA attribute added to the CALS table markup that allows indication of a column-oriented heading in the first row.  When the table is transformed to HTML, this attribute allows XSLT processing to affix hints for accessible navigation of this row-major orientation of the table.  We'd need to do the same for an XHTML table, and still apply processing to it, since authors should not have to insert accessibility structures.)

* Automatic accessibility: today, as long as users have headers, the transform (IBM's internal version) automatically adds all id/headers attributes, and ensures their validity. If users can do this manually (as with the HTML form of table markup), many of them will; however, most will continue to [let transforms] add values automatically. I do not see a good way to ensure accessibility when users specify their own:

 * Ignore user values? From experience, those who use their own values will be upset at losing them. Also there's the edge case of single-cell headers in the middle of the table, or middle column headers -- they could mark it up on their own, and the process today does not know how to add them.  (To me, this means the TC should look carefully at what other processing implications are caused by HTML tables--in a way, CALS forces the use of transforms, which allows processing to manage out most of the variability authors would otherwise have access to--and abuse!)

 * Use only their values? From experience, some authors will make mistakes, and most do not know all of the rules.

 * Have the editor add it? What happens when they use another editor and do not get values?

 * Find some set of rules for mixing auto values with user values? Any set of rules will be confusing to some or all users.

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