Re: [comments] SPARQL Protocol against QA SpecGL ICS [OK?]

Hi Dan,

* Introduction

It's all about explicit versus implicit, and about uniformity for a  
developer. The QA WG has worked on these guidelines trying to make a  
fair balance between the requirements and the implementation of these  
requirements. When we are suggesting something, it is not intended to  
make your life difficult, but to make the life of implementers easier  
in terms of understanding the specification. Developers read MANY  
specifications, each time they have to update to a new format, a new  
way of introducing the concepts, etc, It's very very difficult for them.

We receive often the comments from the community to have obscure  
specifications, so we try in these review to not only give techniques  
to achieve the conformance (QA) but also to encourage a common layout  
to introduce these concepts to make them easier to understand.

Le 2005-10-12 à 17:39, Dan Connolly a écrit :
> 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.

So you see, you said yourself that the material is here.
I would say that it could be a little bit more explicit and  
introduced with a proper conformance section, labeled as such. I  
think it would make the life of developers easier.

SPARQL is a very important technology, I think it's even one of the  
most important technology which has been designed to make the  
Semantic Web a success. And it's why I have been so picky on the  
document. I would like that SPARQL has the same success than HTML  
4.01 specification had in its time. Not missing a window is fine, but  
having a clear document, easy to read, informative, a reference for  
years is also very important.

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


Not much to do. It's a short document. It's not mandatory you label  
each section inside the document, but you could for example say in a  
conformance section. The sections X, Y and Z are normative, and the  
section L, M are informative.

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


I have read the document and I still don't know if it's possible to  
create an extension or not. It's what the term "Formalizing" means  
here. It means say it explicitly yes and no to remove any ambiguities.

Being explicit.

I'm pretty sure we are going in the right direction.



-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***

Received on Thursday, 13 October 2005 01:38:11 UTC