Re: [dita] Some thoughts about tables...

[Don Day <dond@us.ibm.com>]

"Larsen, Seraphim L" <seraphim.l.larsen@intel.com> wrote on 09/07/2004 11:22:22 AM:

> If you have regularly repeating relationships that you are using all
> the time, then you can encode this as a set of data, and later
> render it as a table.  In DITA, I suppose you could encode this as a
> specialized topic, and then you would typically output it as a
> table, although you could also output it in different formats as
> well.  For example --
>
> Address book / contact information (name, address, phone numbers)
> Historical stock market price data (stock name, symbol, open, high,
> low, close)
> Parametric data for electronic components (parameter name, symbol,
> minimum value, typical value, maximum value)
> Any other set of regular data that could typically appear in your documents.

Unless your information structures require a larger base upon which to specialize, these particular examples are all good candidates for specializing from DITA's simpletable element, which in principle is simply a spreadsheet or relational matrix for regularly-ordered data.  The elementref demo in the dita13 toolkit is a good example--the attribute list for elements is based on simpletable, with each row representing a particular attribute, and each cell representing a particular property of the attribute.  The choicetable in DITA's task dtd is another good example.

On a whim, I tried exporting the DITA TC's membership roster as a CSV file, where I did a few global changes to convert the significant commas into <stentry> start/end pairs and to wrap each line as an <strow>, and dropped the content into a new simpletable in an editor with no problem.

Besides reuse, I think manipulation is another unique role for the simpletable.  Like a spreadsheet, the content in a simpletable lends itself to alternative views, such as hiding columns, sorting views by row or column, or presenting a column or row at a time via search or a slide control in a DHTML UI.

> For this type of thing, you don't need to encode it as a table in
> your XML.  You create a specialization for this kind of information,
> and it goes into your DTD, i.e. your local version of DITA.  You
> encode the info using the DTD's tags that indicate the kind of
> information it is.  You later can render it as a table, since that's
> often the best way to present this kind of thing.  Since you know
> what the information is, and what it normally "looks like", you can
> define the table column widths and so on ahead of time, as part of
> your XSLT, which also gives you uniformity in presentation across
> all your documents.

Yes, this also is workable.  For example, information stored in a specialized definition list can be transformed easily into a two-column table for presentation, which then allows presentational control over the behavior of flows within the cells (right-aligned terms, justified definitions, etc.).

> If you have a unique block of information, whose structure is unique
> or unusual and would be hard to reuse, this is when you would need
> to use a table, actually encoded as a CALS table with rows and
> columns and so on, and created using a WYSIWYG table editor.  It is
> only in these situations where you need all those special attributes
> and controls (@scale).  Because of the nature of the business of
> technical writing, this kind of thing happens all the time, so you
> really need to have a way to do this.

And not only in technical writing, given the non-linear nature of human discourse. I can imagine someone using complex tables as an organizational device for a short story. Script-writing software is distinctly modeled upon tables for layout and sequence. Tables are implicitly the poor-man's grid system for newsletters and portals. Some of these cases might actually be able to make use of particular specializations of the Exchange table to fix certain properties of the rendered table in editors and output.

Jon Bosak once made available the Shakespeare plays in XML markup, along with a DTD and XSLT transforms that were heavily based on tables for presentation, so it should be possible, in theory, to map most of that DTD's structures to the Exchange table and to fix some of the presentational cues into the column setup and entry attributes, and thereby provide quite literal in-editor rendering of the intended result view.

Regards,
--
Don Day <dond@us.ibm.com>
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
11501 Burnet Rd., MS 9037D018, Austin TX 78758
Ph. 512-838-8550 (T/L 678-8550)

"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot