Re: Question on abbreviations (fwd)

Even if it's impractical to retrofit a mass of old pages, it would be 
simple to define acronyms and abbreviations at all points in new documents 
as they go forward, especially if the authoring tools supported it (e.g. 
when you type in an abbreviation it lets you specify which meaning you 
meant from your presonal dictionary)

You could also imagine semi-automatic programs to go through existing 
documents popping up each substitution for approval, giving choice from a 
menu when there are alternatives.

As for the problems of using sed--a revered language which, however, knows 
nada about HTML--... you can get around all those problems by using Perl, 
which has e.g. specific ways to check word boundaries, together with a real 
HTML parser, e.g. HTML::Parser, which will make sure you're not messing 
around inside tags and such.  And there are probably equivalents in Java by 
now, tho I haven't looked.

So none of these difficulties should prevent us from requiring that all 
instances of an abbreviation or acronym be tagged.

And even if there were difficulties, I thought we were at this point only 
considering accessibility, and that we were going to discuss difficulty of 
implementation as it affects all guidelines later.  That's my understanding 
of our current process in GL.  I hope I'm right on that, because 
implementation difficulties apply to everything.

Len

At 09:24 AM 12/29/00 -0800, Matt May wrote:

>----- Original Message -----
>From: "Anne Pemberton" <apembert@crosslink.net>
> > >2) false positives
> > >"...causing a distributed <acronym title="Disk Operating
> > >System">DOS</acronym> attack..."
> > >"...a list of <acronym title="Disk Operating System">DOS</acronym> AND
> > >DON'TS..."
> >
> > This one I don't understand. Are you saying that if an acronym is linked
>to
> > it's definition at the bottom of the page or on a definitions page, it
> > sometimes will not work and there nothing can be done about it?
>
>If I have three different usages of "DOS" referenced in my documents, it's
>nearly impossible for someone to code up an application that's going to come
>up with the right definition programatically. Another reason why
>search-and-replace has trouble. It's brain-dead to context.
>
> > >3) unforeseen replaces
>
> > This is a perfect example of why the acronym must be defined by the
>content
> > provider rather than the user. How is the user supposed to choose among
>the
> > 20 acronyms for IF if they don't know what it means in the first place?
>
>Dictionaries have multiple definitions per word. I did also say that content
>providers could and should give guidance using either what's already there
>in HTML, or something RDF-based in the future to create custom dictionaries.
>
> > Matt, you make it sounds like the world of databases has been shuffling
> > along in need of direction for too long anyway. Remember Y2K?
>
>Quite the contrary. I think the last thing database administrators need is
>to be redirected. Not when I know that not a single one of them is going to
>be willing to adopt the "solution."
>
>----
>matt

--
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP and Dept. of Electrical Engineering at Temple 
University
(215) 204-2247 (voice)                 (800) 750-7428 (TTY)
http://astro.temple.edu/~kasday         mailto:kasday@acm.org

Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
http://www.w3.org/WAI/ER/IG/

The WAVE web page accessibility evaluation assistant: 
http://www.temple.edu/inst_disabilities/piat/wave/

Received on Friday, 29 December 2000 15:12:49 UTC