The document at [1] is most impressive. I note with pleasure
the
material in sections 2.1, 2.2, 3.4 etc, given that they are
quite
obviously in harmony with thinking within DIWG. Once could
derive a
validation process from such guidelines. For example, I
could envisage a
subset of a validation process being:
[2.11] If your specification describes a presentation
(final-form)
language then:
[2.11.1] Can the author identify (by URI) the source of
the final
form?
[2.11.2] Is the final-form instance served only upon
user request?
[2.11.3] Is the persistent storage done in a
semantically rich
manner?
The expectation of the validation process is that you answer
Yes to
everything (where applicable) and if you answer No then you
must offer a
justification. Each check references the guidelines for
further
explanation.
OK, Al, you might say this is a bit simplistic. That may be
true, and
perhaps (like a fool) I'm rushing into this arena without
proper
awareness of the savage animals awaiting therein, but I'd
sooner have a
simplistic unavoidable/formal process within publication
that can be
executed by the authors, than have a perfect checking system
that
requires manual contribution from various (over-worked,
under-staffed)
groups (and even then, typically just when invited/alerted
to the need).
In the case of DI, we think it should be easy for an author
to check a
spec and see if "the description of the client makes
assumptions about
its physical or behavioural characteristics in a manner that
excludes
alternative, yet viable, clients". We in DI would spot
such an issue
when we review a spec, but it would be a lot better if we
let authors
ask the questions themselves, and gave them some
guidance/examples to
help them answer the questions. Keeping them to Boolean
assessments
would make the process lightweight. Not perfect perhaps, but
certainly
something do-able. If such a process caught 80% of the
issues, for 20%
of the effort normally expended, then that would be a good
result, I
think.
Or I may be about to be savaged by the lions 
---Rotan.
-----Original Message-----
From: Al Gilman [mailto:Alfred.S.Gilman ieee.org]
Sent: 14 June 2006 16:51
To: Rotan Hanrahan; www-qaw3.org
Cc: www-diw3.org
Subject: Re: Making DI/WAI/I18N checks a formal part of the
W3C spec
publication process
At 4:04 PM +0100 6/14/06, Rotan Hanrahan wrote:
>Hello QA,
>
>In a discussion regarding a recent message received by
the group, I was
>given the action to raise an issue with QA that derives
from a
>suggestion contained within the message, namely:
>
>"if you have any guidelines for spec writers
regarding device
>independence we would appreciate the references."
>
>This request opened the issue of how to raise awareness
of DI with spec
>writers.
>
>It was agreed that questions like:
> - Does this spec give due consideration to
Accessibility?
> - Does this spec give due consideration to Device
Independence?
> - Does this spec give due consideration to I18N?
> - etc.
>might be good "tick boxes" for spec authors
as part of the formal
>publication process. If this were the case, authors of
specifications
>would be required as part of the publication process to
confirm that
>they had considered such issues, preferably with the
help of the
>relevant groups, and had either taken appropriate
actions, or deemed
>the issue not relevant to the spec. The tick boxes could
be linked to
>guidelines provided by each group to streamline the
process.
[fools rush in...]
Let me give some ideas of where we stand on this thought.
1. The WAI attempt:
The XAG [1] offers an example of a read-ahead document for
the
architecting of technologies and their documentation in
specifications.
This is a long-languishing Working Draft which we should
return to but
won't likely do that soon. But it gives an idea of how we
approached the
read-ahead problem. There will still be the need for
read-behind where
accessibility [.. | DI | i18n] qualified individuals read
the drafts of
the technology proponents.
2. Yes, there is a problem:
There is a general recognition that we are too dependent on
Last Call
and manual review by the expert groups during Last Call at
the present
time.
There has been some grumbling in more than one quarter as to
how
requirements documents are developed and then treated as
authoritative
in the transition of specification documents. The
development of
requirements notes has transparency, but no accountability
in terms of a
formal review by the wider community.
W3C has difficulty making general statements about web
content.
What we have been able to say in the Architecture Document
is more about
protocol than about format. The "hypertext web
[2]" is relatively
under-covered. The CDF group dropped back to a short list
of specific
integrations in the hopes of gaining headway.
3. QA may not have the whip hand, here.
IIRC the AB is the center of action for changes in the
Process Doc and
what we ultimately need are changes in the engineering
process
requirements, not just some guidelines docs. But
architect's guidelines
for DI readiness would indeed help. And that DI could Just
Do, parallel
to the XAG.
4. Requirements on any proposed reform:
a) The people in the working groups have to be able to
recognize the
intersection of their topic and the guidelines. [Usability
constraint on
guidelines.]
b) Don't expect what you don't inspect: What's in the
guidelines has to
be actively checked against the drafts beyond some point. At
least at
transitions.
Al
[1] http://www.w3.org/TR/xag
[2] http://ww
w.w3.org/2003/Talks/tp-steven-web/
>Would it be possible as part of the QA work to
consider/comment on such
>an enhancement to the quality of the publication
process? Would the
>consumers of new specifications be more confident in the
specifications
>if they were aware that the publication process formally
included such
>checks as a necessary step?
>
>We acknowledge that there are other oversight processes
(e.g. the
>Chairs acting in concert to suggest reviews of new specs
by various
>groups), but the suggestion we are making is to make
explicit certain
>broad issues like Accessibility, DI and I18N (to name
but three).
>
>Regretably, DI has not written guidelines for spec
writers, but if this
>were a formal part of the authoring process then I'm
sure we (the DIWG)
>would be happy to craft something to that effect.
>
>On behalf of DIWG,
>---Rotan Hanrahan.
|