imports from ERT Re: minutes from last week published

Hi Phill,

My experience has been that it is better to have a short form of techniques
available than just a mapping to another document. I think ERT will form a
major set of "techniques for this guideline", especially for guideline 4, and
we should point to it (and point this out) rather than copy it, in the same
way as we do for 7.1. However, I think there is still value in providing a
short summary in the docuent itself.

What I would like to see in a future techniqes document is several possible
versions, based on one all-encompassing monster that nobody actually reads,
which includes basic ideas on how to do everything, as well as references and
pointers to reference implementations, but from which can be distilled a
version that provides references, or a version that includes everything that
is relevant to image and multimedia tools, or a version that just describes
testing techniques and links to test cases, and so on.

Sorry for the tortured sentence...

Charles

On Mon, 21 Feb 2000 pjenkins@us.ibm.com wrote:

[snip]  
  
  Comments regarding "import from ERT" and "conformance evals":  The
  relationship between the ERT, the "conformance evals", and the ATAG
  Techniques Note need to be clarified.  I would not support importing from
  the ERT anymore than importing from the IBM Java guidelines for ATAG 7.1.
  Having a lot of links from the techniques to the ERT would be helpful.
  Having a lot of links from the techniques to the "conformance evals" would
  be helpful, and the same with Windows and Java applications guidelines.  So
  that brings us to the unique purpose of the ATAG Techniques Note document.
  In my mind it is unique in that it maps from the ATAG to the ERT and other
  documents.  It's value is in the mapping.  If either the ERT, or the
  Windows, or Java documents need help, those document should be helped and
  not added to the techniques uniquely.  If there is an implementation
  revealed in the "conformance evals" that we as a working group agree is
  invalid or undesirable, and hopefully not in the ERT, then it could be
  within the purpose of the techniques document to list what NOT to do.
  These "DO NOT's" could be explained without specifically pointing to the
  vendor(s) implementing them.  We would never know ALL the vendors doing the
  bad or good things, so none of them should be listed in the techniques
  document.
[snip]

Received on Monday, 21 February 2000 23:39:33 UTC