Re: [dita] table models [was: Meeting Minutes 7/20/04 -- DITA Technical Committee]

[Paul Grosso <pgrosso@arbortext.com>]

At 14:32 2004-07-21 -0500, Don Day wrote:

>Paul Grosso <pgrosso@arbortext.com> wrote on 07/21/2004 01:32:31 PM:
>
>> HTML table rules are more limited than CALS.  The table tag has a frame
>> and rules attribute, but you cannot turn rules on and off at the row
>> or cell level.
>> 
>> HTML tables are also restricted in column width specifications to just
>> unitless integers (implying pixels) or percentages.
>> 
>> The CALS model doesn't have markup to specify cell background shading color.
>> 
>> I think that's most of the non-trivial capability differences.  Given that,
>> I'd say the CALS model still has the capability advantage.
>
>What I get from this, however, is that this presentational advantage is only possible for printed format;

But that is still an important advantage, no?  People are used to 
"reduced capability results" in HTML, but that doesn't mean they
want lowest common denominator for their print/pdf output.

> when you output your CALS content using those features to HTML, the carefully crafted point measures and rules get down-converted to whatever HTML can support anyway. 

If your conversion is willing to use CSS styling, you can get HTML
output that reflects the input more closely than you can sticking
just to HTML tagging of tables (e.g., you can get rules and in some
versions of some browsers get the widths too).

> Perhaps the question is not about greatest potential for authoring, but rather about greatest popularity for rendering.

Isn't this, though, just the opposite of what you say below about 
focusing on content rather than appearance?

>  In that respect, going to the HTML model as source means that PDF loses out on the ability to support those rules and close column control. In a production environment trying to keep authors focused on content rather than appearance, perhaps thats not such a bad tradeoff?

I'm a fan of content over appearance, but users usually aren't.  

I fear folks will say they just have to be able to turn on or off
this rule or that or their table just doesn't work.  I'd hate to
pick a table model that requires loss of information from much
legacy data and then have people say that they just can't use
DITA because of it.


>> I agree.  (My most favorite model and the most capable of major models out
>> there today is the XSL-FO one!)
>
>Every real writer I know secretly desires to code raw fo:-namespaced table markup by hand. ;-)  It's the only way to fly, man.

There's no reason table editors couldn't support the XSL FO table model.
But, I admit, few do at the present.

paul