The text variant of the object element

Usage Example

<section role="chapter">
    <h>Chapter I.</h>
    <p><name><char><object src="init_A.png">A</object></char>lice</name> was beginning 
        to get very tired …</p>
</section>
    

Allowed parents

abbr, d:about, annoref, annotation (block variant), annotation (phrase variant), m:annotation-xml, aside, block, caption, char, citation (block variant), citation (phrase variant), code, d, definition, description (block variant), description (phrase variant), description (text variant), emph (phrase variant), emph (text variant), expansion, h, hd, hpart, item, ln (code variant), ln (ln variant), lnum, d:longdesc, meta, name, note (block variant), note (phrase variant), noteref, num, object (block variant), object (phrase variant), object (text variant), p, ssml:phoneme (phrase variant), ssml:phoneme (text variant), ssml:prosody (phrase variant), ssml:prosody (text variant), quote (block variant), quote (phrase variant), its:rb, ref, its:rt, s, ssml:say-as (phrase variant), ssml:say-as (text variant), d:simplifiedLanguageDescription, span (phrase variant), span (text variant), sub, ssml:sub (phrase variant), ssml:sub (text variant), d:summary, sup, td, term, th, time, ssml:token (phrase variant), ssml:token (text variant), d:tour, w and wpart

Allowed children

This element may contain text.

This element may contain the following children: ssml:break, char, description, emph, object, pagebreak, ssml:phoneme, ssml:prosody, its:ruby, ssml:say-as, span, sub, ssml:sub, sup and ssml:token

Content model and additional requirements

Variants

This element exists in 3 variants. The other 2 variants are:

• The block variant of the object element
• The phrase variant of the object element

Namespace

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

Usage Details

It is not always the case that the referenced object will be available, renderable or accessible. The object element provides two mechanisms for adding fallback accessible descriptions in these cases:

1. the direct inclusion of elements within the object element:

   <object xml:id="mnt1" src="mouse.png">
       <p>A picture of a small, grey mouse.</p>
   </object>
                   

   or

   <object xml:id="mnt2" src="mouse.png">
       <description by="republisher">
           <p>A picture of a small, grey mouse.</p>
       </description>
   </object>
                   

   In the first example, a description element with a by attribute value of author is implied around the child content. In the second, an explicit description has been added to identify that the description has been contributed by a republisher of the document.

2. by attaching a desc attribute pointing to the description:

   <object xml:id="mnt3" src="mouse.png" desc="mouse-description" />
   <description by="republisher" xml:id="mouse-description">
       <p>A picture of a small, grey mouse.</p>
   </description>
                   

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.