Proposals: Abbreviations (including acronyms and Initialisms)

HI Gregory and all,

I'd like to start a discussion of some of the recent proposals for  
associating abbreviations (including acronyms and initialisms) with  
expanded forms. The Wiki now has two or three pages devoted to this.  
One page [1], Gregory recently produced as a distillation of another  
page on explicit patterns of association[2]. A second page I produced  
based on my and Ben Boyle's reviews of the phrase elements section. 
[3] A forth one dates back to the early days of the WG back in March  
and April [4]. The current draft represents yet another approach to  
these problems. [5] The HTML 4.01 represents still another related  
approach [6].

Looking at these various approaches, I think the suggestions in [1]  
and [3] provide the greatest advantages for authors and users alike.  
Both proposals provide much greater flexibility in explicitly  
associating abbreviations expansions with abbreviations and also  
allow authors to minimize the amount of syntax necessary to provide a  
rich interactive user experience. Both proposals support matching of  
abbreviations with their expansions. Both proposals provide a means  
to set pronunciations for abbreviations.

The biggest differences between the two proposals:

  •  Proposal [3] is also part of a {term and variable and proper  
noun}/definition association authoring approach
  •  proposal [1] suggests a separate 'iabbr' element  while [3]  
leaves abbr for all abbreviated forms: abbreviations, initialisms and  
acronyms. I'd be interested to hear what Gregory and others think  
about the need for this separate element. Both proposals include  
pronunciation hints and abbreviation expansion associations, so the  
state of the type of abbreviation is easily discernible from this  
information. What does a separate 'iabbr' provide for users or authors?
  •  proposal [3] suggests a new association pattern. In that  
proposal two elements, the abbreviation (abbr) and the expanded  
abbreviation (e.g., DFN) are associated first by the attributes  
DFN@abbr and ABBR@variantof. If the ABBR element has no 'variantof'  
attribute, then the contents of the element are used for matching  
instead. Proposal [1] instead uses the standard for/id pattern of  
association.
      • This means that proposal [1] requires more syntax to set the  
'for' attribute even when the contents of the element would make a match
      • Proposal [1] also can take advantage of the getElementById to  
provide an already mature and optimized method of association.  
Proposal [3] would have to rely on getting elements by their abbr  
attribute value which may not be a method as optimized as  
getElementById.
      • Proposal [1] also raises the issue of multiple homograph  
abbreviations within the same document. This is likely something  
authors should avoid, but I think its something that an interactive  
on-screen web page might be able to facilitate. The for/id  
association in proposal [1] facilitates these multiple homograph  
abbreviations while proposal [3] would require authors to use the  
'abbr' and 'variantof' attributes in more creative ways.
      • Proposal [3] unifies the approaches to associate terms,  
variables and proper nouns with their definitions on one hand and the  
association of abbreviations with their expansions on the other hand.
      • Proposal [3] also adds the ability to scope abbreviations and  
definitions so a single document that combines work by a number of  
authors can each have their own scope for definitions and  
abbreviation expansions.

One other difference that is subtle and may not even be there, but is  
worth discussing is the issue of where to use the abbreviation  
element. Proposal [3] suggests using elements for terms and  
abbreviations in specialized situations. Presumably we would then  
expect the user's UA to provide non-specialized pronunciation and  
abbreviation expansions: particularly according to the user's  
preferences (e.g., URL pronounced as U-R-L or Earl, SQL pronounced as  
S-Q-L or sequel) This would require authors to know when an  
abbreviation was specialized and when it was not. Of course the  
author could always opt to include abbreviation markup (or definition  
markup) whenever the situation could be potentially ambiguous.

Anyway, I'd especially like to hear from Gregory and others about  
these differences and hear from advocates of the current draft or  
HTML 4.01 approaches to abbreviation/expansion associations.

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/AbbrAndInitialisms>
[2]: <http://esw.w3.org/topic/HTML/ExplicitAssociationPatterns>
[3]: <http://esw.w3.org/topic/HTML/DefiningTermsEtc>
[4]: <http://esw.w3.org/topic/HTML/AbbrAcronym01>
[5]: <http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html? 
rev=1.78#the-abbr>
[6]: <http://www.w3.org/TR/html4/struct/text.html#edef-ABBR>

Received on Friday, 7 September 2007 08:09:11 UTC