Description of the ICADD Mechanism
Yuri Rubinsky
Description of the ICADD Mechanism
Foreword
Large repositories of SGML-encoded material are beginning to be built up: Some 50 publishers are using (for one or more projects) the ANSI standard markup scheme for books and journals commonly called the AAP DTD. An updated version of this markup augmented with the Accessible Document techniques described in this booklet has been put forward as ISO 12083. Some 40 projects around the world are marking up millions of pages of literary materials using SGML Document Type Definitions created in accordance with the guidelines of the Text Encoding Initiative (TEI). Aerospace, defense, automotive, workstation computing, semiconductor and telecommunications industries all have DTDs supporting their requirements and new industries are exploring the role which SGML will play in their documentation. When encoded using the SGML Document Access (or SDA) techniques described in this booklet, all of the textual materials created by the associations, industries, corporations, institutions and individuals will be re
adily available to visually impaired readers, for Braille, for the generation of navigable voice-synthesized texts and for the publication of large print books and journals.
1.0 A Very Brief Introduction to Braille
1
Description of the ICADD Mechanism
Note: It is intended that later versions of this booklet will introduce the concepts necessary for creation of computer voice and large print editions. This version, however, concentrates primarily on the creation of Braille and relies on the happy coincidence that a majority of the requirements of markup for large print and computer voice will be readily met by the Braille techniques described here.
Certainly the more one is able to familiarize oneself with the goals and techniques of Braille, the more effectively one can plan for the eventual re-use of text marked up for other purposes. At the same time, the committee recognizes that it is not the intent of all authors, editors and document analysts to become Braille-fluent. Accordingly, this section hopes to present just what is needed for the purposes of creating Braille-ready text as a by-product of other markup activities. Braille is both a short-hand language and a set of rules for the display of text (letters and numbers, including complex mathematics and chemistry, for example) in a manner that is sensible to touch. A Braille character consists of six dots placed in a "cell," three rows down by two across. A dot may be either raised or not, and combinations of dots represent alphabetic and numeric characters. Because there aren't enough combinations of six dots to display the full range of letters, numbers, and special characters, Braill
e cells must be read in sequence: One Braille symbol will indicate that the following symbol (or symbols) must be read as a number instead of a letter, for example. A Braille page generally consists of 24 rows of Braille cells, with 40 cells in each row. If each Braille cell stood for just one letter or number, each page would hold roughly 200 words, and Braille books would be too thick to carry. Instead, Braille has been built up as a very dense set of abbreviations, and a large part of the skill of an experienced Braillist is knowing when and how certain abbreviations are to be used. In recent years, software has been able to duplicate the"context-sensitive" nature of Braille translation and now produces satisfactory to very good Braille. The techniques for making text braille-ready described in this document are geared for automated software translation. A software will transform a "traditionally marked up" SGML file into an output file which is enabled for Braille. That output is a second SGML f
ile which serves as input for Braille translation software. During this process, an experienced Braille transcriber will be required to handle the most complex transformations. For people who are print-disabled, Braille remains the only display method that gives them the advantages of books, that is, the ability to mark and review passages of interest, to skim (to some extent) based on the available formatting, and to study complex passages. For this reason, Braille is still the first choice for production of textbooks. Braille is a formatting language, a fairly sophisticated one, built up out of a very minimal set of format capabilities. On a traditional print page one has at one's disposal an extraordinary variety of techniques with which one can express the rich layers of meaning conveyed by a document's logical structures: point size, leading, choice of typeface to express heading levels, for example; tabular alignment to express matrix relationships; emboldening and italicization to display emp
hasis. When designing a page for the Braille reader, one is limited to a mere handful of format techniques: levels of standard indentation (and, inversely, outdents), centering, blank lines, right alignment and spaces. And one must use these techniques sparingly, knowing that there can be at most 960 cells on any page, and knowing also that much more than in a traditional print publication, each additional page bears a hefty price tag. Despite the limitations of available formatting, note too that there is a degree of flexibility in creation of
2
Description of the ICADD Mechanism
Braille pages, and Braillists comfortable with the techniques will bend rules slightly in order to optimize the amount of data that can be placed on a page. The means that the process is always partially manual. Nonetheless, the techniques outlined in this booklet are intended to automate whatever can be automated of the process.
2.0 The Goals of the ICADD Architecture
This sub-committee's work began with the following assumptions:
1 For a markup technique oriented to the visually-impaired to succeed, it must require absolutely minimal overhead (if any) on the part of the people actually marking up the text.
2 If people have to mark up text twice -- once for their own purposes and once separately for the purposes of non-visual encoding -- there is a great possibility that the second stage will not happen.
3 There is value in having one piece of text marked up in such a way that both codings are effectively present. Most significantly, as new technology becomes available to make possible browsing access to any markup, all repositories will still contain the full richness of their information. In practice this means that the "real" or "archival" document will always be the version with the source markup. The Braille-enabled output file is intended to be only a temporary part of a translation process, not to be preserved for later use. The specific goals of the technical work arose from those assumptions and were as follows:
1 to enable, as much as possible, the automated conversion of marked-up files to Braille, large print and voice editions.
2 to minimize the burden on writers and editors of understanding the requirements of markup for Braille, large print and voice synthesized delivery. (That is: This booklet should be all the background one needs to prepare Braille-ready texts.)
3 to minimize or eliminate publishers' costs in making texts available for the print-disabled community.
4 to keep the technique simple. It is our belief, after discussion with colleagues in the SGML community, that it is possible to have creators of DTDs -- all DTDs -- build into them the relevant attributes to allow for Braille, large print and voice-synthesis from the files encoded for other purposes, as a by-product. In this fashion, everyone creating markup schemes shares the burden, a burden which is absolutely minimal on a site-by-site basis -- perhaps as little as one or two days for a reasonably complex DTD if the technique is well understood, no more than half a day for a simple one.
2.1 What Is Not Covered
This document does not deal with the most complicated requirements of Braille encoding. That is, in order to devise a manageable first step, the committee has chosen to describe a base architecture plus a set of methods which are associated with SGML fragments or modules. One such fragment is included in this booklet -- for the handling of tables. Future enhancements will include support for mathematics, poetry, drama, and chemistry. Separate documentation is forthcoming which will establish both markup and procedures for these areas.
3
Description of the ICADD Mechanism
Their exclusion from the current work should not be interpreted as indicative of a lack of recognition within the committee of their importance.
2.2 For Constructs Not Supported
Although the techniques described in this Booklet will enable the preparation for multiple ICADD uses of nearly all SGML documents, certain complex constructs may not be adequately supported. However, note that one need not use the ICADD techniques to create input to Braille, large print or voice delivery software. Any of a number of widely-available sophisticated SGML transformation tools can be used to generate the markup required by the ICADD22.DTD in Appendix A.
3.0 How to Begin
The person creating a SGML-accessible application will most likely begin from one of two points:
1 a DTD already exists for the content to be converted, or
2 a DTD is to be created. In the second case, one should proceed to design an SGML application optimized to the requirements of the content almost as if there were no Braille component to the work, following a normal course for the creation of a DTD, including analyzing the requirements, proposing a set of tags to cover the requirements, and determining clear instructions for their correct use. However, during that process, we recommend that one go beyond the basic requirements of that application to add special value for the print-disabled. Where this is possible, please see the section at the end of this booklet entitled "Using Braille-Specific Elements in Any DTD". In the unusual situation where the DTD will exist only to prepare a file for Braille encoding, see both special sections at the end of this document: "A DTD Just for Braille" and "Using Braille-Specific Elements in Any DTD." Normally however, one begins with any existing SGML application. Rather than build a separate transformation
file of some sort, in the DTD, the ICADD architecture uses four specialized attributes to build in enough information for a processor to extract a file encoded for use with Braille software. One ends up with two SGML files: one encoded in accordance with the original DTD and a temporary version whose markup conforms to the tagset described in this booklet.
4.0 Overview of the ICADD Methodology
4.1 Using Architectural Forms
The idea underlying the ICADD SGML work comes from ISO 10744 -- the International Standard for Hypertext and Time-Based Encoding ("HyTime"). The HyTime standard articulates the notion that a set of
4
Description of the ICADD Mechanism
semantic constructs may be associated with SGML elements as attribute values and therefore carry with them meaning or intentions beyond what is normally part of an SGML application. This technique, invented by Dr Charles Goldfarb of IBM, defines these constructs as "architectural forms". HyTime standardizes one set of forms which is useful for its purposes. The ICADD technical sub-committee has developed a very simple implementation of architectural forms to represent the formatting capabilities of Braille with a small set of "Braille elements". To a great extent, the formatting capabilities also represent the simple typesetting requirements of large print books and the implied structural hierarchies of the architectural forms turn out to be appropriate for navigation through computer voice delivery of texts. By using architectural forms, the ICADD technique lets SGML attributes in a source DTD carry with them the mapping for their associated Braille elements. This means that no separate file needs t
o be associated with either the source file or the DTD; all the necessary information is immediately available in the DTD. This also means, interestingly, that authors can create documents using a DTD without the ICADD attributes, and pass the resultant file to a system which has access to the same DTD but in an ICADD-enabled version. Indeed, if appropriate, only Braille creation facilities need use the Braille-enabled version of a DTD, although we feel it important that the creators of the DTD be the ones to indicate their preferred mappings. This approach has the additional benefit of spreading the cost of building ICADD-enabled DTDs amongst all those who create the DTDs, and of asking those most familiar with a DTD (that is, its creators) to give guidance, through the "SGML Document Access" attributes, to later users of the marked-up content.
4.2 The Building Blocks
There are five major components of the ICADD technique for SGML Document Access. Together they form a simple architecture for informing an SDA transformation process as to the intended output of such a process -- that is, they allow DTD designers to plan for the creation of an inputstream to production facilities for Braille, computer voice and large type editions. Note that very useful mappings can be constructed using only the SDAFORM and the simple form of the SDARULE attributes. There is sufficient capability in these techniques to accomplish a great deal more, but for many documents, the simplest transformations will go a long way towards making more electronic information readily accessible. Each of these components is discussed in further detail in the following pages.
1. SDAFORM An attribute declared on a source element whose value is the intended result of an SDA transformation; that is, the value of such an attribute must be an element name in the canonical SDA tagset. sdaform may also specify attributes of the original element to be carried forward into the output or transformed file. With the keywords #ATTLIST or #ATTRIB , sdaform carries the names and values of source attributes through the SDA transformation. 2. SDARULE An attribute declared on a source element whose value indicates logical contexts in which values specified override the default element name as specified in an sdaform attribute. With the keyword #USE , sdarule attributes may carry pointers to sets of rules activated by their place in the parentage of the current element -- that is, they may be used to establish stacking rules of precedence for transformations. 3. SDAPREF
5
Description of the ICADD Mechanism
An attribute declared on a source element whose value is to be reproduced as content in the output of the transformation; that is, the transformation process imitates procedures which might take place in a typesetting process to generate fixed text or, with the keyword #COUNT , automatic numbering in place of the source start-tag. The keyword #SET establishes generated text or a counter with the name of an element and the keyword #USE indicates the attribute for which that counter is to be used. With the keywords #ATTLIST , #ATTRIB or #ATTVAL , sdapref carries the names and/or values of source attributes through the SDA transformation. An SGML processing instruction declared as part of an sdapref value and containing the word sdatrans indicates that a Braille transcriber or other expert should examine, and if necessary, modify the current output element structure by hand. 4. SDASUFF An attribute declared on a source element whose value is to be reproduced as content in the output of t
he transformation; that is, the transformation process imitates procedures which might take place in a typesetting process to generate fixed text or, with the keyword #COUNT , automatic numbering in place of the source end-tag. The keyword #SET establishes generated text or a counter with the name of an element and the keyword #USE indicates the attribute for which that counter is to be used. With the keywords #ATTLIST , #ATTRIB or #ATTVAL , sdasuff carries the names and/or values of source attributes through the SDA transformation. sdasuff is the same as sdapref except that the generated text replaces the source element end-tag instead of the start-tag and sdatrans instructions are not allowed. 5. Special Character Handling Use of standardized SGML entity references to ensure that characters and symbols not in the base ASCII character set are successfully passed to an accessible document input stream.
5.0 Using the ICADD Architecture
5.1 Base Tag Set
A small set of "canonical" elements (the "SDA tagset" henceforward in this document has been created to support the basic output formats available in Braille. Because the first target audience for the Braille-ready techniques comprises publishers who produce textbooks with desktop publishing software and who have indicated their enthusiasm for a minimal tagset, the name given to the formal version of this tagset is "ICADD22.dtd". Note that the actual DTD included in this document as an appendix is still in draft form pending additional experimentation and testing. When using the mapping techniques described on the following pages, one must use the canonical element names listed below as the FIXEDvalues of the appropriate attributes, that is, as the target elements of any transformation. This is the heart of the ICADD standardization effort. The elements defined in this base DTD are as follows:
ANCHOR Mark Spot on a Page AU
6
Description of the ICADD Mechanism
Author(s) B Bold Emphasized Text BOOK Highest Level Element for Document BOX Boxed or Sidebar Information BQ Block Quotation FIG Figure Title and Description FN Footnote H1 Major Level Heading within Book H2 Second Level Heading H3 Third Level Heading or BOX Heading H4 Fourth Level Heading H5 Fifth Level Heading H6 Sixth Level Heading IPP Page Number of Ink Print Page IT Italic Emphasized Text LANG Language Indicator LHEAD List Heading LIST List of Items LIT Literal or Computer Text LITEM List Item NOTE Note in Text OTHER Other Emphasized Text PARA Paragraph PP Print Page Reference TERM Term or Keyword
7
Description of the ICADD Mechanism
TI Title of the Book XREF Cross Reference
5.2 Table Module
An optional set of canonical elements has been created to support the encoding of tables. Tables marked up with this set may be used for Braille, large type and computer voice. The set consists of:
TABLE The highest level element, which will include at least one TGROUP TGROUP Grouping element allows repeated combinations of the next three elements to appear in one table: THEAD Table Header (optional) TBODY Table Body (required) TFOOT Table Footer (optional) COLDEF Column Definition (which carries necessary attributes for the column information) HDROW Row in a Header HDCELL Cell in a Header ROW Row in the Table Body STUBCELL The Stub Cell (or Row Heading) of a Row SSTCELL A Sub-Stub Cell in a Row (usually with a different indent) CELL Table Cell SHORTXT Short Text Element provides alternative text for a stub cell or head cell for voice representation or for a cell reference to longer text carried in the NOTE in a Braille table NOTE Text extracted from Braille table cells in order to allow the narrowest possible column widths in the table body
5.3 The Basic Transformation Requirement
Imagine a Braille, large print and voice synthesis tagset which lists only the following elements:
H1 Major Level Heading H2 Second Level Heading
8
Description of the ICADD Mechanism
H3 Third Level Heading LIST List of Items LITEM List Item PARA Paragraph Here's a sample piece of an SGML document type definition, using other elements:
These declarations state that a sec (section) element must begin with a section title ( sectitle ) which must be followed by one or more paragraphs ( p ) or sequential lists ( seqlist ). A seqlist consists of one or more list items ( li ), which in turn are made up of any number of paragraphs ( p ). Finally, the last declaration says that sectitle and p are made up of parsable character data, that is, letters and numbers. Now we need to map the elements in the source DTD to the available SDA elements. That is, we need to state how to represent sec, sectitle, seqlist, p and li using only the tagnames h1, h2, h3, para, list and litem .
5.4 Establishing One-to-One Mapping: SDAFORM
We put the two sides together by using attributes to add extra information to all instances of an element. In its simplest form, the attribute list for an element names the SDA element to which the element corresponds. This technique uses the SGML keyword FIXED to force a specific attribute value to be associated with every appearance of the related element. Its value cannot be changed within the document. For example, to associate the sample element sectitle with the SDA element h1 , we create an attribute named sdaform that "fixes" that correspondence:
This indicates that whenever sectitle is used, it stands for an h1 in the SDA tagset. The example uses only a few of the available SDA "elements" but the technique is the same for any DTD: One uses FIXED sdaform attributes to map any source DTD's elements to those of the canonical set in ICADD22.dtd (listed in Section 5.1 of this book and shown in the DTD in Appendix A). The fixed value must be one from the canonical set. If an element has no previously declared attributes, you will need to create an ATTLIST declaration. If the element already has attributes, simply add the FIXED attributes after those already declared as part of the same declaration. Any element may have no fixed sdaform or sdarule attributes (that is, no declared mapping). For each such element, the transformation process must discard both its start- and end-tags. A typical case where this occurs is with "containing elements", those which do not contain character content of their own, but which mark structural boun
daries, and contain only other elements.
9
Description of the ICADD Mechanism
Note that software which transforms an SGML file from being encoded according to a source DTD is likely to be SGML software, able to read the DTD and perform actions based on the attribute values established in the DTD. The output of such a transformation will be text tagged according to the canonical ICADD tagset, but, under some circumstances, it may not parse against the ICADD22.dtd. Nor does it need to. Braille translation software can withstand a great deal of flexibility in its handling of an input stream.
5.5 Context-Dependent Mapping: SDARULE
Clearly, however, there are occasions when a source element is mapped to a different SDA form depending on the context in which it appears. The ICADD technique includes both a simple mechanism for simple contextual mappings, and more complex ones for those situations in which the mapping may be dependent on attributes in ithe source document instance or on the fulfillment of one or more conditions in the element's ancestry. As just described, the attribute sdaform defines a mapping in the attribute list declared for that element. The simple form of the sdarule attribute allows mappings for an element to be defined in the attribute list of a different element, one which provides context for the mapping. An example makes this clear. Both of the elements concerned -- sectitle and title -- may appear in other elements, with other mappings, but the declaration says that within a sec , a sectitle maps to h1 and a title maps to h3 .
(The attribute declaration in this and other examples is spread across two lines only for legibility. Spaces, carriage returns and tabs are not meaningful in the declarations, with the exception of generated text -- see Section 5.7 below.) In a simple contextual mapping, the attribute sdarule takes an even number of arguments; within each ATTLIST , you can declare any number of pairs of arguments. This mechanism can readily provide different mappings for the same elements in different contexts. For example:
The interpretation of these rules is simple: In a chp , title maps to an h2 element. In a sec , title maps to an h3 element. When it appears in a fig , it is transformed into an it element (italic in the SDA tagset). Remember that title could also have an sdaform attribute of its own:
Unless specified otherwise by an sdarule , therefore, title has a default mapping of ti (title in the SDA tagset). Any active SDARULE overrides the default and the attribute closest to the element to be transformed takes precedence: If a title appears in a figure within a chapter, in this example, it is mapped to it .
5.6 More Complex Context: Stacking Rules with #USE
10
Description of the ICADD Mechanism
The ICADD architecture specifies a more complex mechanism for creating a contextual mapping rule as an attribute on one element, and pointing to it from another element. Only when both the elements appear as part of the full path -- that is, when both element's start-tags have appeared but not their end-tags, then the rule is established and activated and that particular and specific mapping occurs. This is a very powerful technique that can be exploited to great advantage where necessary. Note that in the great majority of cases, the simple sdarule attributes described above will suffice to provide adequate context for changing mappings within document structures. The procedure described in this section will appear only rarely. This mechanism allows one to set a stack of open rules, where the rule in a parent element closest to the current context overrides rules higher in the element ancestry (or previous in the stack). For example, in a content model where chp could occur at multiple levels in
the document, we need to be able to specify different mappings for title depending on whether chp is in a part or not:
The highest level title will always be an h1 , whether it's in a part or a chp . The second level element will always be an h2 . Accordingly, the Braille architectural forms need to carry hierarchical level information with them, that is, they must distinguish between an h1 and an h2 , recognizing that if title appears in a part it maps to h1 , if it appears in a chp within a part , it maps to an h2 , but if the chp is not in a part , the title maps to an h1 . This is done by establishing rules within chp that set the two mapping conditions:
Notice that arbitrary application-specific names are given to two new attributes ( sdabdy and spapart ). Later, other attributes will point to them. They can be given any names that have meaning to the DTD designer; they are not specified by the ICADD techniques. (The example used "SDA" as their prefix only to be consistent with the accessible document attributes. It need not have done so.) From the example in Section 5.5, title has a default mapping set to the ICADD element ti , but this has no bearing on the present situation. It is over-ruled by the sdarule attributes:
(In some cases, both the source element ti , for example, in the Association of American Publishers' BOOK DTD -- and the ICADD tag TI have the same name. The sdaform attribute must nonetheless be established.)
Remember that these stack, that is: If a user has entered a bdy start-tag, he or she has activated the rule that says within a chp element, use the sdabdy rule. A processor now comes upon the chp start-tag and knows to choose the sdabdy rule which decrees that in this context, the title element is to become an h1 .
11
Description of the ICADD Mechanism
Imagine, instead, that the processor, after seeing the bdy start-tag, then came upon a part start-tag. To the stack, it would add the two rules that say transform a title element, into an h1 element; and, upon encountering a chp element, use the sdapart rule. Accordingly, when it comes upon the first title element it hasn't seen the chp start-tag yet, so it is still using the part 's rule and transforms the title into an h1 . Then, when the processor comes upon the chp start-tag, it knows to act on the sdapart rule, and it transforms the next title into an h2 .
5.7 Generated Text: SDAPREF and SDASUFF
The third type of ICADD attribute covers situations in which the name of an SGML element (its generic identifier) carries useful information which would be lost if the original element were transformed into a sdaform attribute which carries only the information needed for presentation. Often formatting software packages will generate fixed text strings or counters as they produce a book. An ICADD input file must have this information in the stream of content. (A Braille book must match the standard print book even if some of the print book's content was generated by the typesetting system and does not exist in the raw electronic manuscript.) The attributes sdapref and sdasuff duplicate this part of the typesetting process, and also have a rudimentary counting mechanism to generate alphabetic or numeric content. Several examples follow:
Here the element apptitle , the title of an appendix, is mapped to a standard h1 element in the SDA set. The sdapref attribute carries "generated text," words to be produced by the translator software as a string appearing within the h1 element immediately after the h1 start-tag.
sdasuff is a similar attribute for generated text to be inserted where the end-tag appears. When sdapref or sdasuff attributes are used without an sdaform attribute, the result is effectively the simple replacement of both or either the source start- and end-tags by generated text. A basic example:
In the example immediately above, the start- and end-tags for a quote element are replaced with typewriter quote marks.
In this example, both the figure description and the simplified figure description (see Section 6.3 of this booklet) are transformed into paragraphs whose opening text is "Figure Description: ". Notice that the sdapref attribute value includes a space after the colon since the contents of the paragraph would normally begin immediately after the start-tag.
5.8 Preserving Text: #CONTENT
Generated text is not always formatted according to the stype of the element which generates it. To
12
Description of the ICADD Mechanism
accomodate this, the prefix and suffix strings may contain markup. The use of the keyword #content allows the replacement of one start--tag with a small element structure, as in the following example:
Abstract