On Tuesday, May 3, 2005, 5:31:48 PM, Karl wrote:
KD> Dear Chris,
KD> Thanks for your comments on the Last Call version of the QA Framework:
KD> Specification Guidelines[0] - 22 November 2004
KD> After two weeks from now (on May 18, 2005), the lack of answer will
KD> be considered as if you had accepted the comment.
KD> Original comment (bug 1158):
KD> http://lists.w3.org/Archives/Public/www-qa/2005Mar/0014.html
KD> The QA Working Group has completed a SpecGL ICS for SpecGL itself,
KD> available at:
KD> http://www.w3.org/QA/WG/2005/04/specgl-specgl-ics.html
KD> We believe SpecGL now conforms to itself, since it implements all the
KD> Requirements; it also implements all but one Good Practice.
Thank you.
KD> Follow
KD> belows details answers to the comments made in the footnotes of the ICS
KD> the TAG filled for the previous version of SpecGL [1]
KD> 1) No link to Class of Products statement
KD> We believe linking to the section including the statement is sufficient
OK
KD> 2) ICS required for claiming conformance?
KD> We have clarified that
KD> "if all the Requirements are checked on the ICS as being satisfied, then
KD> conformance can be claimed as detailed below", linking to the
KD> conformance claim section, which requires linking to a completed ICS.
Much better
KD> 3) Class of Product vs Scope
KD> The scope is what is covered by the specification; the class of products
KD> are part of defining the scope, but a more narrow (and in our opinion
KD> important) aspect of it that directly affects conformance.
OK
KD> 4) "Using the defined term conformance model..."
KD> Done
Thanks
KD> 5) Checking whether references have been reviewed carefully
KD> The good practice has been reworded to be less workflow oriented
Yes, so I see.
KD> 6) Positive statements for no subdivision
KD> SpecGL clarifies now that a positive statement is indeed needed, and
KD> indeed states that it is not subdivided.
Great.
KD> 7) No extensibility mechanism
KD> We disagree that SpecGL doesn't define an extensibility mechansim. In
KD> section 4.3 (Extensibility), we say that one can extend SpecGL as long
KD> as it doesn't negate the requirements given in the specification. This
KD> is a basic extensibility mechanism, and we don't think at this time
KD> there is any need for a more complex one.
Well, okay. Bear in mind then, that you can never publish a second
edition or a new version of this specification that has any deprecated
or obsolete features, as these would contradict the one constraint that
you have on extending the specification. Also bear in mind that any
third party can conformantly claim to have published version 2 of
SpecGL.
However, your addition of a comments field on the pro-forma goes a long
way to allowing specifications to talk about what their extensibility
mechanism is, so overall i think this is fine.
The main point in this part of the comment was to test whether the
extensibility mechanism requirement was truly universal.
Would a comment "We have no extensibility mechanism because we think they
are bad" count as an extensibility mechanism in terms of SpecGL
conformance?
KD> 8) No deprecated features listed
KD> SpecGL clarifies that making a positive statement about deprecated
KD> features is only needed when there was a previous version of the
KD> specification (which is not the case for SpecGL itself)
Okay (although I think first versions of specifications can sometimes
have deprecated features).
KD> 9) No obsolete features identified
KD> Same as 8
OK
KD> 10) & 11) Hard to demonstrate some GP
KD> The QA WG has moved the given GP into a separate informative section of
KD> SpecGL, since they were indeed too workflow-oriented to fit with the
KD> other Good Practices.
Thanks
KD> [0] http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/
KD> [1] http://lists.w3.org/Archives/Public/www-qa/2005Mar/att-0014/
KD> qaframework-recursiveconformance.html
Nice job.
--
Chris Lilley mailto:chris@w3.org
Chair, W3C SVG Working Group
W3C Graphics Activity Lead