The table element

Usage Example

<caption ref="mylodon">ADMEASUREMENTS OF THE LOWER JAW OF MYLODON DARWINII.</caption>
<table xml:id="mylodon">
    <tr>
        <th colspan="2">Inches</th>
        <th>Lines</th>
    </tr>
    <tr>
        <th>Length (as far as complete)</th>
        <td>17</td>
        <td>6</td>
    </tr>
    <tr>
        <th>Depth of each ramus</th>
        <td>4</td>
        <td>9</td>
    </tr>
</table>        
    

Allowed parents

address, annotation, block, body, caption, description, item, d:longdesc, object, quote, section, d:simplifiedLanguageDescription, d:summary, td, th and d:tour

Allowed children

This element must not contain text.

This element must contain the following children: tr

Content model

Namespace

http://www.daisy.org/ns/z3998/authoring/

Usage Details

Associated content

Although images, tables and other objects may stand on their own in a document, typically they will include an accessible description, a caption and possibly a header.

In order to establish that other elements are carrying information about the table or image, you must tie them together using ref attributes that point to the xml:id of the central element, as in the following example:

<hd ref="galapisle">Galapagos Islands</hd>

<object xml:id="galapisle" src="island.png" />

<caption ref="galapisle">The Galapagos islands lie approximately 970km off the shore of Ecuador.</caption>
        

If you were to omit the ref attributes, the information would only be loosely associated by its order in the document (i.e., a processing agent would not be able to handle the elements as a group).

Although all of the above elements are associated through references to the object element, their semantics are still only loosely defined (i.e., the linkage is established, but not what that linkage represents). A human can intuit they represent a figure by the collected items and their use, but not so a machine.

It can also be confusing to edit a document marked up with all content within a section as siblings, because document narrative could fall both immediately before and after the figure elements making it all appear connected. Without checking for ref attributes as you edit, it wouldn't be clear if a new non-structural heading were occuring or a figure were being inserted.

To begin to bind the elements more tightly and create a figure both humans and machines can understand, the block element can be wrapped as a container. A role attribute can then be attached to further specify that all of the children constitute a figure, as in the following example:

<block role="figure">
    
    <hd ref="galapisland">Galapagos Islands</hd>
    
    <object xml:id="galapisland" src="island.png" />
    
    <caption ref="galapisland">The Galapagos islands lie approximately 970km off the shore of Ecuador.</caption>
    
</block>
        

A common question at this point is why the ref elements are still necessary. The answer is because the block element is only a general container. The role attribute provides additional semantics, but those semantics only extend to what kind of content the block represents, not how it is interrelated (but more on this shortly).

Now that the content is grouped, however, we can begin to further simplify it. To avoid the extra work of linking the child elements, an associate attribute can be attached to the block (the attribute represents an automatic ref between all the children). The IDREF that you specify in the attribute implicitly makes the references that we have so far been carrying forward, so our markup can now be more minimally represented as in the following example:

<block role="figure" associate="galap-figure">
    
    <hd>Galapagos Islands</hd>
    
    <object xml:id="galap-figure" src="island.png" />
    
    <caption>The Galapagos islands lie approximately 970km off the shore of Ecuador.</caption>
    
</block>
        

Now, when a processing agent comes across this markup it will be able to determine both that the block constitutes a figure (from the role attribute) and that the child hd and caption elements are tied to the object (from the associate attribute). We've gained much more information about the figure than we started with, and the work required to reproduce the figure has been greatly simplified (there is also no worry about accidentally forgetting a ref on any of the children).

Now that we have a compact markup model for figures, we can briefly jump back to why we cannot assume associations. Consider the following example:

<block role="figure">
    
    <object xml:id="galap-isa" src="isabella.png" />
    
    <object xml:id="galap-fer" src="fernandina.png" />
    
    <object xml:id="galap-sc" src="santa-cruz.png" />
    
    <caption>The Galapagos islands lie approximately 970km off the shore of Ecuador.</caption>
    
</block>
        

We cannot make a simple association here that all the children of the figure are tied to an object, as the figure constitutes three images sharing a caption. We likewise cannot use the associate attribute, but have to revert back to explicitly linking the caption to each of the three images it describes:

<block role="figure">
    
    <object xml:id="isa" src="isabella.png" />
    
    <object xml:id="fer" src="fernandina.png" />
    
    <object xml:id="sc" src="santa-cruz.png" />
    
    <caption ref="isa fer sc">The Galapagos islands lie approximately 970km off the shore of Ecuador.</caption>
    
</block>
        

It's this potential for varation that requires at least some level of linking in all cases, and makes it impossible to state a simple rule that would hold true for all content grouped in a block.

Fortunately, most image and table figures are not this complicated, and the simpler process of grouping in a block with the associate attribute will work the majority of the time.