Techniques requirements: focus on [less microscopic] *patterns* of practice

At 03:56 PM 2003-01-07, Michael Cooper wrote:

>We're a go to meet by teleconference tomorrow, January 8, from 15:00 to
>16:30 UTC (10:00am to 11:30am US Eastern/7:00am to 8:30am US Pacific). The
>conference information is:
>
>+1-617-761-6200
>Passcode 9224
>
>This meeting will be to discuss the Techniques requirements draft that was
>sent around on January 2. Mainly I expect we will raise issues, some of
>which has already been done on the list. We may be able to resolve some
>issues as well, but more importantly I'd like us to arrive at changes to the
>document we'd like to see (including logging issues as open) before posting
>it as a public draft.

There are serious problems with the scoping concepts that go into defining
what is "one technique" as presented here.

Looking at just one of these techniques, one can't tell if it is good or
bad, because it will be either good or bad depending on the other techniques
practiced.

Specifically, the limitations to
- one success criterion
- one 'home' format

are counter-productive

The work should better be re-directed to maintain a database of strategies
from which one can readily generate a rough draft "standing practices" for a
site or organization by checkbox opting in or out of available strategy
descriptions.

The critical level of aggregation is the one over which a site or
organization will reasonably make a yes/no decision as to "we will implement
this one" or "we will not implement this one" in their site/org practices.

These unit strategies are in general, and in fact most of the time, profiles
of coding techniques within multiple formats.  All the coding constraints
to achieve the expected performance benefits must be set out in the
strategy so that once selected, it is effective.

What we should be maintaining is a pool of strategy descriptions, not a
hierarchy of techniques documents.

The strategies may wind up segregated into application areas such as
geospatially related information services and eCommerce transaction processing,
but the mechanics of maintenance: group review and editing, rollup into
documents, should be built around the general case of a bag of strategy
descriptions.

For each strategy, there is a

- application sub-function description
   -- in terms that a practicing designer of web applications can recognize
   -- example:  large tables with multi-level hierarchies of headers
      governing the rows and/or columns.  [major topic at FedStats workshop]
   -- example: warn on leaving site

- coding techniques profile
   -- how certain things are coded across multiple formats
   -- in terms recognizable in format specs, implementable in design tools

- performance assertions, a.k.a. access benefits
   -- collection of how it works for specific delivery context cases, including
      narrowing the range of device and human capabilities and performance 
levels.
   -- this shall be described in terms that consumer advocates would 
authenticate
      and application designers can understand
   -- it may be possible to identify specific access failures that result from
      violating specific coding constraints, but only in the context that
      aside from this violation the rest of the practice is being followed.
   -- the goal here is not to isolate on a single success criterion, but to 
guard
      all success criteria which are at serious risk of violation in this 
function

The unit of discovered knowledge worth publishing is a critical 
*collection* of
implementation constraints that provide a major increase in the likelihood
of satisfying some *collection* of the success criteria.  In other words,
there are multiple success criteria whose likelihood of satisfaction depends
strongly on this [strategy _defined_as_ the class of patternOfPractice that
this paragraph describes] and multiple technology implementation constraints
that this pattern of practice depends on.

[Note that we could view the relation to success criteria as follows: each
strategy that we accept in the end has a relation to _all_ the success
criteria that for _each_ success criterion is either "contributes
materially" or "sensibly independent." If some pattern of practice in
finalFormXSL_FO for example violates some of the success critera, it is not
an acceptable pattern of practice without being coupled with alternatives.
The acceptable pattern of practice is a bundle which affords access to this
pattern and a suitable complement of other patterns.  This is Guideline 1 in
a nutshell.]

For collecting scenarios to determine requirements, and for collecting
evaluation experience to determine recommendable techniques, we should build
a repository that manages the memory of patterns of practice and
dependencies between these assertions and other assertions.  That is a
functionality that accepts both our working knowledge as well as what we
publish after we have purified that working knowledge.

This can be done with strategy descriptions written up in document-like XML 
with
the dependency cross-relations booked either in XLink or RDF.

The XML strategy descriptions can be reduced to RDF for the purposes of machine
comparison, but people should not be asked to contribute scenarios or 
strategies
in RDF.  That would be an exercise in pedantry.

We can accept input in RTF based on writing with a document template that we
disseminate, for that matter.

Al


>There may be issues of process for us to discuss, some
>of which we can discuss in this call and some of which may need to defer to
>a whole-group call.
>
>Michael
>
>Michael Cooper
>Accessibility Project Manager
>Watchfire
>1 Hines Rd
>Kanata, ON  K2K 3C7
>Canada
>+1 613 599 3888 x4019
>http://bobby.watchfire.com/

Received on Thursday, 9 January 2003 10:04:45 UTC