[html4all] ACRONYM and ABBR

[Gregory J. Rosmaita]

aloha, rob!

thanks for your insightful comments and feedback...  (although at this
point, i expect nothing less from you!)

my initialisms versus abbreviations proposal is actually quite old,
the plan having been to submit it as a suggestion for XHTML2, but 
then the MarkUp activity split in two, and so i ported my concerns 
to HTML5...

i realize that it is rather inconsistent of me to advocate 2 
abbreviated forms, especially since i have been a vociferous advocate 
of deprecating BLOCKQUOTE and having a single QUOTE or Q element, with 
the rest left to styling. as explained in:

http://esw.w3.org/topic/HTML/MuchAdoAboutQ

also, i should have cited the excellent "executive summary" of the 
abbreviated form issues, as logged in:

http://esw.w3.org/topic/HTML/AbbrAcronym01

i am not opposed to dropping the request/recommendation for a new 
element -- IABBR -- which would have superseded ACRONYM (and could have
been mapped to ACRONYM for backwards compatibility), as long as the types 
suggested for IABBR are ported to ABBR...  perhaps, in the spare time i 
don't have, i will be able to re-articulate my position using but a 
single element, ABBR to cover abbreviated forms of all types...

as for default acronym/abbreviation expansion, such as that discussed for 
NATO, i am wary of the "tower of babel" phenomenon, where use and custom
in one natural language differs greatly from another (think of the UK, 
US, canada, australia, and new zealand as 5 countries separated by a 
common language), unless such a default is defined in an external 
resource (akin to a stylesheet) so that an expansion is available for 
all abbreviated forms, no matter how "common" or "universal"

gregory.
---------------------------------------------------------------
DELIBERATION, n.  The act of examining one's bread to determine
which side it is buttered on.
                         Ambrose Bierce, The Devil's Dictionary
---------------------------------------------------------------
           Gregory J. Rosmaita: oedipus at hicom.net
  United Blind Advocates for Talking Signs: http://ubats.org/
---------------------------------------------------------------

---------- Original Message -----------
From: Robert J Burns <rob at robburns.com>
To: HTML4All <list at html4all.org>
Sent: Sun, 27 Apr 2008 17:38:12  0200
Subject: Re: [html4all] ACRONYM and ABBR

> HI Gregory,
> 
> I like the wiki article you cite. It has some valuable examples 
> and  some forward looking approaches.
> 
> You won't get any disagreement from me on the need to markup 
> these  abbreviations and initialisms. In the examples that Leif 
> and I  discussed (e.g., NATO) it was my contention that this 
> would not need  markup because it is an abbreviated form that 
> does not share the same  ambiguities as for instance 'Dr.' in 
> the example you gave. Of course  this implies that authors and 
> authoring tools need to be careful to  ensure that any 
> potentially ambiguous abbreviations are marked up  properly. A 
> look at Wikipedia shows their are indeed some possible 
>  alternative expansions[1], though wikipedia directs NATO the 
> obvious  NATO without first using the disambiguation page[2]. My 
> contention  then is that we should be striving for a situation 
> (with proper UAs in  place) where NATO for the treaty 
> organization could be authored into a  document without markup 
> while using NATO for any other meaning would  need markup. Of 
> course using markup would be the safest approach in  any event.
> 
> The wiki article you cite also nicely complements the work I put 
> into  the wiki article on definitions and abbreviations[3]. That 
> article  just cited does not anticipate the need you nicely 
> highlight for a  cross document referencing approach. However, 
> it does suggest the need  for the opposite as well: that is a 
> way to scope the abbreviations  within the same document. This 
> scoping could be especially necessary  when a page includes 
> multiple articles by separate authors using the  same 
> abbreviations and defined terms, but in different ways.
> 
> Next, I feel strongly that another new element is not needed for 
> this.  I think a better approach than adding an IABBR element 
> would be to use  the existing ABBR element and to attach the 
> newly proposed attributes  to that element. In this way, the 
> type attribute could default to 'non- initialism'. While the 
> expressed as could default to  'character' (perhaps).
> 
> I guess this goes a bit against the point that abbreviations are 
>  abbreviations and initialisms are initialisms, but I do not see 
> what  might be the problem with treating them all as abbreviated 
> forms  
> (though with semantic differences as indicated through the type  
> attribute). For me this makes sense even in the abstract. 
> However,  given the goals of HTML5 I think there are further 
> reasons to avoid  introducing a new element and using new 
> attributes instead. In terms  of backwards compatibility with 
> existing user agents, the introduction  of new attributes has no 
> issues and the attributes get added correctly  to the DOM in 
> every major browser. On the other hand with new elements  each 
> of the three or four major browsers handles elements 
> differently.  These new elements would work in Presto and WebKit 
> and fail in IE and  Mozilla (until those UAs could be updated). 
> So these element problems  provide yet another reason to 
> introduce new attributes here rather  than new element or 
> elements. However, I would say again that I think  the use of 
> the ABBR element while distinguishing semantics further  through 
> additional attributes is a nice fit for what you're proposing.
> 
> Take care,
> Rob
> 
> [1]: <http://en.wikipedia.org/wiki/NATO_(disambiguation)>
> [2]: <http://en.wikipedia.org/wiki/NATO>
> [3]: <http://esw.w3.org/topic/HTML/DefiningTermsEtc>
> 
> On Apr 27, 2008, at 5:02 PM, Gregory J. Rosmaita wrote:
> 
> > aloha!
> >
> > the "title" element is ESSENTIAL and MUST be REQUIRED for ABBR
> > for the #implied mechanism not only doesn't work, it is illogical
> > when applied to abbreviated forms, as there are many abbreviated
> > forms that share the same combination of letters, but which represent
> > completely different words/concepts:
> >
> > ADA can be expanded to:
> >
> >  * Americans With Disabilities Act
> >  * American Dental Association
> >  * American Diabetes Association
> >  * American Dietetic Association
> >  * the programming language "ADA" (named for Ada Lovelace)
> >
> > what is needed, therefore, to make "title" an OPTIONAL attribute --
> > AFTER the first REQUIRED declaration of an ABBR -- is a FOR/ID  
> > mechanism
> > for reuse of the expansion for the abbreviated form; moreover, there  
> > are
> > thousands of acronyms that overlap, as discussed in:
> >
> > HTML Needs Initialisms:
> > http://esw.w3.org/topic/HTML/AbbrAndInitialisms
> >
> > the same re-use problem applies to DFN as well -- if one encases
> > an abbreviated form in an abbr without a title, but encases the
> > ABBR in a DFN element, then it is the DFN element that needs a
> > reuse mechanism, and the optimal solution is not JUST the use
> > of title for both, but a reuse mechanism that is universal, not
> > merely document specific...  the first instance of an ABBR or DFN
> > MUST be glossed with an expansion via the "title" attribute, as
> > well as an ID so that further incidents of the ABBR or DFN can be
> > bound to an initial expansion; obviously, a means of referring to
> > an external resource containing a site-wide table of abbreviation
> > and definition expansions is a superior mechanism and that is the
> > issue upon which we should be concentrating...
> >
> > gregory.
> > ------------------------------------------------------
> > It is better to ask some of the questions than to know
> > all the answers.                      -- James Thurber
> > ------------------------------------------------------
------- End of Original Message -------