- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Thu, 19 Jul 2007 16:22:50 -0400
- To: public-html@w3.org
<quote cite="http://www.w3.org/2007/07/19-html-wg-irc#T17-25-03"> ChrisW: ... I think we'll have to make a decision on the disputed principles soon. There are arguments both ways, but it's important to say something. </quote> May I suggest another approach? Don't force the group to pick a "right answer" to the wrong question. See if you can't re-frame the issue so as to expose latent agreement. As I read the "principles that are divisive" it seemed to me that these were couched in unnecessarily divisive terms. This is the kind of place where searching for an assertion that gets more ready agreement will show us a better way to look at the design space. Let's take the 'visible metadata' issue. First of all, there is a mistake in talking about only 'metadata.' At the model level, there are no metadata. Just data, and relationships among the data. Different processes touch different views of the aggregate of data. Display processes, machine processes. The web runs on very lightly-modeled content because of the pervasive involvement of human operators. The principle that belongs in your set of values touches _all_ the concepts floating through the instance docs, both markup and metadata. The answer to this issue flows from some of your other principles: - solve real problems - simple - and an expansion of your 'security' item. This should be relaxed to "support information integrity." And one of Tim's: lowest level language. The corollary of 'lowest level language' here is "frame the model in terms of concepts your users already understand, to the greatest extent reasonably achievable." From "support information integrity" we get the following line of argument: Historically, the Web worked because of the finely-marbled alternation between human and machine action. In the beginning it was just evolving navigation, and the back button meant that groping and test-and-fix added up to success. Now the things one can do on the web are broader and we need to look afresh at 'undo' and what's safe. But in any case, there is cause to prefer field definitions that get used more, for both economy and information integrity (does the data reflect reality?). This is not limited to metadata. And within that "used more" to further prefer field definitions that get validated by users understanding and acting on them. That comes from the conjunction of "information integrity" and "lowest level language." So, prefer data definitions with more human use over data definitions with less human use. In markup and in metadata. Please understand that for accessibility we will be after you to run a sliding scale on this value. That is to say if the "real problem" is that some people get no access to the functionality, then we may want you to include things in the design that close this gap, even if they are not widely used (and specifically they don't have to be widely used now). I think Alastair and Henri framed the "feasible range for agreement" pretty well: Alastair: <quote cite="http://lists.w3.org/Archives/Public/wai-xtech/2007Jun/0111.html"> One thing I'd point out though, is that accessibility use-cases shouldn't necessarily be dropped due to (some of them) being edge cases. </quote> Henri: <quote cite="http://lists.w3.org/Archives/Public/wai-xtech/2007Jun/0094.html"> If you come and say that you want a given edge-case solution in the spec just because you know you think you need it, you are likely to be unsuccessful. On the other hand, if you present a use case, present a clean common case solution and *then* as an extra present coverage for edge cases *and* explain why the edge case coverage is not just chasing for diminishing returns, you are much more likely to be successful even if the edge case stuff is the same in both cases. </quote> If we make the principle "prefer feature designs that get more use over feature designs that get less use" we get both support for universal design over "special things for special people" *and* the justification for why one should prefer metadata that passes through the human consciousness over metadata that doesn't, where either can do the job. Al
Received on Thursday, 19 July 2007 20:23:09 UTC