- From: Ian Jacobs <ij@w3.org>
- Date: Tue, 27 Feb 2001 18:01:15 -0500
- To: wai-xtech@w3.org
Hello,
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"
Partcipants
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.
Agenda
* What do we do about document-specific definitions?
* Is there one WAI glossary? Or one basic glossary from which
others
inherit?
* 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
less)?
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.
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
list?
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
want,
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
process
that can be reused for developing glossaries.
4. Don't try to incoporate non-WAI terms; other specs are definitive
resources.
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
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.
* Include: CMN, Katie, GR
* Do not include: JB, IJ
* AG: I would want external terms that resonated with an unusual
use
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
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:
* 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
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:
* 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
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:
* 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.
JB:
* 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
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:
* I don't think that people need to refer to centralized glossary
if
not editors.
* It would be good to have a mechanism for pulling latest version
of
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
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:
* 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
definition.
* 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
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.
* Having a published Note is useful to people producing individual
documents.
* 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
convergence.
/* 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.
Summary
* Agreement that a central repository of terms is useful to
editors.
* 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
(2)
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
thing.
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 */
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
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):
* 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
need.
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:
* 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
is
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
WAI
CG for discussion, then w3m.
Definition of Graceful Tranformation
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 [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
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:
* 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
don't
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
environment)."
AG:
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
"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:
* 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
variations).
* 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
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:
* No functionality lost
* No essential functionality lost
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.
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
content).
* Server sends final form to the client based on client/server
negotiation.
* Tranformation by intermediaries is a variation on this.
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:
* 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
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 */
Received on Tuesday, 27 February 2001 18:01:17 UTC