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: table models [was: Meeting Minutes 7/20/04 -- DITA Technical Committee]

At 09:50 2004-07-21 -0700, Larsen, Seraphim L wrote:
>Meeting Minutes 7/20/2004 -- DITA Technical Committee 

>        - Which version of CALS table model? 
>            - Debbie -- The differences in functionality between
>              HTML and CALS are negligible -- HTML used to be a lot
>              less powerful but is now comparable. 

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.

>            - Seraphim -- If we support both table models, at least
>              there will be interoperability between DITA users who
>              share the same table model, rather than some people
>              avoiding DITA altogether simply because they don't
>              like the table model. And perhaps we can develop
>              methods for converting between table models. 

One can try to support both models in one DTD.  DocBook is doing that.
It's a bit messy (without using fancier schema languages, the DTD has
to allow some combinations that wouldn't be valid tables), but it does
work to allow both CALS and HTML tables in the same document.

I'm not sure this would be my first choice of a solution, but if we can
come up with convincing arguments that it's important to allow use of
both CALS and HTML tables without initial conversion (I'm not convinced
yet), it can be done.

>            - Mary -- You are going to have a conversion issue, no
>              matter what. She doesn't see the value in adding
>              a transformation to the table piece. (?) The longer we
>              keep the legacy around, the more difficult it will be
>              in the future. 
>            - Seraphim -- Best decision in the long run would
>              probably be to choose the best model and not worry so
>              much about the conversion of legacy documentation (as
>              difficult as that may be!) 

I agree.  (My most favorite model and the most capable of major models out
there today is the XSL-FO one!)

>            - Don -- This obviously cannot be closed today. 
>            - Don -- What is the impact on those with legacy content
>              of moving from the CALS model to the HTML model? Can
>              someone investigate this? 

See above.   You lose some ruling capabilities and most column width specs,
but the conversion is mostly doable.  Whether the users will be happy with
the results is another question.


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