bottom-up look at son-of-ABBR

[this is from an exploratory discussion (not consensed position, but informed
by past PF experience) to the HTML WG.  Jens said 'abbr' is too narrow to
absorb the use cases of 'acronym.'  In the view of the HTML WG it is not.  In
XAG we suggest a) do make your markup names suggestive of the meaning, yet 
b) never
rely on the heuristic value of the markup name as the definition of the 
construct.
It is reasonable, at the cost of re-training pain, to redefine 'abbr' to 
fit all
uses of 'abbr' and 'acronym' in the past.  Anyhow, here is a sample (to be 
followed
by another, more top-town post from Matt) from our attempts to negotiate a 
better
future in this area on your behalf.  -Al]
--

on the product:

I submit that there are plenty of use cases in DI and WAI that qualify
abbreviations and their expansions as 'conditional content' in the language
of the UAAG10.  I have tried to substantiate that below.

[...]

-- details follow

[...]

Let me try to establish that abbreviations, the choice of when to use
them in presentation, and their synonymous relationship with their expansions,
are a 'posterkid,' a 'classic' case of what WAI wants from XHTML2 -- markup
that exposes a *content* model supportive of *later* decisions for the purpose
of the adaptation of presentation.

I mean... what can I say?

You have heard the expression "say what you mean, not what to do with it"?

In terms of those memorable words, 'lookup' is precisely "what to
do with it."  We don't need any more content models designed around one use
case.

Consider another appearance of the abbreviation concept in HTML4:

<quote
cite=
"http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#adef-abbr">

    abbr = text [CS]
           This attribute should be used to provide an abbreviated form of
           the cell's content, and may be rendered by user agents when
           appropriate in place of the cell's content. [...]
</quote>

This specification language makes it clear that html4:th.abbr creates 
"alternate
content" which in UAAG we have appropriately generalized to "conditional 
content"
just as html2:img.alt does.  So at least this instantiation of the 
'abbreviation'
concept in the minds of the spec authors involves content selection.  And I
submit that the practice of using html4:abbr.title to provide an expansion for
html4:abbr.content is for all practical purposes the same relationship in 
reverse.

What I would nominate as a possible content model for the abbreviation 
relationship
is as follows:

There are two things, A, and B

A isA string
B isA string
lengthInCharacters(A) << lengthInCharacters(B)
denotationalValue(A) = denotationalValue(B)

If these things are satisfied, then colloquially we would say

A is an abbreviation for B
B is the expansion for A

Consider the button bar in your browser.  It has presentation options.  The
presentation options in many cases are: string, image, or image+string.
This is content selection, it is deliver-context-driven adaptation.

I am not trying to get to ultimate truth, here about what is 'content.'  I
mean *in the persistent 'source' XML representation* the image and the text
are in separate data forks in the XML infoset.  But all three presentations
have the same denotational function.  We need to capture the range of choice
that captures the necessary population constraints so that the intended
notion *does* get presented *somehow.*

Consider the standard editing practice of presenting the abbreviation as
an annotation on the expansion at the first instance, and the abbreviation
in lieu of the expansion thereafter.  This is content selection.  There
are both the short and long strings.  After initializing the users' recall
with the bond between them, the short one is used to allude to the long one.
This is context-dependent content selection.

In addition to supporting a 'expand on query' lookup function for 
abbreviations,
would it not make sense to automate, or 'push' the display of the expansion
the first time an abbreviation is visited, when a Web visitor arrives at an
internal anchor in the resource and hence cannot be presumed to have ingested
the abbreviation's denotation?

[...]

In Device Independent authoring and view extraction, the short and long
forms are conditional content.  On a big-screen desktop one will format a
left-column navigation bar with full-image icons plus the long text forms.
On a WAP1 tinyBrowser, one will use either the short text abbreviation or a
line-drawing simplified icon.

The XML Format in which the content fragments are stored needs to know,
conclusively, that all these alternative content items (they will be in
parallel data) are used as indications of the same thing.  And that the
view-formulating scripts [general sense] may pick and choose among them
as appropriate.

The screen reader or other assistive technology on the client's computing
platform needs access to the full content model to make the same sort of
view-adaptation decisions as the DI adaptation engine is making [typically]
on the server side.

In particular, in the screen-reader delivery context, there are a number of
behaviors, and we need to have the content cues to guide the client-side
decision as to which of these to follow (in combination with user cues such
as mode settings for general rules):

- replace the text with a sound in an associated:
  .. sounds-like text
  .. audio file, or
  .. phone-stream
- pronounce the element content text as if a word in the current xml:lang value
- spell out the element contents
- say the words in an associated expansion

The choice will be guided by client-side information as to

- is the text being rendered in Braille or audio?
- has the user selected vebose or terse explanation?

Note that achieving the full range of "behaviors that should be selectable"
it take a blend of "conditional content" data and "rendering" perturbations
on presentation of the data.

- speaking the expansion selects conditional content
.while.
- spelling the element content uses a 'spell' mode control in the TTS
rendering engine

An optimized screen-reader UI would have verbosity mode controls comparable
to what the standard digital talking book provides that govern the handling
of abbreviations vs. expansions in the [push] presentation [plus embedded
pull opportunities].  A similar range of modes should be available
concerning the expansion of terms, be they abbreviations or jargon, to
readers in a second language, or a second discipline.

  http://www.niso.org/standards/resources/Z39-86-2002.html#Skip

Lookup is a behavior, a use case.  It is the appropriate display-control
protocol in a common delivery context.  But it is not a 'pure' content model
and it is not the appropriate behavior in all delivery contexts for the same
content model, that is to say for the same semantic relationship between two
content fragments.

To support adaptive presentation that adapts appropriately across
diverse delivery contexts, including the disability cases as a natural
part of the built-in flexibility, we need tools for both parallelizing
the content and tuning the presentation transform.  [content selection
is one of the capabilities supporting tailoring the composed adapted
view.]

We need content markup that clearly characterizes conditional content so
that the device-adaptive server and the content-reprocessing Assistive
Technology have the control degrees of freedom and data alternatives they
need to achieve a) a functional or b) a commercially competitive presentation.

[...]

Best regards,

Al

Received on Wednesday, 25 February 2004 10:41:14 UTC