W3C home > Mailing lists > Public > www-qa-wg@w3.org > January 2005

Re: Action Item to Define Best Practice

From: Lofton Henderson <lofton@rockynet.com>
Date: Tue, 25 Jan 2005 07:44:18 -0700
Message-Id: <>
To: Mark Skall <mark.skall@nist.gov>
Cc: www-qa-wg@w3.org

[...When I saw Dom's mail of this morning about Mark's 12/23 message, I 
looked for my own reply to Mark in the QAWG archive, and didn't find it -- 
never went out -- stuck in IN box -- here it is, for consideration when 
Mark answers Dom's questions...]

At 10:17 AM 12/23/2004 -0500, Mark Skall wrote:

>I was assigned an action item to define a best practice to address the 
>problem I identified during my review of XINCLUDE for conformance to 
>SpecGL.   The problem had to do with not knowing if various features, like 
>deprecated features, were present and thus not being able to determine if 
>the absence of the identification of these features, as required by 
>SpecGL, was non-conformance or non applicability.
>After careful review, I decided that there was already a best practice 
>that solves this problem - it is the best practice for providing an ICS.
>The existing ICS best practice asks for implementations to indicate which 
>capabilities and optional features have been implemented.  In our telcon 
>discussion we agreed that this would be a possible solution to the problem 
>but that we would need some way to make the ICS accessible from the 
>spec.  However, the existing best practice specifically says that "This 
>Good Practice suggests that the specification itself include an ICS proforma."

I might be confused about what you're suggesting.  In the telecon, we were 
talking about how to determine whether a target specification satisfies the 
deprecation and optionality items in the SpecGL ICS, i.e. requirements of 

What you have just quoted refers to an ICS that deals with implementation 
conformance to the target specification.  We seem to be talking about two 
ICS here.

If I understand correctly, you're saying:
** if the target specification satisfies the GP of SpecGL that the target 
specification provide an implementation ICS pro-forma,
** then there will (or should) be items in said ICS pro-forma related to 
optional and deprecated features in target specification,
** and those items in the implementation ICS pro-forma can be used to 
verify whether SpecGL's deprecation (and optionality) identification 
requirements are met by target specification.

While think I see the reasoning here, I'm not sure that I'm comfortable 
with that indirection in satisfying the requirement.  Especially since:
1.) the ICS-proforma item is a GP (in SpecGL), whereas the deprecation item 
is a Requirement (in SpecGL);
2.) the ICS-proforma item is universally "NO" so far in our (QAWG) spec 
reviews against SpecGL, and I suspect that it will remain a low-priority 
item for spec authors.
3.) whereas I consider being able to answer the deprecation (optionality) 
questions pretty important.


>It seems to me that following this best practice would take care of this 
>problem.  Thus, there is no need for a new best practice.
>Happy holidays.
>Mark Skall
>Chief, Software Diagnostics and Conformance Testing Division
>Information Technology Laboratory
>National Institute of Standards and Technology (NIST)
>100 Bureau Drive, Stop 8970
>Gaithersburg, MD 20899-8970
>Voice: 301-975-3262
>Fax:   301-590-9174
>Email: skall@nist.gov
Received on Tuesday, 25 January 2005 14:46:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:34 UTC