Re: 5.2

I'm sorry to go on about this, but now that I've read the whole of Jason's
message (I'm going through my inbox in reverse chronological order) I'm even
more confused.  Let me begin by proposing a slight reworking of what Jason
offered, and then I'll ask a couple of questions.

==Jason's phrasing:==
>... there exist multiple, independent and interoperable implementations of
the
> technologies (i.e., formats, protocols, API's etc.) used by the
> content.
[snip snip] Jason then proposes an example of how we might define
"independence":
>... e.g., that [the technologies used by the content] have not been
> developed by the same entity, or that they don't have substantial code in
> common, or whatever seems most reasonable as a requirement.
>
==end Jason's wording==

Here's a slight reworking that does little more than simplify the syntax:
== John's reworking of Jason's text==
... There are multiple, independent, and interoperable implementations of
the technologies used by the content.

Note: Technologies, including formats, protocols, API's, etc., may be
considered independent and interoperable if they require different operating
systems or don't have substantial code in common.
==end John's reworking==

Comment: I simplified the sentence by removing the parenthetical phrase
about formats, protocols, APIs, etc.  I then proposed putting those terms
into an explanatory (informative) note rather than the text of the
checkpoint or success criterion.  I deleted the phrase about having been
developed by different entities because it didn't seem to fit cases such as
JAWS and WIndow-Eyes.

Questions:
What does "interoperable" mean in the sentence "There exist multiple,
independent, and interoperable implementations of the technologies used by
the content"?

Does content meet 5.2 if it works in Internet Explorer on both Windows and
Macintosh but not in Netscape/Mozilla?

I think there *is* a significant communication issue here.

Sorry!
John
----- Original Message -----
From: "Jason White" <jasonw@ariel.ucs.unimelb.edu.au>
To: "john_slatin" <john_slatin@forum.utexas.edu>
Cc: "'Lee Roberts'" <leeroberts@roserockdesign.com>; <w3c-wai-gl@w3.org>
Sent: Thursday, December 26, 2002 12:17 AM
Subject: RE: 5.2


> john_slatin writes:
>  >
>  > I see your point, Lee, and it makes sense.  I think we would be wise to
>  > avoid phrases like "user agent engines" because the concept of an
"engine"
>  > is foreign to most people.  The ones who recognize the term might
associate
>  > it with "search engines," but they still won't know what the word
"engine"
>  > means in that context, either.
>
> Ultimately, I don't think it is a communication issue. Rather it is an
> attempt to tie the checkpoint too much to the structure of those
> implementations in which the concept of an "engine" makes sense. I
> suggest we return to the underlying issue: not only is there a variety
> of user agents, but people with particular needs addressed by the
> guidelines have reason to select implementations that best meet their
> needs, including custom-developed user agents. Content that relies on
> a single, specific implementation of the formats, API's and protocols
> it uses, will be inaccessible to users who, for whatever reasons, find
> that their needs are best met, or can only be met, by a different
> implementation from that on which the author has chosen to depend.
>
> The current discussion relates only to how the requirement should be
> expressed; there is at present no dispute as to its importance or
> place in the guidelines, issues which I therefore leave aside in what
> follows. I think the simplest and most accurate mode of expression is
> to say that there exist multiple, independent and interoperable
implementations of the
> technologies (i.e., formats, protocols, API's etc.) used by the
> content.
>
> This is different from saying that the content is implemented in
> multiple user agents, in as much as it is here explicitly prescribed
> that the implementations must be independent, provided that a suitable
> definition of independence is given, e.g., that they have not been
> developed by the same entity, or that they don't have substantial code in
> common, or whatever seems most reasonable as a requirement.

Received on Sunday, 29 December 2002 00:29:14 UTC