Re: seeking clarification of your comments

On Sat, 2003-06-21 at 13:10, Lofton Henderson wrote:
> Hi Ian,
> 
> We were discussing one of your SpecGL Last Call comments, and had a couple 
> of questions of clarification.  It is the issue we call LC-29.4, which is 
> sub-issue number 4 of LC-29 [1]:
> 
> >4. It might be valuable to explain some desirable characteristics of a 
> >specified technical requirement:
> >
> >    1. Mutual independence from other requirements
> >    2. Expresses a minimal requirement
> >    3. Distinguish and label: requirements, exceptions to those 
> > requirements, necessary and/or sufficient techniques for satisfying those 
> > requirements.
> 
> On both of the first two points, we could see multiple ways to define your 
> terms, respectively:
> 
> "mutual independence"
> and, "minimal requirement".
> 
> For example, some people thought that minimal meant "atomic" -- not easily 
> sub-dividable or factorable -- and some thought it could mean a requirement 
> establishing a minimum.  There were multiple different ideas about what 
> "mutual independence" might mean.
> 
> Could you elaborate a little bit, exactly what you meant for both cases?

Yes, and thank you for following up on these questions.

1) By minimal requirement I meant that the spec should require as little
   as possible. During the (long) development of UAAG 1.0, the UAWG
   came to understand the goals of each checkpoint. We realized that
   some of the requirements were too broadly expressed and could be
   narrowed and still meet the desired goals. In other cases, the 
   requirements were too narrow (e.g., we required a particular
   solution to a problem instead of expressing the problem).

   Seeking minimal requirements was a challenge for a spec like UAAG   
   1.0; it might be easier for protocol and format specifications. 
   It's hard to say, for example, what the "minimal configurability"
   needs to be for changing the pitch range of synthesized speech.
   Nonetheless, as UAAG 1.0 matured, the scope of most requirements
   shrunk at the same time we expressed the requirements more precisely.
   
   During the paring down process, we also found it useful to 
   clearly distinguish what is necessary from what is sufficient. 

2) I think it's a challenge, notably in a big spec, to understand
   how all the requirements depend on one another. Clearly two
   requirements that contradict each other pose a problem. But two
   requirements that overlap in scope can also be problematic. For
   instance, it seems to me that there shouldn't be three ways to
   do the same thing in a format specification. 

   In UAAG 1.0, we found that we had some cases where checkpoint
   X required something, and checkpoint Y required a subset of that.
   At first, we thought this was useful since checkpoint Y emphasized
   a particularly important special case of X. We decided later that
   this would be confusing to readers ("Checkpoint X already covers   
   this; why do you need checkpoint Y??"). So we tried to ensure that
   checkpoint requirements were mutually exclusive. 

   I note that we do still have special case checkpoints, but they
   are distinguished by priority. For instance, it's a priority 1
   to follow OS conventions when implementing the focus. It's a
   priority 2 to follow (general) OS conventions that benefit 
   accessibility. The two checkpoints overlap, but are distinguished
   by priority, so they don't overlap at the same conformance level.

I hope these comments help,

 - Ian

> [1] http://www.w3.org/QA/WG/lc-issues#x29
-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Sunday, 22 June 2003 10:52:02 UTC