[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. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]