RE: Issue 1041: ICS Good Practices: 1.2 A, B., C

My preference, is to be clear that the ICS is a vendor's articulation of
what they have implemented - and implemented in his mind, correctly (cause
why would someone take the time to implement it badly?).  So, I agree with
your comment regarding - ".. answering yes ... has been tested and correctly
implemented (i.e., conform)."  I suggest dropping "and correctly implemented
(i.e., conform). The problem is that people are confused - often reading too
much into the 'conformance' part of the ICS.  

  I tried to remove as much of the 'conformance' and 'claim of conformance'
from the ICS definition and discussions.  It is and has been used as the
precursor to conformance testing.  It is well accepted in this (as pointed
out by Patrick's reference to ESTI, used this way by IGES, STEP, OSI, and
many others).  I would agree that ICS may be a bad name, since it is
confusing. 

 

 

 

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com] 
Sent: Thursday, March 17, 2005 10:33 AM
To: Lynne S. Rosenthal; 'www-qa-wg@w3.org'
Subject: Re: Issue 1041: ICS Good Practices: 1.2 A, B., C

 

At 10:47 AM 3/16/2005 -0500, Lynne S. Rosenthal wrote:



[...]
An Implementation Conformance Statement (ICS) provides information about an
implementation to a specification, by presenting in a uniform manner the
capabilities (e.g., functions, features) and options that have been
implemented as well as limitations of the implementation. An ICS pro-forma
typically takes the form of a questionnaire or checklist, to be completed
for an implementation.  


Okay so far.




It provides the implementer a way to indicate what has been implemented.
Think of it as an inventory of what has been implemented.  Note, that a
completed ICS does not indicate conformance of the implementation.  Hence,
answering yes to indicate a capability is supported does not mean that the
capability has been tested and correctly implemented (i.e., conforms).  


I don't like the last sentence.  It seems to imply that an implementer
should or could check "yes", something is implemented, even if they *know*
that it is not correctly implemented.  That seems absurd.  The ICS becomes a
vehicle for deceit.  (Such real-world abuses we actually seen at the height
of the CALS era -- checklists of implemented CALS stuff that was known to be
wrong.)

Though I disagreed with it, I will live with the Boston decree that ICS
shall not contain any proof or substantiation of the claims, but it seems to
me absurd that someone, in an Implementation CONFORMANCE Statement, should
check "yes" to a feature that they know to be non-conforming or incorrect.  

In other words, the ICS "yes" should mean that the feature is implemented
and is claimed to conform (but without any proof or substantiation of that
claim).

I would replace the last 4 sentences (above) with something like:




It provides the implementer a way to indicate what has been implemented.
Think of it as a template [ed.  recall that the context is "ICS pro-forma"]
for making detailed feature-by-feature conformance claims.  


You could add, "Whether or not the features do in fact conform as claimed is
verified only by conformance testing, which is beyond the scope of the ICS."
That leads into the next stuff, which indicates that completed ICS can be an
input to a conformance testing process.

-Lofton.