[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] 1.3 Issue: Use Full CALS Table/DocBook CALS Tables
> -----Original Message----- > From: ekimber [mailto:ekimber@reallysi.com] > Sent: Monday, 2009 September 14 10:47 > To: dita > Subject: [dita] 1.3 Issue: Use Full CALS Table/DocBook CALS Tables > > One limitation in DITA through 1.2 is the use of OASIS interchange > tables, > rather than full CALS tables, which imposes a number of constraints, > not > least of which is the lack of any formally-defined table footer. > > For 1.3 I would like to consider, and will likely formally propose, > that > DITA upgrade its tables to full CALS, probably as used in DocBook, > ideally including the DocBook-specific formatting PIs. > > More research will be required to determine what the most appropriate > solution is, but we definitely need to upgrade the table functionality. I agree we can discuss this for 1.3, but while I'm thinking of it, let me archive a few thoughts. Adding the tfoot element does add functionality (though many people mistake a table footer for a place to put footnotes or end-of-table caption/legend sorts of things which is not its purpose--the tfoot is for column feet, just like thead is for column heads, and over the 24 years since the OASIS Exchange Table Model became a standard, I have not really found a lot of user requirement for this), but there are other parts of the CALS table model that only add complications. For example, I would not want to add CALS' spanspec element to the model, as almost the same functionality is already available using the namest and nameend attributes to span cells, and spanspec is a complicated and confusing thing to use (and implement properly). I would also question whether we want to add CALS' entrytbl element. There were good reasons the OASIS table model subset of CALS was developed, and there was a lot of discussion of user requirements at the time, so I would not want to accept the full CALS model without some careful consideration of the need for each addition. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]