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

Hi Paul,

I suspect that what you're looking for is not in the spec (sometimes I
wonder, are any of your questions ever answered in the spec?), but I
haven't looked to be sure.

This gets in to one point about specializations, which is that some of them
really require processing overrides to get good output. In cases like that,
I tend to think that there are two options. One is to keep the class
attributes when generalizing, and keep the processing override. The second
is to have a migration as part of your generalization -- in the case of
property tables, it would add empty cells as needed.

For the suggested changes to the spec:
1. If we disallow optional cells, then we limit further specialization, or
make it more awkward. For example, if we require all three cells in a
property row, then a specialization of reference using only two of the
columns will still have a required empty column.

2. Adding a colnum attribute edges us closer to the CALS/Exchange tables,
which decreases the simplicity of the simpletable... but otherwise doesn't
seem to be a problem.

3. If we require that each column have a unique type/name/class value, then
it means we cannot have rows like this one:
( name, street, (stateName | provinceName), postalcode?)

In that case, the <stateName> and <provinceName> elements would need to
line up in the same column, even though they do not have the same type. I
do not know of any specializations like this today, but they are possible.

I think I'd be tempted to say this:
If you specialize a table in a way that implies empty cells, you have three
options. First, you can require that your specialized processing stay with
the files, even when the files are generalized. Second, you can provide a
generalization/migration routine that allows you to fall back without
breaking the content. Otherwise, you should consider requiring each cell to
appear in each row, even if some of those cells may be empty.

Alternatively, we could say:
By default, processing should line up any unique simpletable entry in its
own column. [insert details on how to tell which comes first when 2 rows
each have a unique entry. Insert specific details on how to tell if an
entry is unique -- would <proptype> be allowed in the same column as a
specialized proptype?] If multiple elements can use the same column, then
you must provide special processing. [Insert any best practices on
overriding generalization, when removing class attributes].

In the second alternative, the state/province example would still require
users to do something for good fallback or generalization, but it would fix
tables that use the <properties> model. Any thoughts?

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit

             "Paul Prescod"                                                
             stradius.com>                                              To 
                                       "Paul Prescod"                      
             12/29/2005 02:42          <paul.prescod@blastradius.com>,     
             PM                        <dita@lists.oasis-open.org>         
                                       RE: [dita] Simple table             
                                       specializations (e.g. property      

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

> -----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

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