SGML for access: Yes/No

for readers who do know something about access technologies but do not know much about SGML

So let's talk about SGML. The acronym stands for Standard Generalized Markup Language. It's a means of using ordinary ASCII text – what you get when you type away on your computer without adding font specifications or changing the point size or underlining or italicizing anything – to "mark up" other text according to its structure.

The issue of structure (or function) is critical to SGML. We'll define this by example. Let's think of all the ways we can use italics in ordinary English text (which, in the following examples, all make use of the HTML <i> tag for simplicity):

• Simple emphasis: I told you to turn left, not right.
• Introduction of a new term: The tiny claws on a cat's inner forepaw that correspond to human thumbs are called dewclaws.
• Names of certain artworks, like films, TV shows, records, books, and plays: Gee, the school play this year is Our Town. What a surprise.
• Foreign words: Jeff Adams, as a red-haired paraplegic wheelchair racer, is clearly sui generis.
• Names of ships: My taxi ran late and I never made it aboard the Hindenburg. I have made it a point never to rush taxi drivers since then.
• Editorial annotations, as in plays:
  Sgt. Matthews (to Rosie): Ma'am, I'm sorry to have to tell you this–
  Rosie (blinking back tears): Johnny's dead, isn't he?

You could think of other uses for italics, I'm sure. Now, the point here is that one overt form – italic type – is used to denote a wide range of structures or functions. In SGML, we would typically try to keep those different structures distinct by using tags, or markups. Tags generally take the form of a word written between angle brackets, like <emphasis> or <title>. To continue with the example of italics, we could use SGML to define various structures that correspond to our uses of italics. (The beauty of SGML is that, while a great many structures are already defined and ready to use, we can define our own structures at will.) We could create tags like:

<emphasis> </emphasis>
<terminology> </terminology>
<title> </title>
<foreign> </foreign>
<ship> </ship>
<annotation> </annotation>

(We use a slash / to turn a tag off. Not all tags need to be turned off, but in this case they all do.)

We could then rewrite our example sentences as follows:

• I told you to turn <emphasis>left</emphasis>, not right.
• The tiny claws on a cat's inner forepaw that correspond to human thumbs are called <terminology>dewclaws</terminology>.
• Gee, the school play this year is <title>Our Town</title>. What a surprise.
• Jeff Adams, as a red-haired paraplegic wheelchair racer, is clearly <foreign>sui generis</foreign>.
• My taxi ran late and I never made it aboard the <ship>Hindenburg</ship>. I have made it a point never to rush taxi drivers since then.
• Sgt. Matthews (<annotation>to Rosie</annotation>): Ma'am, I'm sorry to have to tell you this--
  Rosie (<annotation>blinking back tears</annotation>): Johnny's dead, isn't he?

Why would we want to go to all this trouble? Well, having marked up or tagged our text according to structure, we could let the interpreting program decide how to format it. This concept will be familiar to you from using Web browsers, which interpret HTML, a bastardized subset of SGML that underlies all Web pages. If you've ever looked at HTML text directly, you'll know that it's a complicated mass of <s and >s and formatting codes. But when that mishmash is read by a program like Lynx or Netscape, it's turned, in ideal cases, into a visually appealing and semantically meaningful design, with typographic attributes, spacing, graphics, and the like.

In the examples above, if whatever program you were using understood SGML, you could command your program to use italic characters for emphasis, foreign words, and titles, but not for annotations or ship names. Or if you were more concerned with spotting all the foreign words in a document (let's say you were trying to simplify it), you could set up the <foreign> tag to be displayed in a large font.

Also, you can search for and replace these tags, or otherwise manipulate them. And this is where we begin to see relevance in access issues. Let's continue with our example of italics. In captioning in North America (sorry, in quality captioning), captioners use italics for all the traditional applications in print typography, but also to denote interior monologue (thinking), narration, and offscreen speech. But not all captioners have exactly the same overt form. Sometimes, as in a nature documentary where the only human speech is from a narrator, italicizing every caption is seen as unnecessary, and an explicit annotation is used instead:
Narrator:
[NARRATOR]
[ Narrator ]

If our caption file were saved in SGML format with, say, a <narration> tag and a full suite of other tags (this is not a piecemeal approach I'm talking about), we could do various things:

• Tell the software to render narration in italics, as in a documentary where other human beings speak using roman characters.
• Tell the software to render narration in roman characters prefaced by Narrator: on the line above (the Caption Center approach) with the same alignment.
• Tell the software to render narration in roman characters prefaced by [NARRATOR] on the line above (the NCI approach) with the same alignment. But since the NCI style allows explicit speaker IDs like [NARRATOR] on the same line as the actual words spoken by the narrator, the software could intelligently place the [NARRATOR] annotation either above the lines of text or at the beginning of the same line depending on how much space were available.
• Perform a transformation: Let's say the Caption Center captioned a program for first-run television but NCI captioned it for home video. (This has happened before – look at Star Trek: The Next Generation and The X-Files.) NCI could simply buy the SGML caption file from the Caption Center, and with a few software commands instruct the program to change all Caption Center formatting to NCI formatting. For example, lines could end in commas (they can't in Caption Center style), speaker IDs would look like [NARRATOR] and not Narrator:, and placement could follow NCI's peculiar rules instead of the Caption Center's peculiar rules.
• Perform a bigger transformation: The Australian Caption Centre has a contract to caption E.R. They buy the caption file from the Caption Center (preferably after the Caption Center fixes all the mistakes I find in nearly every E.R. episode) and, via a few software commands, transform the file into upper- and lowercase captions suited to the different number of frames per second in Australian TV. Also, italic and other formatting codes would be either stripped out (there are no italics in Australian captioning) or transformed (all <title> tags could take the overt form of single quotation marks, as in Gee, the school play this year is 'Our Town', but all <emphasis> tags could take the overt form of capitalization, as in I told you to turn LEFT, not right).

Now that you have some understanding of SGML, you may wish to look at other online resouces on the subject, like sil.org. Also try SoftQuad and the newsgroup comp.text.sgml.

You should now look at the Common Issues homepage.