RE: [docbook-apps] acronyms, abbreviations, definitions

["Rowland, Larry" <larry.rowland@hp.com>]

Hello Nathalie,

A couple of things:

  1) You don't have to have a single glossary database for all your documents.
     It is quite reasonable to break it up into glossaries that are topic-appropriate.

  2) Title was what the W3C consortium recommend at one time for the expansion.  I have
     not kept up with it for a while, since dropping out of the accessibility police in
     the writing group I worked with.  If you want to have other behavior, such as
     expanding it inline, it is a matter of slightly different coding to make it work.
     I have noticed that there is a lot of variability in what screen readers actually
     do with the same source markup and find that somewhat frustrating.  It is similar
     to the CSS wars among browsers in the early days of CSS (when we had to use a 
     JavaScript to load the appropriate CSS file based on the platform and browser
     being used (and even version of browser in some cases).  There is some chatter on
     the Web that indicates using acronym vs. abbr can lead to different behavior for
     the title.

  3) If you are worried about the size of a glossary database, the same thing can be
     done with a glossary section in a book (or other document).  The downside is that
     you have to repeat the glossterm in each document it is used in, but the upside is
     you can customize the glossary appropriately in a manner appropriate to a specific
     context.  I wrote a simple script to extract terms from a master glossary and
     add them to a glossary which was then made part of the book itself, rather than
     using the glossary database (specifically to avoid problems with render time and
     creeping changes in a glossary -- you don't always want the most current version
     of glossary entries every time a document is built).

  4) The expansion was added to the acronym element, as recommended by W3C for 
     expansion of acronyms.  A title on the anchor element (the a) would be associated
     with the link destination rather than with the acronym.

As a friend of mine frequently says, "I admire your problem." 

Good luck solving it.

Best Regards,
Larry Rowland

-----Original Message-----
From: Nathalie Sequeira [mailto:n@n-faktor.net] 
Sent: Thursday, November 11, 2010 7:47 AM
To: docbook-apps@lists.oasis-open.org
Subject: Re: [docbook-apps] acronyms, abbreviations, definitions

Hi Larry,

> The advantage of storing it centrally in the glossary is that the expansion doesn't have to be added to every instance of the acronym (while convention says it only needs to be expanded at "first occurrence," in electronic media, determining the "first occurrence" for a reader can be difficult so we frequently used an acronym tag the first time an acronym was used in a topic).  It also provides a mechanism for explaining what the expanded acronym means, since expansion is not always sufficient to explain why it matters.
>   
At first I found the prospective offered by the glossary database 
feature rather enticing, exactly because of the repetitiveness (during 
the production phase) of adding the extended version  - ideally to each 
- instance of an abbreviation/acronym.

So the idea of having an external glossary that is run over a text in 
which the acronyms/abbreviations are also marked as glossterms (which, 
when explanation is necessary, can also be linked to a "real" glossary - 
slick!), and xslt'ing the lot into nicely formed, fully functional 
XHTML-Elements would be something that could greatly enhance the reading 
experience of online versions, while in PDF/print versions, just the 
classical glossary could be output...

However, the question arises for me how viable this is when dealing with 
a very large text base.
(in my case I'm working on a growing online library with currently 1600 
texts - from short articles to whole books - dealing with diverse 
aspects of "disability" on a variety of levels).
- I'd be afraid that the glossary itself would soon grow to dimensions 
that are not so easily to be edited anymore.
- And, as I understood it, the text is processed in loops for each 
single glossary term (even if 3/4 of them are not relevant for the text 
in question). Since our HTML-versions are cached, this would not happen 
every time the pages are loaded, but  still... wouldn't that create an 
enormous processing overhead?

Asked the other way around, how large is the text base you apply this 
technique to?

Also, I'm  not sure about how your output looks:
> Getting expansion on hover or similar is slightly trickier, but not a major stretch (the match to the glossentry is already being made by the extended glossterm auto link code) by adding a title attribute with the content of the glossterm to the anchor element around the acronym in the output (at least in HTML).
Do I understand rightly that you are adding the expansion as a title to 
the  <a> element?
I hate to say so, but I am just currently being made aware of the fact 
that "title" does not work reliably on links in screen readers.
Apart from the fact that the expansion is no longer attributed to the 
acronym itself, but rather becomes additional information about the 
content being linked to...
So what may look the same for sighted people is a completely different 
(and possibly invisible) creature for screen reader output.
This mechanism should thus actually insert the glossterm into acronym to 
make it fully functional (perhaps only creating the glossary link when 
there is, in fact, an additional explanation...).

Thanks for the interesting input :)
Nathalie




---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org