terms for pictures and such (both coarse and fine categories, related)

This is a bit heavy going, but I haven't found time to make it simple.  I hope
this helps a little to make what I meant clear.

At 12:49 PM 2001-01-04 -0500, Charles McCathieNevile wrote:
>On Thu, 4 Jan 2001, Al Gilman wrote:
>
>  At 09:47 AM 2001-01-04 -0500, Charles McCathieNevile wrote:
>  >How about using 'illustration' and 'decoration' as the two terms. It makes
>  >more sense to me that we describe a table as an illustration of a point
(or
a
>  >paragraph of text, for that matter) than describing an image as an
exhibit.
>  >
>  >(except in courtroom drama <grin/>)
>  >
>
>  AG::
>
>  No.  You miss the point.
>
>  We need the unfamiliar concept, for which this is the most familiar term.
>
>  You are trying to arrive at a partition composed entirely of colloquial
>  terms.
>
>CMN:
>I'm not sure what you mean by a partition. I am trying to arrive at a series
>of documents that people can use and understand without looking up the
>definitions section any more than they really have to.
>
>It is worth being explicit in the definitions sense that we are using a rich
>(but common) meaning for a term, and not a narrow one, if that is the case.
>
>Besides, we use the verb "illustrate" to mean 'expand upon using graphics,
>sound, whatever it takes' in a checkpoint, with text that makes it clear.
>
>In other words, I'm trying to keep the language clear and simple, and think
>illustrate / illustration does it better than exhibit. It still allows us to
>be readily understood with the meaning we have, and we can reinforce that
>with an explanantion of what we mean in the glossary.
>

AG::

'illustrations' belongs in our working vocabulary.  'exhibits' belongs in our
working vocabulary.  Quote "_the_ two terms" unquote does not belong in
what we
think we have _decided_.  It is too soon to know how many terms will be
required in the end to say what we need to say.

1.  I have no problem with calling illustrations 'illustrations.'  That wasn't
what I said at all.  I do have a problem thinking we an get authors to call
tables 'illustrations.'  But not to get their editors to call tables
'exhibits.'  That's how they talk already.

2.  As it turns out, we can't write the total corpus of documents we need
(clearly) without using overloaded terms, that is to say using _both broad and
narrow terms_ in talking about _the same thing_ _in different contexts_.

You invoked the image of a partition, and gave the idea that 2. above was not
true, when you used the definite article 'the' in "the two terms."  In
particular, this was not responsive [did not correspond] to my request to
insert (i.e. add) a more abstract notion into our working ideology.  I didn't
say "call _the_ category 'exhibits'."  I said "Please, let's _think_ in terms
of _a_ more abstract 'exhibits' category _as well_."

I think it is fine to assert "illustrations and decorations are two kinds of
graphics that should be treated differently by the author."  I absolutely
object to saying "illustrations and decorations are _the_ two kinds of
graphics
that should be treated differently by the author."  We need to explore what
categories there are and what ways there are to handle them some more
before we
know how many categories are going to show up in the final explanation.

I claim [broken record] that we need both to let the author call their object
something that they can understand, like an illustration, and also have our
infrastructure (a.k.a. data model, dialect description document or profile)
provide the clear connection that illustrations so marked are members of some
broader class [like exhibits] for which we have asked the User Agent to
provide
some minimum set of method handlers.  The "graceful transformation" methods
are
likely to need these more abstract classes like 'exhibit' to cover the
waterfront of applications gracefully (and affordably).  This way our access
strategies don't break just because we introduce a new class of exhibits.  It
helps provide room for creativity and coping at the same time.

We need headroom for finding patterns within the problems we have with
different kinds of items.  I just asked to insert one of these generalizations
into the glossary along with the more immediately recognizable terms.  The
general page structure case includes sidebars as much as figures and tables. 
The sidebar is a story within itself, but has no one logical serial place in
the longer story in the background.  A sidebar is the same kind of stuff as
the
background story, but not an ordered part of a common narrative thread.  [the
electronic book model forces us to pick some global linear order, but this is
not actually the semantics of the content.]  Equations and diagrams, on the
other hand, reflect changes in the pallette of what kind of stuff can go in
there.  We need a document and site composition model that deals with both of
these kinds of distinctions.

A case currently at point has to do with WCAG-required patterns of equivalence
among content fragments, and how the User Agent should provide connected,
related, or in-context access to these fragments [see Checkpoint 2.3 in the
latest draft.]  The point is that while the WCAG requires the _author_ to make
these alternatives _equivalent_ in their (after human processing)
communicative
effect, it doesn't require the formats to provide _dedicated_ content control
mechanisms for disability access or for 'equivalents' required under the
WCAG. 
It only requires the author to employ the content control mechanisms that the
format defines, so the user will have the opportunity to tune the presentation
to meet their needs.  The User Agent completes the strategy by ensuring that
"content control" means "user control."

The User Agent should give all users full control (and efficient, in the sense
of making the relatedness of the options obvious) over the ultimate outcome of
the content-control features defined in the formats.  The access methods
should
be keyed to "content control structures," not "WCAG equivalents structures." 
It is the former, and not the latter, that the formats define.  Content
control
is actually a _protocol_ supported by option structures in the formats.  The
user agent requirement is to make sure the user can control the end result by
some mechanism.  It can be interactive or by configuration only or whatever. 
See the UAAG for details.  But the point is that the user agent methods attach
to the more general class of "content control" structures, not specifically to
just the equivalents that the author put there for disability access reasons.

Al

PS:  The term 'non-linear' is too narrow.  We need to get beyond 'single
threaded' vs. 'other.'  Most of the rhetoric of page design is "multi-linear,"
not "non-linear."  There is more than one thread weaving through the bag of
contents.  Almonst nothing is in there that doesn't participate in one plot
thread or another.  Some of the pieces participate in more than one.

>cheers
>
>chaals (although I may have still missed your point, in which case please
>explain again)
>
>AG
>  Among terms in common use, you get a lattice, a taxonomy, and not a
>  partition.
>  And the concepts that we need extend up and down into abstractions and fine
>  distinctions beyond what is colloquial, i.e. people don't _ususally_ speak
in
>  terms that broad or that narrow.
>
>  Our vocabulary has to include overlaps, generalizations, and
specializations;
>  and both familiar and unfamiliar concepts.  We need to connect with the
rich
>  redundancy of actual common usage, and relate the uncommon notions we need
to
>  get on with our job well to what is already there in the common notions.
>
>  We need the non-colloquial sense of 'exhibit' from the tech editor
>  community to
>  complete our thinking about how the layout responds, because the
interaction
>  with algorithms should probably be at this "not so natural to say" level.
>
>  It's a compromise with the small brain power of computers.  And it is the
>  general nature of how we can actually get the idiot computers to do smarter
>  things.  Only ask them to do things a little smarter.
>
>  Al
>
>  >chaals
>  >
>  >On Thu, 4 Jan 2001, Al Gilman wrote:
>  >
>  >  At 11:45 PM 2001-01-03 -0800, Kynn Bartlett wrote:
>  >  >At 04:56 AM 1/3/2001 , Marti wrote:
>  >  >>Regarding the use of graphics, I would like to see some changes in the
>  >  >>terminology used.  Graphics is too generic a term and I doubt that
Anne
>  >  >>really wants two different sizes of all the 'decorative' stuff.  How
>  about
>  >  >>we call the images used to augment text "illustrations" to distinguish
>  their
>  >  >>purpose?
>  >  >
>  >  >This is a good idea, as it clearly identifies a _function_
>  >  >rather than a specific set of _formats_.
>  >  >
>  >
>  >  AG::
>  >
>  >  Please book the term 'exhibit' into the lingo.  This is borrowed from a
>  common
>  >  term referring to both figures and tables, but as intended it includes
>  set-off
>  >  equations as well.  Just the other day I discovered that we
shouldconsider
>  >  logos to be in this class.
>  >
>  >  This serves as a superclass for illustrations and other items that enter
>  into
>  >  the formatting logic in a similar way.
>  >
>  >  Al
>  >
>  >  >--Kynn
>  >  >
>  >  >--
>  >  >Kynn Bartlett  <kynn@idyllmtn.com>                   
>  > 
<<<http://kynn.com/>http://kynn.com/><http://kynn.com/%3E%3Chttp://kynn.com/
%3Ehttp://kynn.com>http://kynn.com/><http://kynn.com/>http://kynn.com/
>  >  >Sr. Engineering Project Leader, Reef-Edapta      
>  > 
> 
<<<http://www.reef.com/>http://www.reef.com/><http://www.reef.com/%3E%3Chttp
://www.reef.com/%3Ehttp://www>http://www.reef.com/><http://www.reef.com/>ht
tp://www
>  .reef.com/
>  >  >Chief Technologist, Idyll Mountain Internet  
>  > 
> 
<<<http://www.idyllmtn.com/>http://www.idyllmtn.com/><http://www.idyllmtn.c
om/>http://www.idyllmtn.com/><<http://www.idyllmtn.co/>http://www.idyllmtn.co
>  m/><http://www.idyllmtn.com/>http://www.idyllmtn.com/
>  >  >Contributor, Special Edition Using XHTML    
>  > 
> 
<<<http://kynn.com/+seuxhtml>http://kynn.com/+seuxhtml><http://kynn.com/+seu
xhtml>http://kynn.com/+seuxhtml><<http://kynn.com/+seux>http://kynn.com/+seux
>  html><http://kynn.com/+seuxhtml>http://kynn.com/+seuxhtml
>  >  >Unofficial Section 508 Checklist          
>  > 
> 
<<<http://kynn.com/+section508>http://kynn.com/+section508><http://kynn.com/
+section508>http://kynn.com/+section508><<http://kynn.com/+>http://kynn.com/+
>  section508><http://kynn.com/+section508>http://kynn.com/+section508
>  >  >
>  >
>  >
>  >--
>  >Charles McCathieNevile   
<<mailto:charles@w3.org>mailto:charles@w3.org><mailto:charles@w3.org%A0%A0%
A0>mailto:charles@w3.org   
>  phone: +61 (0) 409 134 136
>  >W3C Web Accessibility Initiative                     
> 
<<http://www.w3.org/WAI>http://www.w3.org/WAI><http://www.w3.org/WAI>http://
www.w3.org/WAI
>  >Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
>  >until 6 January 2001 at:
>  >W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
>  France
>  >
>
>
>-- 
>Charles McCathieNevile    <mailto:charles@w3.org>mailto:charles@w3.org   
phone: +61 (0) 409 134 136
>W3C Web Accessibility Initiative                     
<http://www.w3.org/WAI>http://www.w3.org/WAI
>Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
>until 6 January 2001 at:
>W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
France
>

Received on Thursday, 4 January 2001 21:50:43 UTC