- From: Dan Connolly <connolly@w3.org>
- Date: Wed, 12 Oct 2005 16:39:29 -0500
- To: Karl Dubost <karl@w3.org>
- Cc: public-rdf-dawg-comments@w3.org
On Tue, 2005-10-11 at 18:17 -0400, Karl Dubost wrote: > This is a review of "SPARQL Protocol" against QA SpecGL ICS. > > SPARQL Protocol for RDF > W3C Working Draft 14 September 2005 > http://www.w3.org/TR/2005/WD-rdf-sparql-protocol-20050914/ [...] > # QA Specification Guidelines - Implementation Conformance Statement > This version: [http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/ > specgl-ics][3] > > ## Checklist table > > [Requirement 01: Include a conformance clause.][22] > NO and no reference to a document which would contain such a > section. [...] > [Requirement 03: Identify who and/or what will implement the > specification.][32] > NO. The "classes of products" are not identified, which will > make it difficult to create a conformance clause. [...] >[Requirement 06: Create conformance labels for each part of the > conformance model.][37] > NO. The conformance section is not defined. It's not clear to me how you came to those conclusions. The document does cover conformance and product classes: "A compliant SPARQL Protocol service must support the SparqlQuery interface; if a SPARQL Protocol service supports HTTP bindings, it must support the bindings as described in sparql-protocol-query.wsdl. A SPARQL Protocol service may support other interfaces." See also other occurrences of must/may/should marked up in the document. > [Requirement 08: Indicate which conformance requirements are > mandatory, which are recommended, and which are optional.][41] > NO. if we consider the fact you are using RFC 2119, we could > say yes, Quite. > but there's also the fact that you do not define which > sections in your document is normative or not normative. We didn't find it necessary to distinguish normative material from informative material in order to specify the protocol. > [Requirement 11: Address Extensibility.][52] > NO. This has not been addressed at all. Create a section on > extensibility and explain the extensibility, requirements or your > language. If it's not extensible, say it. The document defines a protocol; it does not introduce any extensibility mechanisms, so it does not discuss extensibility. The QA document says "Formalizing the position of the Working Group in a clearly defined section and prose removes ambiguities for the specification users about the possibility of developing extensions or not" which presumes that there are ambiguities to be removed. We are not aware of any ambiguities. If you find some, feel free to point them out. Until then, I hope you'll agree that the document does address extensibility as much as is warranted. Please let us know whether this addresses your comments to your satisfaction. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Wednesday, 12 October 2005 21:39:36 UTC