- From: Lofton Henderson <lofton@rockynet.com>
- Date: Tue, 25 Jan 2005 07:44:18 -0700
- 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 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 14:46:00 UTC