- From: Charles McCathieNevile <charles@w3.org>
- Date: Fri, 5 Jan 2001 08:25:59 -0500 (EST)
- To: Al Gilman <asgilman@iamdigex.net>
- cc: WAI GL <w3c-wai-gl@w3.org>
OK, I get it and it makes sense to me too... Chaals On Thu, 4 Jan 2001, Al Gilman wrote: 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 > -- Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 134 136 W3C Web Accessibility Initiative 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 Friday, 5 January 2001 08:26:00 UTC