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, Robert and Paul:

Good catch and analysis.

Option 1 (requiring the empty cells) would invalidate topic instances that are valid for DITA 1.0 and isn't optimal for authors.

Option 2 (defaulting a colnum attribute in <stentry> specializations) has a minor hiccup -- what if we had a properties table with only <proptype> and <propdesc> columns (a common case)? We'd want to format it as a two-column table instead of inserting an empty column for <propvalue>. So, the processing would need to treat the colnum as a column identifier with a pre-defined sequence with respect to the other column identifiers rather than as an actual column assignment.

If that behavior would be confusing to authors and designers, we could modify Option 2 to provide a colname attribute on <stentry> and a colnames attribute on <simpletable> that lists the allowed colnames in order. Either way, if the row allowed a choice of specialized <stentry> elements in the column, the specialized elements could share the same column identifer.

Option 3 (aligning cells in columns based on the most specialized class) has the strong appeal of processing based on semantics, but I can't think of a way to meet Robert's objections without requiring processors to match row instances against the row content model.

We should steer clear of custom generalization code. Currently, people can exchange normalized content and generalize as needed. It would be unfortunate if people sometimes had to send along custom generalization code. (Hmmm. Unless the generalization code could be normalized with the content?)


Other thoughts?


Erik Hennum
ehennum@us.ibm.com


Inactive hide details for Robert D Anderson/Rochester/IBM@IBMUSRobert D Anderson/Rochester/IBM@IBMUS


          Robert D Anderson/Rochester/IBM@IBMUS

          01/05/2006 12:19 PM


To

dita@lists.oasis-open.org

cc


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"                                                
            <paul.prescod@bla                                            
            stradius.com>                                              To
                                      "Paul Prescod"                      
            12/29/2005 02:42          <paul.prescod@blastradius.com>,    
            PM                        <dita@lists.oasis-open.org>        
                                                                       cc
                                                                         
                                                                  Subject
                                      RE: [dita] Simple table            
                                      specializations (e.g. property      
                                      tables)                            
                                                                         
                                                                         
                                                                         
                                                                         
                                                                         
                                                                         




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
>



GIF image



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