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: dita table model

At last week's telcon, during the discussion of what table model
to use in DITA, it was suggested that forcing users to use
a particular table model will discourage users who are already 
standardized on a different model.

DITA is a DTD, so right off we are constraining users by defining 
a vocabulary they must use.  DITA goes to greater extents than 
most other vocabularies to provide a controlled way to extend 
the vocabulary, but within fairly limited bounds that ensure the 
benefits of a known vocabulary are not entirely lost.

DITA's extension mechanism maintains most of the benefits of
a known vocabulary by ensuring that the XSLT already written
for the known vocabulary will work for newly defined tags.

Doing something like this for disparate table models would be
very difficult.  Not only is writing XSLT for table models
among the most complex part of stylesheets, but table models
can differ from each other more drastically (structurally
and architecturally speaking) than different flavors of topics 
and procedures and steps do.

I think it would be putting too much of a burden on the DITA
processing code to have to deal with different table models.
Conversion from one model to another--if necessary for legacy
documents--could be managed by table editors or other code to
produce DITA-compliant tables.

Allowing different users to use different table models in DITA 
would mean in practice that those users could never share their
information in a practical way.  Since DITA is about reuse, I 
think this would be a poor direction to go.

If someone is coming to DITA from somewhere else, they have to
learn a new DTD.  Part of that might be learning a new table
model (though, in fact, the great majority of the markup out
there already uses either the CALS/Exchange table or HTML).
The OASIS Exchange model has the greatest tool support, so 
using it would make it most likely that a user would never 
have to be concerned with the details of the table markup.


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