ZedAI Content and Structure Descriptions

From zedwiki

Background

The need to describe images, graphics and structures for accessible production purposes is not a new problem. Unfortunately, the prevalence of HTML has led to solutions in the digital world geared to working in a browser-based environment. HTML, however, was not engineered for accessibility, making all such solutions inherently limiting.

This problem was recognized early on in the development of the DAISY standard, leading to the introduction of the prodnote element in the Z39.86-2005 version. Although a step forward, prodnote suffered from a number of problems itself: it's general nature made it broadly useful but interfered in determining the semantics of its contents; the descriptions had to be embedded in the xml data hindering production processes; the method for their inclusion in an output format was restrictive; and on.

ZAI description element

Overview

The ZAI description element represents a new direction in adding accessible descriptions to XML documents. Unlike its predecessor, the prodnote, the description element does not attempt to encompass such a broad range of uses.

prodnote has been effectively split into two elements: the annotation element - together with the role attribute - assumes the production and rendering aspect, and the description element is now designated for attaching one or more accessible descriptions to any element in a document.

The description element also has been enhanced so that descriptions can be referenced from external files. Although it is anticipated that external descriptions will be authored in ZAI syntax, there is no requirement that they are, making the specification adaptable to future directions.

The targeting of descriptions to output formats has also been greatly enhanced. The desc attribute already allows a single element to reference multiple types of descriptions. But beyond this enhancement, the ZAI Content Selection Feature is like the old showin attribute but on steroids.

Attaching descriptions

The desc attribute allows any element to reference a description. A structural description of a table, for example, could be attached as follows:

<table desc="table1-desc">
   ...
</table>

<description xml:id="table1-desc" role="structural">
   <p>The table contains four columns and twelve rows.</p>
   <p>The headings for the columns are...</p>
</desc>

An element isn't restricted to only a single type of description, either, ensuring that multiple descriptions aren't crammed into a single element because their type can't be effectively determined.

The desc attribute can contain a space-separated list of references to the associated descriptions for the element; the only condition is that each reference must resolve to a description with a unique role attribute value. This flexibility means that a content description could also be added to the above example as follows:

<table desc="table1-struct table1-content">
   ...
</table>

<description xml:id="table1-struct" role="structural">
   <p>The table contains four columns and twelve rows.</p>
   <p>The headings for the columns are...</p>
</desc>

<description xml:id="table1-content" role="content">
   <p>The table describes the financial data for a fictitious corporation...</p>
</desc>

Another feature of the description element is that it does not have to be embedded within the element that references it. A producer can include their descriptions anywhere in the document they choose: as close to the element as possible, grouped at the end of a section or even in the head of the document.

Also, for convenience, the object element assumes a content description element around it's child content:

<object src="mouse.png">
   <p>A small mouse is pictured sitting on a rock...</p>
</object>

An explicit description can be embedded inside the object, the purpose of which is explained in the next section.

Attributing descriptions

Another feature of ZAI documents is the ability to specify the contributor of any element via the by attribute. By default, all elements are attributed to the author of the document. Attaching the by attribute allows the contributor to be changed, making it easy to identify the parts of a document that have been subsequently added, such as by a republisher.

The previous examples have assumed the descriptions were provided by the author, as no by attribute was attached to them. To change to a republisher contribution is as simple as adding the attribute with the appropriate role value:

   <description xml:id="mouse-desc" by="republisher">
      <p>A small mouse is pictured sitting on a rock...</p>
   </description>

As noted in the previous section, the object element implies an author description wraps its content. As descriptions are often added by republishers, a means of overriding this behaviour also needed to be added while maintaining the simplicity of the automatic association, which is the reason why a single explicit description element can also be used inside objects:

<object src="mouse.png">
   <description by="republisher">
      <p>A small mouse is pictured sitting on a rock...</p>
   </description>
</object>

Although a little more work for republishers to add the container description, this method retains the benefit of not having to ID the description and reference it from the source object.

External descriptions

ZAI document creators are no longer limited to embedding their descriptions within the documents, either. The writing of descriptions in parallel with document production has proven a production headache, which is in part why the description element has been designed so that it can point to an external resource containing the description. The xlink:href attribute can be added in place of child content to point to a local or remote resource:

<object src="mouse.png" desc="mouse-desc"/>

<description xml:id="mouse-desc" xlink:href="mouse.xml"/>

This feature means a description writer could be editing the description files for a document in parallel with a production team creating or converting the main body to XML.

There is also no requirement that the referenced resource be an XML file. Although a means of validating description fragment files as ZAI XML is being created, and the use of ZAI markup is encouraged, like the metadata model for ZAI documents the ability to attach descriptions is being kept as open as possible so that it remains adaptive to future directions.

Targeting descriptions

A common need for producers and republishers is to be able to target their descriptions to the output medium. Ideally, a description of an element would be applicable regardless of the medium, but that's not always the case: a description that is good for braille and audiobooks may not be suitable for tactile, for example.

The DTBook showin attribute was a first step in the direction of targeting output, but gave only a limited set of targets (braille, large print or print). There was no way to distinguish "print", for example, from the ways that print material may be represented (on paper, HTML format, PDF, etc.), braille from BANA rules or UEB rules, etc. There was also no way to target to the reader's need, such as descriptions for blind readers v. dyslexic readers.

Again, to foster openness and extensibility, the ZAI Content Selection Feature has been introduced as a means of providing greater control over the output not just of descriptions, but of all data in a document.

The sel:select element is similar to an if/else condition in a typical programming language. Each sel:when condition is tested during a transformation process to determine whether to output its contents, defaulting to the sel:otherwise if no condition matches.

A simple example of how to target description output follows:

<sel:select>
   <sel:when expr="target:format('BRAILLE')">
      <description by="republisher">
         <p>...</p>
      </description>
   </sel:when>
   <sel:otherwise>
      <description by="republisher">
         <p>...</p>
      </description>
   </sel:otherwise>
</sel:select>

The content selection feature is too complex to summarize all of its functionality here, but more complex tests than simply the output name can be constructed using the expr attribute. For more information, please refer to the feature's documentation (please note that the feature is still being developed, so not all functionality is yet available for review).

One note on the new functionality is the inclusion of the sel:selid attribute to solve the problem of repeat IDs. As keen readers of XML will notice in the above example, the repeated descriptions did not include xml:id attributes, because repeating the ID in each condition would invalidate the document. They are not examples of real world markup, as a result, because no element's desc attribute could refer to them.

The sel:selid attribute solves this problem by "hiding" the ID until processing and resolution of the conditions, at which point it is converted to an xml:id. An example of a select as it would look in an actual document follows:

<object src="mouse.png" desc="mouse-desc"/>

<sel:select>
   <sel:when expr="target:format('BRAILLE')">
      <description sel:selid="mouse-desc" by="republisher" xlink:href="mouse-braille-desc.xml"/>
   </sel:when>
   <sel:otherwise>
      <description sel:selid="mouse-desc" by="republisher" xlink:href="mouse-desc.xml"/>
   </sel:otherwise>
</sel:select>

After a processor has generated the braille output file, the above would be reduced to:

<object src="mouse.png" desc="mouse-desc"/>

<description xml:id="mouse-desc" by="republisher" xlink:href="mouse-braille-desc.xml"/>

The ability to tailor descriptions to the output medium has made a significant leap forward as a result of this new feature.