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


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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

Subject: RE: [dita] HTML vs CALS tables so far

Title: Message
Erik, thanks for the useful summary.
In terms of the two table models/single vocab. suggestion, an HTML element called "htmltable" could still be rendered as a table in Author.  Some standard built-in functions such as "Insert Row", "Delete Column" currently recognize the HTML/CALS ( including Exchange ) tags and haven't been designed to use the "html" prefix.    Do other CMS/Authoring tools support "htmltable" tags without losing any existing functionality?  And would this type of prefixing satisfy our HTML advocates?
Looking forward to tomorrow's meeting,
YAS ETESSAM Consultant, XMetaL
BLAST RADIUS XMetaL http://www.xmetal.com

This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please notify me by replying to this message and permanently delete the original and any copy of this e-mail and any printout thereof.

-----Original Message-----
From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Monday, August 09, 2004 4:20 PM
To: DITA TC list
Subject: [dita] HTML vs CALS tables so far

Esteemed TC:

I know we'd all like to reach closure on the table issue, so I'd like to try to summarize the discussion thus far in preparation for the meeting tomorrow. (Please correct any misrepresentations.)

** Debbie and others indicate that HTML table is the current and future direction for their clients.

** Paul and others raise the issue that CALS table has the control needed for print and is widely used by existing content providers.

** For DocBook, Paul combined both HTML and CALS table within a single model and advises against that approach.

I'd also like to raise some questions in hopes that they'll help with weighing the alternatives:

** If your first choice is one of the options, is your second choice the other option or both options?

** Could our statement of direction be that we expect to deprecate the CALS option after the HTML option adds equivalent print control?

** Could we reduce complexity by using distinct elements for each table model instead of having a single table model that covers both variants? For instance, where elements have the same name in both models, we might add an HTML prefix for now (as in htmltable and htmltgroup) and use namespace prefixes in the future once we have a coherent story for namespaces and specialization.

** Does the CALS exchange model have enough benefits to justify migrating current DITA adopters from the existing CALS model? Especially if we deprecate CALS to some extent in favor of HTML.

Finally, a key question: will tool vendors (such as editor and content management system suppliers) have trouble supporting two table models in one vocabulary?

Hoping that's useful,

Erik Hennum

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