Home | Business News | Browse by Publication | X | XML Journal

The trouble with tables: they''re trickier than they seem. (Content Management).

Article Excerpt
When the content of an XML document is intended for human eyes, rather than software digestion, it's necessary to consider the possible limitations of rendering applications, including typesetting systems, DTP packages, and on-screen document presentation tools such as Web browsers. Simple text structures, like headings, paragraphs, and list items can be presented easily enough, but intricate structures, such as chemical and multilane mathematical formulas, are so difficult to render that they're often preprocessed into images. Between these extremes we have tabular structures.

The trouble with tables is that they are too common and straightforward to be treated as images, yet they are often sufficiently complex to cause problems for rendering applications. Standard table models can help, and two such models are discussed in this article, though their more advanced features must be used cautiously. Semantic markup with dynamic conversion to tabular structures is another possible approach.

Complex Tables

A table is complex, and potentially causes problems for rendering applications, if it:

* Lacks column width information

* Includes columns of text that are vertically aligned on a specific character

* Includes cells that occupy more than one grid location

* Has complex cell content, possibly including embedded tables

* Includes repeatable header and footnote rows

* Includes border lines

Figure 1 shows a complex table as it might be presented to the document author in a sophisticated XML authoring package (note that such visual feedback helps authors avoid making mistakes). Figure 2 shows how this table might be formatted when the document it is contained within is presented on paper. All of the complexity factors listed above are demonstrated (with the exception of complex cell content), in part because the table happens to be split across two pages.

Complex Table Tagging

A table is theoretically simple enough, being merely a series of rows and columns that intersect to create cells, and XML elements can be employed to create this structure. Any number of strategies are plausible and, at first sight, the most significant decision when creating an XML table model (as part of a DTD or schema) is whether tables should be built row-by-row or column-by-column (in fact, the former approach is usually taken, and is the basis of the two standards discussed later):

... ... ... ...

XML tagging can also express the complexities listed above without difficulty. Typically, attributes are used to specify column widths; the presence and style of border lines; alignment of text within a cell; and the size of a cell that occupies adjacent cell spaces (a "straddling" cell). Element hierarchies can describe tables and other structures within a cell, and elements are also typically used to identify header and footnote rows. But simply adding elements and attributes to the table model in order to permit such complexities to be introduced does nothing to help with the rendering task (quite the reverse). Each of the problem areas listed provides a unique set of difficulties for any rendering application.

Column Widths

The first problem a document instance author might encounter when creating a table is the need to decide how wide to make each column, and there are several strategies to consider.

From the author's point of view, the simplest thing to do is to ignore the issue, and not bother to specify any column widths. The rendering application then has to decide...

View this article FREE - Now for a Limited Time, try Goliath Business News
Free for 3 Days!