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:]
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
