Table standards

Industry standards play an important role in defining models for constructs that are difficult to render on screen or paper, and the most common example of this is tabular matter. Structures like paragraphs, lists and warnings form a simple linear sequence, but table cells are arranged into a two-dimensional grid. An application must recognize the elements that represent column or row boundaries. Other complications include border lines, cells that straddle over adjoining rows and columns, and the various ways in which text can be aligned within each cell.

These typical table features may be described using additional elements or attributes, but if every document model designer adopted a different approach, an application that is required to present the information in a tabular format would have little chance of being able to interpret the markup.

CALS and HTML tables

In the SGML community, recognition of this problem led to the establishment of a de facto standard. From a few competing models, widespread use of applications that supported DTDs developed for the US Department of Defense meant that the CALS table model was the inevitable winner (and was used in the DTD for this book). This table model requires the use of specific elements, including Table, Thead, Tbody, Tfoot, Row and Entry.

This model also influenced the approach taken to add table support to HTML. Introduced in HTML 2.0, this scheme has been extended in later versions, and is now quite similar to the CALS model (see Chapter 23 for details). The HTML model is rapidly becoming the de facto standard. Certainly, this model is retained in XHTML (an XML compatible version of HTML 4.0), and other HTML-derived standards.

Meaningful element names

Although there is nothing to prevent the creation of XML elements that reflect the names of HTML elements, such as Table, Tr (table row), Th (table header) and Td (table data), the freedom to use names that are more meaningful to the content of the cells remains an important XML principle.

For example, when the table contains a list of product codes and prices, the following structure may be deemed more appropriate:

<prices>
  <prod><code>XYZ-15</code><price>987</price></prod>
  <prod><code>XYZ-22</code><price>765</price></prod>
</prices>

In this example, the information is sufficiently well identified for product details to be automatically located and extracted, and it is possible to locate the price of a specific product. The content can also be presented in a number of different ways. Nevertheless, the most obvious presentation format is a tabular structure. Close study of the elements reveals that the Prices element is analogous to the HTML Table element, the Prod element encloses a single row of data, and the Code and Price elements both represent individual cells.

CSS mappings

An application must be informed of the specific significance of each of these elements. This can be achieved using a stylesheet. Fortunately, the CSS specification now includes property values that map an element name to a table part role (see Chapter 25 for full details). The values 'table', 'table-row' and 'table-cell' may be used in the display property:

prices { display:table }
prod   { display:table-row }
code   { display:table-cell }
price  { display:table-cell }

Care should be taken to adopt a row-oriented approach, as shown in the example above, so that the elements can be easily mapped to the HTML model. It is not possible to map elements in a structure that takes a column-oriented approach, as in the example below:

<table>
  <products>
    <code>XYZ-15</code>
    <code>XYZ-22</code>
  </products>
  <prices>
    <price>987</price>
    <price>765</price>
  </prices>
</table>

Note that another reason for avoiding this approach is that it is more likely to separate related items (such as a product code and the price for that product), which complicates analysis and extraction of these items.