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


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


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