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

[Nathalie Sequeira <n@n-faktor.net>]

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