RE: Making DI/WAI/I18N checks a formal part of the W3C spec publication process

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-qa@w3.org
Cc: www-di@w3.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://www.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.

Received on Wednesday, 14 June 2006 16:25:49 UTC