Representing tabular structures using XML markup is a complex area. Fortunately, for this very reason there is a standard for table markup that this DTD has adopted. However, there are constraints on the use of this standard, and features of it that require explanation. In addition, this standard does not address the need to support the need for formal and informal tables in journal articles, nor the specific conventions adopted in journal tables.

Formal tables are tables that would be given a table number in the article (even if the content of the object so labelled is not actually a table at all, but is instead a graphic image of a table or similar structure). They are expected to have a title, and may include endnotes, but may be handled as markup, graphics, or both.

Informal tables are used to help format text that cannot be formatted using other constructs. For example, a list that the author insists must occupy two or more columns because it is a long list with short items. These tables are not labelled in any way, and cannot contain a title or endnotes.

Formal tables capable of being tagged should be handled as such (if the table is rotated in print, or sufficiently complex, a graphic should be supplied to accompany or replace the markup). A table should always include column specifications as part of a table header. Outer rules should always be identified along with proper row and column separators within the table where needed.

In the case of an informal table, the content must be a table structure.

As mentioned above, a formal table can contain a graphic instead of a table grid. The <graphic> element is used for this purpose. Note that the title must be added to the XML markup, as well as appear in the graphic itself, and indeed the <title> element is required in any case:

<formaltable>
  <title>Table Image</title>
  <graphic fileref="tableimage.gif"/>
</formaltable>

Graphics cannot be inserted directly into informal tables, but this is not a problem because the table would add nothing of value to an image simply inserted directly into the text (though graphics can still be used in individual cells of such a table).

The CALS model has been used for table structures since the late 1980's, and gained an early lead in software support. Apart from the very similar HTML table model, it has remained dominant ever since.

The basic structure is row-oriented. There is an element for each row, and within it an element for each cell (entry). At a higher level, there are elements that identify the body of the table, and optional header and footer sections. If present, all three sections have the same elements to build one or more rows of cells. The following example shows a simple CALS table:

<table>
  <thead>
    <row><entry>Header 1</entry><entry>Header 2</entry></row>  
  </thead>
  <tfoot>
    <row><entry>Footnote</entry></row>
  </tfoot>
  <tbody>
    <row><entry>Row 1, Cell 1</entry><entry>Row 1, Cell 2</entry></row>
    <row><entry>Row 2, Cell 1</entry><entry>Row 2, Cell 2</entry></row>
  </tbody>
</table>

The header section appears first. The content of the rows in this section may be presented multiple times, at the top of each page that the table spans over. More surprisingly, the table footnote section also precedes the body section. This is done so that rendering software can "grab" the footnote text before it starts to render the body content, and then add it to the end of each page that the body content spans over.

When body rows are divided into sections, additional vertical space is needed between the groups to make these sections obvious. This is achieved by creating a separating row, and populating it with a single, empty <entry> element:

<row><entry>Last Row of Group</entry>...</row>
<row><entry></entry></row>
<row><entry>First Row of Group</entry>...</row>

Composition of tables with graphical, mathematical or chemisty content must be handled in such a way as to render correctly both in print and on the web. To that end, all entries must be fully populated with appropriate content when delivered. Oversize or complex tables may be provided in graphical form under extreme circumstances, but Taylor & Francis reserve the right to return a poorly handled table for recomposition if its technical staff feels it appropriate.

In order to simplify the process of including images in table cells, tables coded with inlinegraphic or structure in place of the more correct usage of inlinematheqn or inlinechem will be accepted. The only stipulation is that any entry with a text citation needs to be coded such that it has a related linkend value to create the hypertext link.

The CALS model has been adapted (safely) to target the most common requirement for formal tables in journal articles.

The <table> frame attribute has been given a default value of "topbot" (usually, there is just an implied setting). Column and row separator details must be added to the <tgroup> element in order to avoid problems with inadequate rendering tools, and to ensure that this is done the colsep and rowsep attributes have been removed from the <table> element.

The <colspec> element must be used, and must have both column number values and column names, which can adopt a simple standard such as "col1", "col2", col3" etc. The width must be specified, and the "*" proportional system is recommended because it is easiest to convert into appropriate real values suitable for the medium and column width concerned whenever it is rendered, though points and millimeters (including fractions of millimeters) are also permitted. The align attribute has been removed from this element to prevent its use (because it is much safer to align cells individually).

The <thead> element has its valign attribute set to default value of "bottom" (instead of just implied). In most cases, taggers are expected to add a rowsep attribute value of "1" to the last row of header cells.

The <tbody> element has its valign attribute set to a default value of "top" (instead of just implied).