W3C home > Mailing lists > Public > wai-xtech@w3.org > February 2001

Raw minutes from 27 Feb 2001 WAI glossary group meeting

From: Ian Jacobs <ij@w3.org>
Date: Tue, 27 Feb 2001 18:01:15 -0500
Message-ID: <3A9C31BB.B1D8CC7@w3.org>
To: wai-xtech@w3.org

Raw minutes from today's meeting online [1] and quoted below.

 _ Ian

[1] http://www.w3.org/2001/02/27-glossary

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Reference document: [1]27 Feb draft of unified glossary

      [1] http://www.w3.org/WAI/GL/2000/12/unified-glossary

   Book: "Dictionary of Computer and Internet Terms"


   Wendy Chisholm (Chair), Al Gilman, Jason White, Katie Haritos-Shea,
   Harvey Bingham, Gregory Rosmaita, Ian Jacobs (scribe), Len Kasday,
   Judy Brewer,, Jutta Treviranus, Daniel Dardailler, Cynthia Shelly.


     * What do we do about document-specific definitions?
     * Is there one WAI glossary? Or one basic glossary from which
     * How to pare down number of definitions?
     * What definitions can we reuse from other sources (W3C specs,
       books, govt. laws, etc.)
     * What are conflicts with usage in/outside of W3C?
       JW: What about existing Web Content Glossary
     * Is this a W3C-wide exercise?
     * Should we have different glossaries (e.g., one jargony, one

   CMN: What other sources should we be using? The closer they are in
   terms, the more we should constrain ourselves to not deviate. Taking
   terms from legal an policy documents is tricky (e.g., for reasons of
   internationalization). I don't think legal docs a good source for our

   JW: Legal definitions are frequently the result of compromise, and
   exclude some individuals. We should look instead to disability

   Action CMN: Talk to Dan Brickley about getting words in WordNet.

   Action JW: Troll the ICADD materials.

   CMN: I think that this is a W3C-wide activity. Karl Dubost is the
   quality assurance Activity lead. He will be working on this.

   AG: Sometimes, what we need is an explanation, not a definition.
   are problems with different people reading a glossary and the way
   interpret the glossary.

   KHS: Some of the WAI glossaries are good at explaining, others are

   HB: I looked at some books in bookstores for the words
   and "usability". Few of them use the terms in the way we do. Our
   is not being used by the layperson in the same way.

   WAC: Should we adopt lay usage?

   HB: No, I think we should be educating the layperson.

   GR: Yes, some people think that "access" means "getting online". I
   don't think that we should try to define the term "accessibility".

   CMN: Having a glossary available will speed up our work. However, if
   we deviate from standard interpretations, we must make this known.

Should the glossary include terms from others specs?

   JW: I think we should refer to other specs. There is a process
   question, too: how will the glossary be developed on the cross-wg

   JB: I want to speak in favor of including definitions of basic stuff
   in a WAI glossary.

   IJ: I think that:
    1. Any group should be able to read from WAI glossary when they
       and should do so using the latest version of the glossary.
    2. To write terms to this glossary, WAI WGs have to go through the
       glossary group
    3. Don't try to address this at a W3C-level yet, but design a
       that can be reused for developing glossaries.
    4. Don't try to incoporate non-WAI terms; other specs are definitive
    5. Whether to link or to include is a decision by each WAI WG.
    6. Set of terms for everyone, but primarily for editors.

   CMN: Yes, I agree with Ian's point 1.

   KHS: What granularity should we be considering here? You should be
   able to have a printable version of a document that contains all the
   relevant information.

   /* Katie notes that http://www.w3.org/Glossary is empty and should be
   used for a W3C-wide glossary */

   AG: I wanted to know that having glossary entries as links in HTML
   makes the document chattery (lots of tab stops). I would look for
   to distinguish glossary links from run-of-the-mill links.

   HB: I noticed that many of the glossary terms in our documents have
   links to other terms. It should be possible to extract, from a
   combined glossary, that part that the user needs to read a specific

   LK: If you do have copies of external definitions (which I think is a
   good idea), there's a complication if it's part of a normative

   JW: One approach: don't include in this glossary terms that are
   particular to specific format or protocol. Have links to other specs
   for technique-level references to specific terms of a format or
   protocol spec. People working with a format or protocol should be
   capable of referring to those specs.

   JW: It is important to be able to extract the definitions of a
   glossary relevant to a given specification.

   IJ: I hear talk of extraction. My model is that you include (copy)
   terms from the glossary rather than just link to them. This means
   there is no issue about extracting from a separate resource. The
   editor has to decide which terms to include. I thought of the
   as first a resource for editors, and secondarily a repository for
   other people to refer to.

   DD: I disagree; I think there should be no duplication and people
   should link to the glossary as a separate resource.

   JB: If you extract something and the document you extracted from

   WAC: But references would be to dated versions.

   GR: We have different audiences. I would be wary about presuming that
   some readers will know what terms mean.

   IJ: In practice, people don't use our printable formats; they just
   print from their browsers, so that linking to definitions may not
   in practice.

   JW: I think that definitions should be copied from central glossary
   (and reproduced inline). I think that definitions from other W3C
   should not be included in the central WAI glossary. I think of the
   glossary as primarily being for editors, and that a few issues become
   irrelevant with that model.

   WAC: Who thinks that we should have a central repository for

   /* There is agreement on a central repository */

   WAC: From the editors' perspective, should we include non-WAI

   JB: I don't think we should redefine terms that are in stable W3C
     * Include: CMN, Katie, GR
     * Do not include: JB, IJ
     * AG: I would want external terms that resonated with an unusual
       to be documented in the relevant resource. "In this spec, we've
       used the term as follows...." But not in the repository.

   WAC: Should a term that is only used once not appear in the

   GR, CMN: I think even single uses should appear; these will be used
   the future by other specs. I think we might consider an informative
   a normative glossary.

   JB: I worry about scope creep. I think that within the confines of
   it will already be difficult to settle on definitions. I think it
   would be a rich experience to look at external terms (to figure out
   how to talk to other parties), but I would be worried about resource

     * A centralized glossary is a way to collect the terms that people
       are using. I don't think that we need to store these terms in a
       single document.
     * I think it is important to see how other terms are being used
       (e.g., <span lang="en-au">goose's bridal</span>).

   JW: I thought that the original purpose was consistency among WAI
   terms. My first proposition would be to restrict the glossary to
   definitions pertinent to WAI specs that are not defined in other W3C
   specifications. I think the first version of the glossary should be
   for editors.

     * V1 of glossary: (English) terms from ATAG 1.0, WCAG 1.0, UAAG 1.0
     * V2 of glossary: Add terms, and figure out process to add terms
       (e.g., what to do when a definition from another WG doesn't quite
       meet our terms).

   AG: I want to make sure that part of adding a term involves looking
   the world for more precedence.

   WAC: WCAG 2 experience: there are six terms we've used that the WG
   feels we need to define. I don't think we should surf the Web in
   advance looking for terms, putting in a glossary for potential later
   use. I think we should add to the glossary based on need.

   CMN: I don't think we should restrict ourselves to not having non-WAI
   terms in the glossary a priori.

   GR: As long as we're talking about a unified glossary, I have a
   question: are we going to provide a unified glossary of terms in

   KHS: On a personal note, I'd like to walk away with definitions of
     * Transform gracefully
     * Accessibility

   JW: It's not worthwhile to include terms we don't think we'll use in
   any of our documents. I think that terms actually used, and that are
   becoming controversial, should be forwarded to cross-wg list.

     * About translations: I would say that the glossary should be
       translated, and that WAI should coordinate with translators. But
       not do the translation itself.
     * About "transform gracefully": There is a dilemma if our terms are
       close to untranslatable.

   HB: Feedback from translators important to the original definition as

   DD: Editors need pointers to definitions that WAI considers to be a
   reference. I'd like to have in the glossary indication of where terms
   come from. We started looking at definitive source for IETF RFCs for
   example. We should help people find the right definition from

   DD: As important as the translation of the meaning of terms is the
   terms themselves.

   CMN: Centralized glossaries allow translators to refer to a single
   source and coordinate translations.

   /* Break 14:35 - 14:50 */

   KHS: I consider the glossary as a resource for the world, not just
   editors. I think educators and students will refer to the glossary.
   You should expect that a wide range of people will use it.

     * I don't think that people need to refer to centralized glossary
       not editors.
     * It would be good to have a mechanism for pulling latest version
       definitions automatically.

   JT: I thought of the repository as a database for editors. I think a
   public document should be generated from the repository. (But the
   public wouldn't have access to the repository directly).

   DD: I think that the repository could be used by available and still
   available to the public.

   WAC: Axes:
     * Repository v. Glossary
     * Editors v. Readers

   IJ: I would distinguish making available raw data (a good thing) from
   making available data not yet stable enough for distribution.

   KHS: I think that the information should be available to the public,
   though perhaps not work in progress.

   JT: I think that the repository is a tool for tracking work in

   JB: I hope the glossary will be available publicly. I have concerns
   about where a group has done a translation of an early draft
   brainstorming document.

     * Database v. document is an implementation issue.
     * There is no reason not to allow the public to have access to the
       work in progress. We can simply mark up status of each
     * There's a lot of value in having work in progress translated. You
       get more feedback. Just need to be clear about status.

   WAC: I'd like to address two questions:
    1. Process for adding definition
    2. What's the nature of the repository/glossary?

   WAC: Who wants at least an editors' repository with a periodic
   consensus view for the public?
     * Yes: 9
     * No: CMN, GR
     * Abstain: LK

   CMN: I don't see the value of publishing a snapshot of some abstract
   glossary. We will get more useful review when terms are copied into
   documents are reviewed in context.

   WAC: We haven't talked about how guidelines WGs pull in terms.

   CMN: My proposal:
     * A single repository in legible form (e.g., xhtml). This is the
       only glossary document. It includes status of definitions.
     * That's all we publish.

   WAC: Who supports this proposal?

   /* A lot of hands */

   IJ: A formal publication differs from a database view because people
   can refer to stable published references. If we don't go through the
   formal W3C processes (Notes, Recs, etc.), then we are bypassing W3C
   process. I think that even if there is a public version of a
   repository, that that should not be the information that people refer
   to normatively. There is also a question of how much review by other
   W3C groups do we expect of the glossary.

   CMN: I think a Note should reflect the full repository.

   JW: I don't see any need to publish the repository as a document. I
   don't think we need to make that decision now. The primary goal in my
   opinion is for editors to extract definitions.

   LK: I think it's useful to have definitions all in one place. A set
   terms in one place helps provide context. A glossary not just for
   editors would be useful.

   JT: I envision a tool where allowing me to view terms, find status of
   terms, visit places where it has been used, get links to
   additional references from terms, etc. all from one place.

   JB: I agree with Len; there are cases where I want to read a set of
   definitions together. E.g., readers wanting to do a reality check
   between their view of accessibility and WAI's. Useful for self-check
   as well.

   CMN: If it's a high threshold to publish the repository as a Note,
   having a Note is a reasonable thing to do. Note also that terms
   imported into Rec-track documents will get AC review, and that can be
   used as feedback to the Note.

   KHS: It is useful to look at three definitions and see how one is
   specific to a document. Maybe we could have "active element" in
   generic form, then links to other documents where it's used.

   JW: I think that we should unify the definitions so we don't have
   multiple definitions.

   JB: I don't think that this document has no chance of being a
   Recommendation. But I do think it should be a Note. It makes it more
   stable, is referencable, and makes it look more serious.

   GR: It was my impression that the point of the exercise was a
   centralized glossary to avoid redundancies.

   /* There doesn't seem to be opposition to this */

   JW: I agree that there shouldn't be duplication of terms across the
   guidelines. If we think that this document should stand alone, we
   should also do this. I'm not opposed to the glossary being a Note. I
   just don't think it will be as useful.

   CMN: The Note is a source for glossaries. When you publish a Rec,
   what's in the Rec is normative.
     * Having a published Note is useful to people producing individual
     * It's also useful to WAI groups.
     * You will get differences in definitions between versions of
       Recommendations (definitions imported at different times).
     * But since we are working from a common source, you will get

   /* Cynthia joins around here */

   IJ: Definitions should be fixed in a dated spec. And it's also
   possible to link to the latest version of the glossary for updates;
   but that's not necessarily what was known when the dated spec was
   published. This version and latest version semantics are always

   HB: We could use XML Query on database of terms to compare and
   contrast uses.

   KHS: I also see the glossary being used by people writing outside of

   AG: In IETF and in the real standards world, there are limitations
   about making normative references to peers.

   DD: We don't have this at W3C (no notion of "peers", for example).

   GR: As different terms become unified and codified, are there errata
   in published documents?

   CMN: My understanding of the process is that you could argue that
   having a crappy definition is an error and that it could be an
   (but is not in all cases). But the status of errata in W3C processes
   is not well-defined. Some may require AC review again, some may not.

   GR: If a single term is used wildly different in different documents
   that are interelated is probably an error.

   AG: Classical configuration and control: Once a doc is released as a
   Rec, it's frozen. You copy text from the glossary Note into a
   on the Rec track. A significantly changed term might be considered an
   erratum. If there's a change in substance, it would need to be
   reviewed by the AC. And you might have two meanings floating around
   a given moment. You can't make automatic changes to a Recommendation
   once it's been published.


     * Agreement that a central repository of terms is useful to
     * Agreement that a perodic report in the form of a TR page document
       would be useful.
       CMN: I think that it's a bad thing if there's a different version
       of the glossary source than the Note.
     * Editors of WAI documents incorporate terms and definitions from
       the latest version of the central repository.
     * Terms and definitions added when found to be (1) controversial
       shared among documents.
     * We have not discussed the review process for when something is
       added to the glossary (open issue).
     * Attaching status information to terms and definitions is a good
       KHS: I think that the document needs to be a real role model of

   DD: So we're not going to solve the problem of same terms with
   different meanings in guidelines. We may reduce the issue, or
   converge, but we won't solve it.

   KHS: One term at a time, over time will help get us there.

   /* Break 16:00 - 16:25 */

Next steps

   CMN: Getting WAI WG participants subscribed to wai-xtech.

   WAC: We will call for review of the latest version of the document by
   all WAI groups.

   JB: I think we should be careful not to cross the process boundaries.
   Glossary group still needs a home, but may not be a WG.

   AG: My understanding was that GL would become a ward for the
   In Bristol, there was some motion to accept this.

   WAC: I'm not as excited about this since it's gotten bigger.

   JW: It's a cross-WG matter, so I don't know why some particular group
   should have sole responsibility for it.

   DD: In theory, it sounds like it should be a technical WG. But given
   the price of creating WGs, a solution is to have it housed by a WG.

   AG: It's mostly a question of administrative burden, not of control.

   JW: I'd rather that this be a short-lived task force.

   AG: This task force doesn't go away.

   CMN: This is a work item for a Working Group (actually more than
     * We need an editor (Katie)
     * It needs a place on the Web (doesn't matter where)
     * It needs to be accessible to people working on it.
     * The xtech list is a mechanism for cross WG discussion.
     * I don't think it needs to be a WG of its own. If it does need to
       be a WG, then maybe QA needs to be involved. But in any case, we
       are asking people to join a separate group to do the work they

   CMN summarizing: We don't need a chartered WG, we just need a list
   a place for documents to live at.

   JB: I don't think we should try to resolve process issue today. I
   propose the following default path:
     * WCAG co-chairs and Team contact discuss what it means to be host
       of the glossary and whether they want to be host. If the answer
       know, we take it back to WAI CG.
       Action JW, WAC: Find out if WCAG WG wants to be guardian of this.
     * Action Judy: If WCAG declines, take back question of new WG to
       CG for discussion, then w3m.

Definition of Graceful Tranformation

   IJ: Does this need to be a normative term, or just a fuzzy general

   WAC: We removed from WCAG 2.0 (with one objection).

   /* Katie reads definition from [2]27 Feb draft of unified glossary */

      [2] http://www.w3.org/WAI/GL/2000/12/unified-glossary

   CMN: "Transform gracefully: To present the same information
   of the medium used."

   LK: I think that "transforms gracefully" means "is accessible after".

   /* Not agreement on this */

   CS: You hear often "degrade gracefully" in the industry. It's still
   usable (the information is still available). But "degrade" sounds

   JW: "Continues to be usable when certain features or technologies
   it invokes are not supported or unavailable."

   DD: The original definition was for "graceful degradation".
   "Degradation" is important because it conveys the idea that something
   is lost, even though information is still available.

     * Not sure an iron-clad definition is crucial to the document if
       only a question of general principle. But I agree better
       definitions are better.
     * Transformation/Degradation is context-sensitive. What if you
       have a computer? Does the content transform gracefully in that
       case? What if the user doesn't have a browser? Should the content
       be indented for easier reading in the source view? What are the
       bounds of what's graceful? This is the context.

   CS: In the definition of the 27 Feb draft: I like the definition,
   though not the example as much. The example I see when training Web
   masters is CSS. A good portion of CSS transforms gracefully. I'd like
   to see that example in there.

   LK: I get uncomfortable talking about terms in the abstract. All the
   examples I can think of, the description "maximally accessible
   afterwards" applies. In our restricted context, I think that graceful
   transformation is tightly bound to accessibility.

   HB: "Exploit redundant information to accommodate the user's
   capabilities, limitations, or preferences (of the user or

    1. I think that "fail operational" and "fail safe" are relevant here
       (from space shuttle requirements).
    2. The obvious meaning from plain English: "transforming gracefully"
       is the opposite of "transforming catastrophically". The concept
       implies robustness. Capable of responding to adversity when
       expected dependencies aren't met.

   IJ: Based on our UA experience, it would seem wiser to keep the
   general meaning of "t.g." and only bind it to accessibility when
   necessary. We had this experience when importing the term
   from WCAG.

   JW: "Web content transforms gracefully if it can still be used when
   particular features or technologies that it employs are either
   unavailable or unsupported (e.g., by a user agent)."

   CMN: My proposal: "To present the same information or function
   regardless of the medium used." Then add Jason's sentence. Example: A
   page that uses a style sheet to format text; the content transforms
   gracefully if the text can still be used without the style sheet."

   LK: I don't think that medium is the only parameter. Input
   accessibility is also a consideration. I want to see the definition
   include input and output.

   IJ: Axes:
     * input and output are included.
     * capabilities, limitations, and preferences
     * degradation (some information loss) [No consensus here]
     * Features or technologies unavailable or unsupported
     * Same info regardless of medium used (at least for some
     * This is about content and functionality.

   JW: I'm concerned that the concept might be broadened. In WCAG 1.0 it
   was about unavailable or unsupported features. I would be concerned
   the term were broadened to cross-medium access. In WCAG 1.0 it's a
   descriptive term that refers primarily to backward compatibility (but
   not exclusively to it). You might add to my previous proposal "There
   may be some loss of presentation or functionality, provided the
   content is still usable." I think some of the confusion around this
   term results from trying to broaden it.

   LK: What I like about JW's formulation is that it brings in input and

   CS: It sounds like GR is thinking more about "graceful" than
   "transformation". Graceful means "you may lose something, but it's

   IJ: Sounds like different levels:
     * No functionality lost
     * No essential functionality lost

   IJ: But there is not one way to say what's essential: what is lost,
   its value, depends who you're talking to. There is not just one
   "essential view".

   CMN: I think that we should avoid saying "essential".

   CS: What is essential is a judgment call. The author has to make a
   judgment call.

   IJ: I'd vote for a user-biased definition and counterfactual
   conditionals: It transforms gracefully if the user would not notice
   any difference if the information would there."

   CMN: I don't think this works.

   CS: I think you have to consider the author's perspective. Otherwise
   the author won't implement your standard. The question is not whether
   the user can perceive the difference (e.g., the user can tell that
   fonts are different).

   GR: Information is a subset of functionality.

   LK: CS mentioned a meta issue that arises once or twice in every
   meeting: question of user needs balanced by requirements on authors
   (or author needs). I would suggest as a procedure that we factor out
   the user v. the author side of things.

   CS: I'm fine with factoring it out. I don't want the term "graceful
   transformation" to be an absolute term. There is a balance.

   Action KHS: Write a definition based on above discussion.

Ideas for Wendy's appearance on the architecture panel.

   DD: I'd like to see a clear presentation of publication model:
     * Server sends transformable content to the client (redundancy in
     * Server sends final form to the client based on client/server
     * Tranformation by intermediaries is a variation on this.

   JW: You can't make a claim about where a particular functionality
   reside. These services may be on a single computer or be distributed
   over the Web. It's entirely possible for content to be processed as
   goes up and down the chain. I would argue that this model is valid.
   What is important is that the content should be as generic as
   each time it hits a transformation point. The accessibility
   requirement is that the user can set preferences and get content in
   accessible and redundant form (since the author doesn't know what the
   transformations will be).

   CMN: How, WAC, do you view the point of view that "all of these
   problems can be solved by the author" or "all can be solved by the

   LK: Transparency: it should be possible for a third-party to verify
   that two different presentations are equivalent. There are
   architectures where it's easier to verify that two things are
   equivalent. You want architectures where it's easily testable that
   things are equivalent or that two things are made equivalent by
   construction (preferably both).

   AG: I don't subscribe to the proposition that everything could be
   solved by AT innovations. I believe that, against the baseline of
   current Web techs, there is some stuff that must come from the

   DD: E.g., video description.

   AG: I think that DD's question is a good one - ask people what they
   believe the diversity will be about what will be on the Web. In
   reality, W3C won't implement the most general specs possible. People
   want a concrete justification for what's in a spec. Some range of
   options will be available for processing. We want to ensure that
   in use make available enough information. This will involve a lot of
   checking up on folks.

   WAC: Sounds like access and device-independence diverge here (user
   side v. client side control). Device-independent authors design
   abstractions and generate a ton of content on the server-side.

   AG: People haven't looked at how much better one can do something on
   the server-side (e.g., with a larger dictionary than what the client
   would have). We don't know know that transformations would be worse
   the server side.

   AG: [New] I don't find any of the spec groups aggressively pursuing
   the quality with which the formal model created by the markup is
   loaded. I don't see the w3c engineering plan addressing the "quality"
   issue: how well does the author use the formal model that is captured
   by the format.

   KHS: Someone calculated that people use 10 WML elements (and not the
   full richness of the language).

   WAC: This is the lowest common denominator.

     * Question of whether the path we've taken of modularization and
       profiling: will this endanger interoperability in the future? How
       will this work in practice? How will pieces work together?

   JW: What vocabularies need to be developed to express content in a
   such that the semantics can be worked on?

   AG: This picks up on what CS was saying: intermediate level between
   final form and raw data.

   GR: You need a semiotic Web, not a semantic Web. You need to be able
   to transform tokens.

   Action WAC: Create a glossary page (to track minutes and

   /* Adjourned 17:40 */
Received on Tuesday, 27 February 2001 18:01:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:25 UTC