Figure 1.
The relatively new international HyTime standard (ISO 10744) introduced the notion of architectural forms. With architectural forms, SGML elements can be classified by means of #FIXED attributes as belonging to some class. In HyTime, architectural forms are used as a basis for processing hypermedia documents, but their use is not limited to that.
The International Committee for Accessible Document Design (ICADD) was formed to help in making printed materials accessible to people with print disabilities (eg. people who are blind, deaf-blind, or otherwise reading impaired). The ambition of ICADD is that documents should be made available for people with print disabilities at the same time as and at no greater cost than they are made available to people who can access the documents in traditional ways (usually by reading them on pages of paper). This ambition presents a significant technological challenge.
ICADD has identified the SGML standard as an important tool in reaching their ambitious goals, and has designed a DTD that supports production of both "traditional" documents and of documents intended for people with print disabilities (eg. in braille form, or in electronic forms that support speech synthesis).
ICADD is aware that it is unrealistic to expect document producers and publishers to use the ICADD DTD directly for production and storage. Instead a "document architecture" has been developed that permits relatively easy conversion of SGML documents in practically any DTD to documents that conform to the ICADD DTD for easy production of accessible versions of the documents. The architecture is based on ideas that are quite similar to those of HyTime architectural forms.
The approach of ICADD is interesting, not least because it illustrates that document portability and exchange in SGML can be achieved by other means than standardizing on a single DTD in the exchange domain. In ICADD, portability is achieved by specifying mappings onto a standardized DTD.
This article describes a technique that permits the processing of SGML documents that conform to many different SGML DTDs by means of SGML attributes with well-defined semantics on the elements of the DTDs. This way, certain processing can take place without knowing the specific semantics of all of the DTD. This technique was chosen by the ICADD committee (see below) to improve access to information for visually impaired.
The relatively new HyTime standard (ISO 10744) introduced the term architectural forms for the description of document characteristics independently of individual (SGML) applications. In HyTime, architectural forms are used to define hypermedia-related semantics without restricting the document types that can be used in HyTime-compliant applications.
The HyTime standard itself doesn't define architectural forms formally. Instead the following informal explanation is given:
Architectural forms are rules for creating and processing elements (just as document architectures are rules for creating and processing documents). Architectural forms are specified principally by attribute definitions, one of which is the "HyTime architectural form" attribute, whose value identifies the form.
This explanation doesn't say much. The interesting thing about architectural forms is that they transcend applications! An architectural form identifies elements that belong to a certain class, and defines some set of semantics that apply to the elements which belong to the form. However, neither the elements nor the semantics are limited to a single SGML application. Architectural forms define semantics independently of applications, and elements in many different DTDs can belong to the same architectural form.
The usual approach when you want to use SGML is to define a DTD, and then process documents that conform to that DTD. Normally, the processing is bound directly to the document structure as it is manifest from parsing the document with respect to the DTD. With architectural forms, you can define applications that process documents which conform to many different DTDs. The processing that is applied to documents depends on the elements in the document that are identified as belonging to particular architectural forms. In other words, with architectural forms you define processing independently of the specific document structure.
To give an idea of the kinds of things that architectural forms can be used for, a small example is presented below.
Consider this simple SGML document
<!DOCTYPE Doc1 [
<!ELEMENT Doc1 - - (fm,(p|ul)+)>
<!ELEMENT fm - - (tit, au)>
<!ELEMENT ul - - (li+)>
<!ELEMENT (p|li|tit|au) - O (#PCDATA)>
]>
<Doc1>
<fm>
<tit>A Simple Document
<au>Klaus Harbo
</fm>
<p>First paragraph in "A Simple Document"
<ul>
<li>Item one in list
<li>Item two in list
</ul>
<p>Final paragraph in document.
</Doc1>
Compare the document above to:
<!DOCTYPE Doc2 [
<!ELEMENT Doc2 - - (DocTitle,Author,(Para|List)+)>
<!ELEMENT List - - (Item+)>
<!ELEMENT (DocTitle|Item|
Author|Para) - O (#PCDATA)>
]>
<Doc2>
<DocTitle>A Simple Document
<Author>Klaus Harbo
<Para>First paragraph in "A Simple Document"
<List>
<Item>Item one in list
<Item>Item two in list
</List>
<Para>Final paragraph in document.
</Doc2>
Clearly, the two documents basically contain the same information, the data contentis the same. But the two documents do not conform to the same DTD, they have different markup.
Processing of SGML documents is normally controlled by the markup, so we would normally use two different programs to process (eg. format) the two documents shown above. It is clear, however, in this simple example, that the two documents have a lot in common - it is conceivable that we might use the same program to process the two documents, if we had some way of recognizing the similarities between them.
With the information available in the documents above, this is not a simple thing to do. You might, in fact, argue that it is impossible in the general case to calculate when DTDs (and thus the documents that conform to the DTDs) have "interesting" (useful) similarities.
We can, however, choose to explicitly encode the similarities in the DTDs (we could do it in the document instances, but that is probably not a good idea), and thus enable the processing of the two documents in the same way using just one program.
This is exactly what you do with architectural forms.
In the example, we could - arbitrarily - choose to encode the similarities by identifying a unifying set of "element classes" that could be used to represent the element types of the two DTDs. We could define the classes DocumentTitle, DocumentAuthor, Paragraph, List, and ListItem, for example. Each of the declared element types in the two DTDs above that have a matching partner in the other DTD can meaningfully be mapped into these classes.
Establishing a set of element classes is not enough, of course. We also need to actually associate each of the declared element types in the two example DTDs to an element class. This can be done in many ways, but one obvious way to do this - and the way it is done in HyTime - is to declare #FIXED attributes in the DTD.
In our example we might add the following declarations to Doc1:
<!ATTLIST au ElemType CDATA #FIXED "DocumentAuthor">
<!ATTLIST tit ElemType CDATA #FIXED "DocumentTitle">
<!ATTLIST ul ElemType CDATA #FIXED "List">
<!ATTLIST li ElemType CDATA #FIXED "ListItem">
<!ATTLIST p ElemType CDATA #FIXED "Paragraph">
Similarly, we could add the following to the declarations in Doc2:
<!ATTLIST Author ElemType CDATA #FIXED "DocumentAuthor">
<!ATTLIST DocTitle ElemType CDATA #FIXED "DocumentTitle">
<!ATTLIST List ElemType CDATA #FIXED "List">
<!ATTLIST Item ElemType CDATA #FIXED "ListItem">
<!ATTLIST Para ElemType CDATA #FIXED "Paragraph">
Clearly, there is now enough information available to an SGML processor so that the two documents can be processed in the same way by a single program: all the program has to do is look at the attribute value of the ElemType attribute to decide what to do.
It is important to note that architectural forms rely on conventions. In the example, we have two DTDs which now both have element types which have an ElemType attribute. Without further explanation, we can not be sure whether the meaning of values of ElemType attributes is the same in the two DTDs.
In fact, the meaning of attribute values (or anything else in the SGML document) isn't formally defined anywhere in the document type declaration. When we create SGML documents, we assume that the documents are processed by mechanisms that can correctly interpret the documents' markup (ie. know their semantics), and thus process the documents correctly.
With architectural forms this aspect becomes very important, because architectural forms are meant to go beyond any individual application. In the example, a processor would have to know somehow that the relevant information is encoded using the ElemType attribute, and know what to do with its values.
To summarise, we can say that when we use architectural forms, we add information to DTDs interpretable by mechanisms that are not as tightly integrated into the processing environment in which the documents were created as is normally the case. With architectural forms we enable certain forms of processing of the documents outside the local processing environment, by encoding information about the documents that allow mechanisms to process the document without knowing about the semantics of their DTD (other than the semantics that related to the architectural forms themselves, of course).
ICADD (International Committee for Accessible Document Design) is committed to making printed materials accessible to people with print disabilities, eg. people who are blind, partially sighted, or otherwise reading impaired. The initiative for the establishment of ICADD was taken at the World Congress of Technology in 1991.
The purpose of ICADD is to make printed materials more accessible to people with print disabilities by means of modern information technology, and to increase general awareness of accessibility problems.
The proliferation of electronic documents has created new means for producing accessible documents for the print disabled. The existence of structured documents provides new opportunities to enhance accessibility and - at the same time - lower the costs of providing it. ICADD was established to take advantage of some of these new opportunities.
Making information accessible for print disabled people basically means making it available through media they can use. That is the technical challenge facing ICADD. Traditionally, this has primarily meant braille, large print, and recorded readings on audio tapes. More recently, the combination of computers with speech synthesis modules and appropriate software has been added to the list as an alternative to audio tapes.
Most information is never made available through these media: the cost of doing so is prohibitive, requiring - usually - extensive manual editing of manuscripts (possibly even retyping) in production centres that specialise in publishing for reading impaired.
During the analysis of the problem of providing information access to print disabled, ICADD identified three categories of documents:
Documents stored in ISO standard structured formats such as SGML (and ODA).
Documents that exist in machine readable forms that do not provide the important characteristics of ISO standard structured formats.
Documents stored as bit mapped images or which exist only on paper.
ICADD's charter is to improve access to documents in all three of the above categories. However, the problems of doing so differ substantially from one category to the next. This paper discusses aspects of the techniques ICADD has chosen to improve accessibility of SGML documents.
In general, SGML documents are easier to make accessible than documents that belong to the other two categories. The special thing about them is that they have descriptive markup which explicitly structures the text using a formally declared, standardised syntax. These two qualities make a very good start for improving document accessibility.
The descriptive markup enables the automation of publishing through accessible media because it characterises the document content and so can serve as a basis of automated processing (e.g. conversion). The standard syntax ensures the use of readily available tools and the possibility of document interchange, both of which are prerequisites for reducing the costs of improving information access.
Making an electronic document available through a special medium such as braille means converting it to a format that enables conversion to actual, physical braille, so - at a fundamental level - the technical problem facing ICADD is a many-to-many format conversion. The approach chosen to tackle this problem is classic: Define an intermediate format and use two-step conversion (see figure). In the figure there are four source format and four target formats. With a direct approach, that means writing converters to convert each of the source formats to each of the target formats, yielding 16 distinct converters to write. With an intermediate format the number of converters can be reduced to 8. The larger the number of source and target formats, the more effort can be saved by using an intermediate format. In general, having N source formats and M target formats yields N*M distinct converters for a direct approach, and just N+M distinct converters when using an approach with an intermediate format. In the case of ICADD, the potential savings are substantial.
The intermediate format serves as an interface between two domains, the domain of the "normal" publishing world which produces and owns the rights to information, and the domain of specialised production centers that have technical expertise in publishing information through special media to print disabled.
The intermediate ICADD format must have characteristics that make it feasible to convert documents in the ICADD format to special media. At the same time, it must be simple enough to make conversions from formats in the publishing world relatively straightforward: If conversion to the intermediate format is not straightforward, it is unlikely to be used.
One problem in this regard is that these two goals are somewhat contradictory: on the one hand you want a powerful intermediate format that allows you to take advantage of possibilities available in the different acess-providing formats, on the other hand it's clear that it is much harder to map documents to a complex format than to a simple format.
ICADD has chosen to opt for a quite simple, "flat" format. This is reasonable mainly because the issue presently is more to actually make information available and less to exploit all the possibilities of different media. To improve accessibility, as many obstacles to accessibility as possible should be removed, and this implies sticking to a very simple intermediate format.
In some literature, ICADD's intermediate format is termed a "tag set", but it is in fact quite SGML-like, and a DTD has been developed that can be used to validate documents marked up using the tag set. The following list summarises the tags in the ICADD tag set:
Mark spot on page
Author(s)
Bold emphasised text
Highest level element
Boxed or sidebar information
Block quotation
Figure title and description
Footnote
Headings
Page number of Ink Print Page
Italic emphasised text
Language indicator
List heading
List of items
Literal or computer text
List item
Note in text
Other emphasised text
Paragraph
Print Page Reference
Term or keyword
Title of book
Cross reference
ICADD has defined a set of attributes that are used to specify exactly how a document is mapped onto the ICADD tag set. The values of these attributes are intended to be interpreted by an ICADD-aware processor; they specify mappings of the elements in the document to the tags of the ICADD tag set.
The SDA attributes can be thought of as architectural forms. With them, a DTD is augmented with information that encodes how the elements of the DTD map to known types (architectural forms) that an ICADD-aware processor knows how to process.
The SDA attributes defined by ICADD are SDAFORM, SDARULE, SDAPREF, and SDASUFF. The following subsections present a short overview of the meaning of values of these attributes.
The SDA attributes are declared #FIXED in the DTD, meaning that the declared value is the only value the attribute can take. Whenever an ICADD-aware processor checks the value of an SDA attribute, its value will be the one declared in the DTD.
The SDAFORM attribute is used for simple one-to-one mappings whose scope is all of the document (as opposed to the SDARULE attribute which has limited scope, cf. next subsection).
<!ATTLIST AUTHOR SDAFORM CDATA #FIXED "AU">
The above declaration means that AUTHOR elements are mapped to AU elements in the ICADD format, no matter where the AUTHOR elements occur in the source document. For example, using the declaration above, "<AUTHOR>Klaus Harbo</AUTHOR>" in the source document would be mapped to "<AU>Klaus Harbo</AU>" in the ICADD tag set.
The mappings permitted with the SDARULE attribute can vary a bit more than is the case for SDAFORM, letting the mapping depend on the context of the element in the document. For example, one can specify that TITLE elements should be mapped to one thing inside chapters, and to another thing when found inside a list (which is possibly inside a chapter, in which case the former specification is overridden by the latter). This mapping can be expressed using the following declarations:
<!ATTLIST CHAPTER SDARULE CDATA #FIXED "TITLE H2" >
<!ATTLIST LIST SDARULE CDATA #FIXED "TITLE LHEAD" >
The attribute value of SDARULE will always have an even number of white-space separated "arguments". The first argument of each pair specifies a source element type, the second specifies the ICADD tag the source element maps to.
With SDAFORM and SDARULE it is possible to map the document structure to the ICADD tag set. This structural mapping is not adequate, however, partly because the ICADD tag set is very limited: of course it isn't possible to map a "rich" structure into a "lean" structure without information loss. To compensate for this necessary loss, it is possible with the ICADD mechanism to generate text content on the basis of the rich structure.
For example, if the rich structure has an INTRO element, its contents can be mapped into the ICADD tag set using preceding H1 element adding a heading that informs the reader that the following text is an introduction:
<!ATTLIST INTRO SDAPREF CDATA #FIXED
"<H1>Introduction</H1><PARA>#CONTENT</PARA>">
The SDAPREF is used to generate text before the element being mapped (it is a PREFix), and the SDASUFF is used to generate text after the element being mapped (it is a SUFFix).
This section presents a complete example. The intention is that the reader should get an idea of how documents can be processed using the ICADD scheme.
The DTD is quite simple, and was constructed specifically for illustrating certain points of ICADD-based document processing.
<!DOCTYPE PRES [
<!ELEMENT PRES - - (TITLE,INTRO,(SLIDE+|SLIDEGR+)) >
<!ELEMENT SLIDEGR - - (HEADING,SLIDE+)>
<!ELEMENT SLIDE - - (HEADING,ENTRY+)>
<!ELEMENT (TITLE|HEADING|ENTRY|INTRO)
- O (#PCDATA)>
<!ATTLIST PRES SDAFORM CDATA #FIXED "BOOK"
SDARULE CDATA #FIXED "SLIDE #USE SDAPRES" >
<!ATTLIST TITLE SDAFORM CDATA #FIXED "TI" >
<!ATTLIST INTRO SDAPREF CDATA #FIXED
"<H1>Introduction</H1><PARA>#CONTENT</PARA>" >
<!ATTLIST SLIDE SDAPRES NAMES #FIXED "HEADING H1"
SDAGRP NAMES #FIXED "HEADING H2" >
<!ATTLIST SLIDEGR SDARULE CDATA #FIXED "HEADING H1 SLIDE #USE SDAGRP" >
<!ATTLIST ENTRY SDAFORM CDATA #FIXED "PARA"
SDAPREF CDATA #FIXED "#count(slide ~)#count(entry,1). ">
]>
<PRES>
<TITLE>Presentation SGMLBeLux Conference
<INTRO>This is collection of the presented slides</INTRO>
<SLIDEGR><HEADING>Document Processing Based on Architectural Forms
<SLIDE><HEADING>Architectural Forms</HEADING>
<ENTRY>First entry
<ENTRY>Second entry
</SLIDE>
<SLIDE><HEADING>The ICADD Committee
<ENTRY>First item
<ENTRY>Second item
</SLIDE>
</SLIDEGR>
</PRES>
Two mappings in the mapping of the above DTD are simple, PRES is simply mapped to BOOK, and TITLE is mapped to TI in the ICADD tag set.
It is a little bit more tricky mapping SLIDE and SLIDEGRP. The problem is that a presentation is either a sequence of slides, or it is a sequence of slide groups which is a sequence of slides. In the former case, it is reasonable to map the heading of SLIDE elements to H1, in the latter case is reasonable to map the heading in SLIDEGRP to H1 and map the heading of SLIDE to H2.
The solution using the ICADD scheme is to specify both mappings
(using the SDAPRES and SDAGRP attributes of SLIDE),
and then specify SDAPRES as the "default" by requiring the
#USE of the SDAPRES attributes on the PRES element,
and then overriding that with the SDARULE (SLIDE #USE
SDAGRP) on the SLIDEGRP element.
A counter is defined for ENTRY elements, its value is output using SDAPREF on ENTRY elements. The ENTRY counter is reset after each SLIDE (using "#count(slide ~)").
The example document shown above maps to the ICADD tag set like this:
<BOOK>
<TI>Presentation SGMLBeLux Conference</TI>
<HE1>Introduction</HE1>
<PARA>This is collection of the presented slides</PARA>
<HE1>Document Processing Based on Architectural Forms</HE1>
<HE2>Architectural Forms</HE2>
<PARA>1. First entry</PARA>
<PARA>2. Second entry</PARA>
<HE2>The ICADD Committee</HE2>
<PARA>1. First item</PARA>
<PARA>2. Second item</PARA>
</BOOK>
With the exception of the placement of certain newline characters (which were moved simply to make the output easier to read), the ICADD processor developed by Exoterica (see below) produced the output shown here.
The example demonstrates the use of the ICADD transformation scheme on a simple document. More complex transformations can be done, but it is outside the scope of this article to present all the variations of processing using the ICADD SDA attributes. The interested reader is referred to the references for more complete descriptions of the mappings possible with the ICADD mechanism.
With the SDA attributes and the ICADD intermediate format, there seems to be at least two approaches to utilising the information represented by ICADD SDA attributes (architectural forms): interpreting the SDA attributes as they occur in the document, or by mapping the document to the ICADD intermediate format, and then use the intermediate format for further processing.
The first approach can be thought of as a "virtual mapping" into the ICADD intermediate form. The second approach is really conversion, where the original representation is discarded. The two approaches are more or less equivalent, but are appropriate in different situations: a user at home can't easily print Braille - which would probably require a conversion ("real mapping") - but he or she might want to read it with his Braille display reader or access the document via his telephone (a "virtual mapping"). As a rule of thumb, virtual mappings are most appropriate for interactive applications, and real mappings are most useful for batch-oriented processing.
In the "virtual mapping" approach, the SDA attributes can be thought of as a kind of style sheet that permits processing, whereas in the "real mapping" approach they hold the parameters controlling a conversion.
A brief description is given below of examples of implementations that use the two approaches.
A major result achieved by the ICADD committee was the incorporation of SDA attributes in the standardised DTD published as ISO 12083. It is hoped that this development will further the acceptance of ICADD, and thus increase the number of DTDs that have SDA attributes defined for its elements.
We are aware of two general implementations of ICADD that use real mapping.
One was developed at UCLA (University of California in Los Angeles) for use in their InfoUCLA information system. There, SGML is used to maintain UCLA campus information. The SGML documents are converted to a variety of formats for electronic delivery (using Gopher, WorldWideWeb, WAIS, USENET News, and other delivery technologies) in multiple formats, including ICADD. The conversions are performed using Exoterica's OmniMark SGML processing and conversion programming language.
The other ICADD implementation using real mapping was developed by Exoterica. Hardly surprising, this conversion program was also written using Exoterica's OmniMark language. The resulting program, which is freely available from Exoterica on request, converts documents that conform to DTDs with SDA attributes to the ICADD tag set. It implements all parts of the ICADD specification, as described by ISO 12083.
An independent project with objectives similar to those of ICADD, CAPS (Communication and Access to Information for People with Special Needs), and sponsored by the European community, has developed an interactive ICADD implementation which uses "virtual mapping" to the ICADD tag set.
The CAPS developed browser software enables the visually impaired user to navigate SGML documents which incorporate SDA attributes. The ability to use ICADD-enabled documents directly, ie. with explicit conversion, is a big advantage.
By means of a special SDA attribute SDAEXPL the system can explain the meaning of the original element names, as well as provide the user with contextual information that helps him navigate the document.
ICADD is not without its problems, some of which are mainly technical and some of which are more of a political nature. We want to conclude this article by pointing to some of the areas where there is still room for improvement.
The description of SDA attributes included in ISO 12083 consists largely of examples. It does not include a formal syntax that permits ICADD processors to validate their input before processing it. The lack of a syntax significantly increases the risk of wrong or incomplete ICADD implementations. As part of the CAPS project, a syntax has been developed that is believed to accurately describe the syntax of SDA attributes. The plan is to submit the developed syntax to the ICADD technical committee, and the hope is that it will be accepted as accurate and distributed in the ICADD community.
As mentioned above, ICADD is mainly described by means of examples with accompanying comments and explanations. Unfortunately, the information available is not sufficient to resolve all ambiguities.
The lack of clear, well-defined semantics is severe, exactly because ICADD is intended to span individual applications. It is therefore very likely that an ICADD specification is not written at the same place as where the documents will be processed, as the intention is exactly to enable exchange of documents!
There is a big risk that the ICADD constructs will be interpreted differently by different people.
An example of the type ambiguities found in the description of ICADD can be found in ISO 12083 (p. 92). A part which describes ICADD's "basic location model" contains the following example:
<!ATTLIST SEC SDARULE CDATA #FIXED
"TITLE H1
[SEC>>TITLE] H2
[SEC>>SEC>>TITLE] H3
[SEC>>SEC>>SEC>>TITLE] H4"
It is stated in the text, that the above should be interpreted such that outer-level TITLE elements should be mapped to H1, TITLE elements in first-recursive-level SEC elements should be mapped to H2, and so on.
The specification does not provide the exact semantics of the above construct; specifically it does not say whether the attribute value should give precendence to left-most or right-most value pairs. The text of ISO 12083 implies that precedence should be given to right-most value pairs.
We contend that the most reasonable way is to read it left-to-right, and thus give precendence to left-most value pairs. This makes the example in ISO 12083 a bad one, since any element in an instance that matches "[SEC>>SEC>>TITLE]" will also match "TITLE" and thus be mapped to H1!
It is a question of design (and possible taste) whether it is more reasonable in this situation to read left-to-right or right-to-left. The problem is that it isn't clear from the description of ICADD which is the correct interpretation! This ambiguity greatly reduces the chances of compatibility of different ICADD implementations.
The above is just one example, but in our opinion, it illustrates a significant weakness of the current state of ICADD.
The 22 ICADD base tags are really a very minimal set of tags. In the experience of the CAPS project, there is a need for more fundamental tags, eg. a DATE tag and an INLINE tag.
There is some support within the ICADD mechanism for simple tables. The conversion from source SGML documents which include tables to the table model in the ICADD intermediate format is not without problems.
Certainly, it was an achievement that ICADD was incorporated into an officially sanctioned ISO publication. This will surely increase the awareness of the problems of information access for reading impaired, and help incorporation of SDA attributes in DTDs.
The inclusion in 12083 is not without its problems, however. The most serious, probably, is that with the inclusion of ICADD in 12083, it has become quite hard to improve or change the specification. In light of the problems pointed out above, this is a real problem.
We argue that, technically, the specification of ICADD was not ready for inclusion in ISO 12083, and that ICADD will probably want to revise the description of the ICADD transformation scheme, and possibly even revise the ICADD transformation scheme itself.
It is almost inevitable that ISO 12083 will become the place where most people will encounter ICADD, and so that description will be the most widely used and referenced. That way, ICADD risks being "stuck" with an inadequate specification of its transformation scheme. If ICADD chooses to update the ICADD transformation scheme, they can easily end up with two (possibly mutually incompatible!) ICADD schemes: "the ICADD scheme that people know about" (the one in ISO 12083), and "the ICADD scheme they really want people to use" (described in a document which is less easily available and therefore less known and used).
It is an interesting observation that the current ICADD base tag set is not unlike the tag set, called HTML, used in the Internet hypertext system called WorldWideWeb (WWW). For visually impaired people - using character-based WWW hypertext browsers such as Lynx - this potentially huge information source, is of great importance.
It is not unreasonable to speculate that HTML might replace the ICADD base tag set. This might have benefits such as:
HTML is quite similar to the ICADD base tag set
HTML has become a well-known and widely used format on the Internet
just like the ICADD intermediate format, HTML is quite simple and has a flat structure
Some contacts with the developers of Mosaic (the most widely used WWW hypertext browser) have been made by the ICADD Technical Subcommittee to highlight the needs of the print disabled users and to try to influence the further development of the coming HTML+ DTD.
The approach ICADD has chosen, to stick to a simple intermediate format and devise a simple scheme that enables SGML users to specify how documents that conform to their DTD are to be mapped onto the ICADD intermediate format, has proven to be quite powerful. In its simplicity, however, the ICADD conversion scheme does have limitations; it is not a general conversion technology that can map information in any DTD into the ICADD tag set in a useful way. That kind of flexibility is currently only offered by full programming languages such as OmniMark.
Still, the approach chosen by ICADD does seem to be a good one, despite its lack of full generality. The problem that ICADD faces is not only technical, it is also political and organisational. Improving access through the use of the ICADD intermediate format will only happen if information owners and publishers choose to support it; ICADD depends on the DTD developers to specify the mapping onto the ICADD tag set. By using architectural forms for the specification, ICADD reduces the perceived complexity of specification development; and the same time this development - by having the specification be physically part of the DTD - it is stipulated to be an integrated part of the DTD development itself, thus presumably increasing the chances of support from the DTD developers.
At pointed out in the previous section, technical problems remain, not least with regard to the technical description of the DTD. Because ICADD necessarily spans local SGML applications, it is absolutely essential that the specification mechanism is clearly defined so the specification constructs are used consistently, both by those who develop the specifications, and by those who implement ICADD-based processing mechanisms. However, the inclusion of the SDA attributes in the DTDs in ISO 12083 - a major ICADD result - impedes revision of both the transformation mechanism and its technical description.
The ICADD is a worthwhile initiative. The potential of SGML to improve information access for print disabled is enormous, and the technique proposed by ICADD clearly has the potential to increase the amount of information readily available to the visually impaired.
"International Committee for Accessible Document Design", Handed out at SGML '93 in Boston; George Kersher and Yuri Rubinsky presented.
"ISO 10744:1992", Hypermedia/Time-based Structuring Language (HyTime).
"ISO 12083:1993", International Organization for Standardization, A.8 Facilities for Braille, large print and computer voice (p. 82-97)
"The Functionality of SGML and its Related Standards for Applications for the Print Disabled", J.J. Engelen and B. Bauwens, Proceedings of SGML Europe '93 Conference, Rotterdam, 9-12 May 1993.
"Large Scale Distribution of Text Information: The Harmonisation and Standardisation Efforts of the TIDE-CAPS Consortium", J.J. Engelen and B. Bauwens, Proceedings of the ECART2 Conference, Stockholm, 26-29 May 1993.
"Structuring Documents: The Essential Step in Accessible Text Production for Reading Impaired Persons", J.J. Engelen, B. Bauwens, F. Evenepoel, C. Tobin, T. Wesley, Proceedings of the Ninth CSUN Conference on Technology and Disability, Los Angeles,-19 March 1994.
"SGML - And Enabling Technology for the Reading Impaired", B. Bauwens, J. J. Engelen, F. Evenepoel, C. Tobin, T. Wesley, Proceedings of SGML Europe '94 Conference, 16-19 May, 1994