RE: [dita] Simple table specializations (e.g. property tables)

["Paul Prescod" <paul.prescod@blastradius.com>]

To put this question another way: where in the DITA specification does
it say that simple table specializations with optional cells should
operate in the intuitive fashion where elements are lined up by element
type rather than the way that generalization otherwise works where
specialized element types are ignored except in the presence of
overrides.

> -----Original Message-----
> From: Paul Prescod [mailto:paul.prescod@blastradius.com] 
> Sent: Thursday, December 29, 2005 12:11 PM
> To: dita@lists.oasis-open.org
> Cc: dita-ot-developer@lists.sourceforge.net
> Subject: [dita] 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):
> 
> <properties>
>   <prophead>
> 		<proptypehd>Visual Element</proptypehd>
> 		<propvaluehd>Value</propvaluehd>
> 		<propdeschd>Implication</propdeschd>
>   <property>
>     <proptype>color</proptype>
>     <propvalue>red</propvalue>
>     <propdesc>depicts anger</propdesc>
>   </property>
>   <property>
>     <propvalue>green</propvalue>
>     <propdesc>depicts permission</propdesc>
>   </property>
> </properties>
> 
> Note that the last row lacks a "proptype".
> 
> Now consider the generalization of this:
> 
> <simpletable>
>   <sthead>
>       <stentry>Visual Element</stentry>
>       <stentry>Value</stentry>	
>       <stentry>Implication</stentry>
>   </sthead>
>   <strow>
>       <stentry>color</stentry>
>       <stentry>red</stentry>
>       <stentry>depicts anger</stentry>
>   </strow>
>   <strow>
>     <stentry>green</stentry>
>     <stentry>depicts permission</stentry>
>   </strow>
> </simpletable>
> 
> 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 attribute.
> 
>  Paul Prescod
>