Re: Action Item to Define Best Practice

Dom, Lofton

Lofton essentially captured what I meant (that the target spec ICS would
account for all features that are present, like deprecated features, and
thus we could then examine the spec to see if those features were
satisfactorily documented).  I also share Lofton's concerns, especially with
respect to the "manditoriness" of the Good Practices. Certainly, the ICS
asked for by SpecGL would be even more appropriate since it would document
explicitly what features are supported by the target spec. If we could
mandate that, we'd be set. 

Mark

--------------------------
Sent from my BlackBerry Wireless Handheld


-----Original Message-----
From: www-qa-wg-request@w3.org <www-qa-wg-request@w3.org>
To: Mark Skall <mark.skall@nist.gov>
CC: www-qa-wg@w3.org <www-qa-wg@w3.org>
Sent: Tue Jan 25 09:44:18 2005
Subject: Re: Action Item to Define Best Practice


[...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 
SpecGL.

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.

-Lofton.


>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
>
>
>****************************************************************
>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 19:31:07 UTC