RE: Definition of feature, interoperable and implementation

There are some words, (e.g., feature, function) that we may not want to
define - that we purposely don't want to tie it down, since it is not
consistently used, but everyone knows what it means within their technology.
If we do decide to define it, it will be difficult. 



> -----Original Message-----
> From: www-qa-wg-request@w3.org [mailto:www-qa-wg-request@w3.org] On Behalf
> Of Karl Dubost
> Sent: Monday, March 14, 2005 8:21 PM
> To: 'www-qa-wg@w3.org'
> Subject: Definition of feature, interoperable and implementation
> 
> Hi QA WG,
> 
> there's a work going on the CDF Mailing List to define three terms:
> 	- feature,
> 	- interoperable
> 	- implementation
> 
> Abstract of my research
> - feature
> 	QA SpecGL: 120 - not defined
> 	Process:    12 - not defined
> - interoperable, interoperability
> 	QA SpecGL:  30 - not defined
> 	Process:     5 - not defined
> - implementation
> 	QA SpecGL:  95 - defined
> 	Process:    34 - not defined
> 
> 
> [Member only]
> http://www.w3.org/mid/
> Pine.LNX.4.61.0503091206030.5940@dhalsim.dreamhost.com
> 
> I will ask if it's possible to share it on www-qa@w3.org mailing list
> for the benefits of a wider community.
> 
> Here follows, the use of features in the Process document, It's never
> defined what a feature is even if it has a lot of implications in the
> process.
> 
> In 7.4.3 Call for Implementations
> 
> [[[
> In the Call for Implementations, the Working Group MAY identify
> specific features of the technical report as being "features at risk."
> General statements such as "We plan to remove any unimplemented
> feature" are not acceptable; the Working Group MUST precisely identify
> any features at risk. Thus, in response to a Call for Implementations,
> reviewers can indicate whether they would formally object to the
> removal of the identified features.
> 
> After gathering implementation experience, the Working Group MAY remove
> features from the technical report that were identified as being "at
> risk" and request that the Director Call for Review of a Proposed
> Recommendation. If the Working Group makes other substantive changes to
> the technical report, the Director MUST return it to the Working Group
> for further work.
> ]]]- http://www.w3.org/2004/02/Process-20040205/process
> 
> 
> In 7.4.4 Call for Review of a Proposed Recommendation
> 
> [[[
> 2. Shown that each feature of the technical report has been
> implemented. Preferably, the Working Group SHOULD be able to
> demonstrate two interoperable implementations of each feature. If the
> Director believes that immediate Advisory Committee review is critical
> to the success of a technical report, the Director MAY accept to Call
> for Review of a Proposed Recommendation even without adequate
> implementation experience;
> ]]]- http://www.w3.org/2004/02/Process-20040205/process
> 
> In 7.4.6 Returning a Document to a Working Group for Further Work
> 
> [[[
> 	1.  	The Working Group makes substantive changes to the technical
> report at any time after a Last Call announcement and prior to
> Publication as a Recommendation, except when the changes involve the
> removal of features at risk identified in a Call for Implementations.
> In the case of substantive changes, the Working Group MUST republish
> the technical report as a Working Draft.
> ]]]- http://www.w3.org/2004/02/Process-20040205/process
> 
> In 7.6.2 Classes of Changes to a Recommendation
> 
> [[[
> 3. Corrections that MAY affect conformance, but add no new features
> ]]]- http://www.w3.org/2004/02/Process-20040205/process
> 
> and
> [[[
> 4. New features
> For new features, W3C follows the full process of advancing a technical
> report to Recommendation.
> ]]]- http://www.w3.org/2004/02/Process-20040205/process
> 
> 
> To be fully honest, we use _120 times_ "feature" in the QA
> Specification Guidelines without defining it.
> 
> We define in the glossary
> [[[
> * Deprecated feature
>   	An existing feature that has become outdated  and is in the process
> of being phased out,  usually in favor of a specified replacement.
> Deprecated features are no longer recommended  for use and may cease to
> exist in future  versions of the specification.
> * Obsolete feature
> 	An existing or deprecated feature has ceased to  exist and that is
> listed for historical purpose.
> * Module
> 	A collection of semantically-related features that represents a unit
> of functionality.
> ]]] - http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#glossary
> 
> 
> We define Implementation
> 34 times in Process document
> 95 times in QA Specification Guidelines.
> 
> but we don't define interoperability. We use the terms
> interoperability, interoperable, etc. about 30 times. Process document
> is using it 5 times
> 
> 
> --
> Karl Dubost - http://www.w3.org/People/karl/
> W3C Conformance Manager
> *** Be Strict To Be Cool ***

Received on Tuesday, 15 March 2005 12:13:52 UTC