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: Simple table specializations (e.g. property tables)

Property tables inherit from simple tables, but it seems to me that the
semantics of the two do not line up directly. Consider the following
property table (from the DITA specification):

		<proptypehd>Visual Element</proptypehd>
    <propdesc>depicts anger</propdesc>
    <propdesc>depicts permission</propdesc>

Note that the last row lacks a "proptype".

Now consider the generalization of this:

      <stentry>Visual Element</stentry>
      <stentry>depicts anger</stentry>
    <stentry>depicts permission</stentry>

What tells a formatter working on this content that the stentry should
go in the SECOND column rather than the FIRST column? In fact, the DITA
toolkit puts the word "green" in the first column as does XMetaL DITA
Edition (when working with arbitrary specializations). Is there any
application out there that works otherwise? With arbitrary
specializations of simple tables?

I can think of three solutions to the problem, all requiring changes to
the DITA specification.

1. Simply disallow specializations of simple tables that have optional
cells. Instead, authors should just use empty elements to represent
missing data. This is BY FAR the simplest solution for implementors.

2. Add metadata (probably through fixed attributes) allowing elements to
be aligned. E.g. a "colnum" attribute for each cell.

3. Declare that specializations of simple tables MUST use unique element
type names for columns. Then columns could be aligned by the class

 Paul Prescod

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