Don's reflections on semantic tables vs CALS-heritage tables

During last week's discussion about tables, I mentioned having some
    background on the rationale between the two table types in DITA and
    how the semantic differences impact specializers. The conclusion of
    this tome is a discussion about column flows requiring a possibly
    different semantic approach than using tables... in the end, the
    dita-user I planned to reply to chose a different solution and this
    discussion became moot, but it is possibly still pertinent for this
    group's understanding of the preferred roles for these table types
    (and why they are poor subs for multi-column layouts.

    -----------------------------------------

    

    You know the mantra that DITA is all about separation of markup from
    presentation, but how does that apply to tables? Tables are semantic
    devices--they are cells that organize the relationships of
    content--not the presentation per se, but the relationships. And in
    DITA, the ability to specialize based on common archetypes has long
    driven the design of all the core elements in a plain DITA topic
    (from which all specialized elements are derived). 

    

    Simpletable, for example, has no spans because it represents
    matrix-oriented data. You could literally query a relational
    database and pour the results into a simpletable for subsequent
    tabular presentation in auto-generated reports or for representation
    as a specialized data model that looks nothing like a table. Nothing
    prevents your using simpletable for simple tabular
    presentation--that's specifically why the DITA originators chose to
    call it "simple table" rather than "semantic table." Yet it aligns
    perfectly with the CSS display:table properties: you could output
    the rows and cells (indeed, any element element specialized from
    those) as divs, associate the right CSS properties to each kind of
    div, and effect a table-like presentation without the use of table
    markup whatsoever. This is extremely important for query-based
    content where authors normally do not have the ability or mandate to
    tweak for presentation--it's more about efficient representation of
    data in structures that are as near as possible to the original data
    model itself. Simpletable just happens to be very easy for authors
    to work with, and its fine as long as these design principles are
    not limitations for your purposes.

    

    But whenever table-based relationships need more specific
    presentational control, there's an app for that: it is the standard
    table format which DITA adapted directly from the older CALS model,
    now called OASIS Exchange Table Model (http://www.oasis-open.org/specs/tablemodels.php),
    also used by DocBook and many other content standards. This set of
    markup was enabled to be specialized as well, although in practice
    most data models tend to map more directly to the semantic table
    elements. But this form of table provides all the standard controls
    for very fine-grained management of the presentation of the content
    of the cells, including borders, spacings, spans, widths of any
    unit, and more.  In short, if presentation matters, this is the kind
    of table your data should be instanced in.

    

    Does that mean that this kind of table can be used to support
    queried data as well? Absolutely. However, it is not likely that
    you'll ever have anything in your data that relates directly (that
    is, in a specializable way) to a colspec element or to the namest
    and nameend attributes that actually manage spans or to the colsep
    and rowsep rule directives--these are purely presentational props
    that, as I mentioned before, rarely have direct counterparts in
    natural data.  For these reasons, I tend to regard standard tables
    more as filters that writers apply to data in order to emphasize a
    particular presentation of it. 

    

    The Exchange Table model normally does not permit changing the
    layout of the data without changing the presentational markup
    encoded in it. That is, to make one column wider, you must adjust
    the value of column widths adjacent to that column; to move a span,
    you must change the location and values in the associated namest and
    nameend attributes.

    

    The simpletable is more dynamic; by using appropriate CSS or XSL
    attribute set assignments, you can greatly change the appearance of
    content in that format, but again, only in a generic way. 

    

    In both cases, to get the appearance of two column layout, you have
    to put specific amounts of content into the cells defining each
    "column." In other words, you must intervene as a composition engine
    in creating the appearance of layout. That is because, as you have
    heard often from the HTML world, tables are not layout devices. 
    Layout applies to data by element type; tables impose presentation
    to containers that surround data. There is a huge difference here!

    

    For example, to change an HTML topic from single column or galley
    style into a multi-column style, you just reference a stylesheet
    that changes the column-count and column-gap properties on a
    containing div, and on conforming browsers, the content of that div
    will balance itself across the designated number of columns. The
    same attribute values referenced externally also work for
    region-body ranges of content for XSL-FO-based output--it's
    basically that simple to change the layout of either HTML divisions
    or book parts on the fly. This is far different from a table, where
    to add a new column, you must modify a topic directly to
    redistribute the previous content into the new containers.

    

    The 'multiple rows in two columns' requirement seems to point to a
    special data type rather than to a table, meaning that this is
    probably a case of content best managed as a simpletable, but with
    the rules turned off for the nonce by setting the appropriate
    override parameters for that container type. I realize that you have
    some help now with solving this presentation issue with direct
    markup overrides, but the distinction of layout by style vs literal
    containment was not getting out in the right context. For those who
    have been willing to drill through this explanation, I hope it helps
    when it comes to selecting the right content and processing
    architecture for future projects!

    

    

    
-- 

      

        
 Don R. Day 

        
 DITA and XML Consultant, Learning by Wrote

          Co-Chair, OASIS
            DITA Technical Committee 

        

          
"Where is the wisdom we have lost in knowledge?

          
Where is the knowledge we have lost in information?"

          
--T.S. Eliot