Reference document: 27 Feb draft of 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.
JW: What about existing Web Content Glossary
CMN: What other sources should we be using? The closer they are in W3C 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 documents.
JW: Legal definitions are frequently the result of compromise, and may exclude some individuals. We should look instead to disability community.
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. There are problems with different people reading a glossary and the way they interpret the glossary.
KHS: Some of the WAI glossaries are good at explaining, others are not.
HB: I looked at some books in bookstores for the words "accessibility" and "usability". Few of them use the terms in the way we do. Our usage 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.
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 list?
JB: I want to speak in favor of including definitions of basic stuff in a WAI glossary.
IJ: I think that:
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 ways 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 document.
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 document.
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 that there is no issue about extracting from a separate resource. The editor has to decide which terms to include. I thought of the glossary 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 changes...
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 work in practice.
JW: I think that definitions should be copied from central glossary (and reproduced inline). I think that definitions from other W3C specs 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 definitions?
/* There is agreement on a central repository */
WAC: From the editors' perspective, should we include non-WAI specific terms?
JB: I don't think we should redefine terms that are in stable W3C specs.
WAC: Should a term that is only used once not appear in the repository?
GR, CMN: I think even single uses should appear; these will be used in the future by other specs. I think we might consider an informative v. a normative glossary.
JB: I worry about scope creep. I think that within the confines of WAI 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 expenditure.
CMN:
JW: I thought that the original purpose was consistency among WAI terms. My first proposition would be to restrict the glossary to those 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.
WAC:
AG: I want to make sure that part of adding a term involves looking to 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 other languages?
KHS: On a personal note, I'd like to walk away with definitions of two terms:
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.
JB:
HB: Feedback from translators important to the original definition as well.
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 external sources.
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.
JW:
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:
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 progress.
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.
CMN:
WAC: I'd like to address two questions:
WAC: Who wants at least an editors' repository with a periodic consensus view for the public?
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:
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 of 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 translations, 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.
/* 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 useful.
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 W3C.
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 erratum (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 document 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 at a given moment. You can't make automatic changes to a Recommendation once it's been published.
CMN: I think that it's a bad thing if there's a different version of the glossary source than the Note.
KHS: I think that the document needs to be a real role model of accessibility!
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 */
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 glossary. 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 one):
CMN summarizing: We don't need a chartered WG, we just need a list and 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:
Action JW, WAC: Find out if WCAG WG wants to be guardian of this.
IJ: Does this need to be a normative term, or just a fuzzy general principle?
WAC: We removed from WCAG 2.0 (with one objection).
/* Katie reads definition from 27 Feb draft of unified glossary */
CMN: "Transform gracefully: To present the same information regardless 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 pejorative.
JW: "Continues to be usable when certain features or technologies that 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.
IJ:
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 environment)."
AG:
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 "equivalent" 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:
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 if 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 output.
CS: It sounds like GR is thinking more about "graceful" than "transformation". Graceful means "you may lose something, but it's not important."
IJ: Sounds like different levels:
IJ: But there is not one way to say what's essential: what is lost, or 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 the 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.
DD: I'd like to see a clear presentation of publication model:
JW: You can't make a claim about where a particular functionality will 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 it 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 possible each time it hits a transformation point. The accessibility requirement is that the user can set preferences and get content in an 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 AT"?
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 two 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 author.
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 those 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 on 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.
DD:
JW: What vocabularies need to be developed to express content in a way 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 developments).
/* Adjourned 17:40 */