- From: Sandro Hawke <sandro@w3.org>
- Date: Tue, 09 Oct 2012 09:45:13 -0400
- To: "Polleres, Axel" <axel.polleres@siemens.com>, SPARQL WG <public-rdf-dawg@w3.org>
On 10/09/2012 03:29 AM, Polleres, Axel wrote: > Hi, > > @sandro, is it ok to fix editorial things like aligning wording and maybe putting in some anchors > to cross-references terminology in the last transition from PR to Rec still? Yes, it's okay to make editorial improvements at every stage. I think we still have time to fix it before PR, though:procedurally, we'll have about 10 days between the decision to publish [hopefully today] and actually publishing. I know groups differ in how much they want the document to be frozen when they make the decision -- many groups make the decision to publish "pending implementation" of specific changes, reviewed by the chairs or other chosen people. -- Sandro > Axel > > >> -----Original Message----- >> From: Gregory Williams [mailto:greg@evilfunhouse.com] >> Sent: Montag, 08. Oktober 2012 18:41 >> To: Chime Ogbuji >> Cc: SPARQL Group >> Subject: Re: Ambiguity between SPARQL 1.1 RDF protocol query >> via GET and SD retrieval >> >> On Oct 6, 2012, at 1:07 PM, Chime Ogbuji wrote: >> >>> While porting over my implementation of the SPARQL 1.1 RDF >> protocol, I noticed that the language in the Service >> Description specification about how a service description >> document is dereferenced is a bit ambiguous. >>> "SPARQL services made available via the SPARQL Protocol >> should return a service description document at the service >> endpoint when dereferenced using the HTTP GET operation" >>> Whereas the SPARQL 1.1 RDF Protocol document says: >>> >>> "Protocol clients may send protocol requests via the HTTP >> GET method. When using the GET method, clients must URL >> percent encode (http://www.ietf.org/rfc/rfc3986.txt) all >> parameters and include them as query parameter >> (http://www.ietf.org/rfc/rfc3986.txt) strings with the names >> given above" >>> Under the query string parameters column for this binding >> it says: "query (exactly 1)". >>> Unless I've missed text elsewhere that clarifies this, >> reading both as they are written begs the question about >> whether a query via GET binding request SHOULD return an SD >> document. My assumption is that the distinction is between a >> GET request to the service endpoint *without* a query >> parameter versus a request *with* this parameter - returning >> an SD document if the query parameter is not provided. >>> This distinction should be made explicit. Some suggested >> text (in SD specification): >>> "[...] should return a service description document at the >> service endpoint when dereferenced using the HTTP GET >> operation without any query parameter strings provided" >> >> I agree that the language here could be made better by being >> more specific. In looking this over, I also noticed that the >> terminology between the two documents has drifted a bit >> (which is a bit embarrassing since I edited both). SD says: >> >> """ >> A SPARQL [Protocol] service is commonly referred to as a >> "SPARQL endpoint". >> """ >> >> while Protocol has two different definitions for "Service" >> and "Endpoint": >> >> """ >> SPARQL Protocol service >> An HTTP server that services HTTP requests and sends back >> HTTP responses for SPARQL Protocol operations. The URI at >> which a SPARQL Protocol service listens for requests is >> generally known as a SPARQL endpoint. (Also known as: service) >> >> SPARQL endpoint >> The URI at which a SPARQL Protocol service listens for >> requests from SPARQL Protocol clients. >> """ >> >> Does anyone (esp. chairs) think fixing this before the >> upcoming publication would be a problem (or perhaps it's >> something that could be fixed post-publication)? I don't >> think fixing this is a substantive change as I believe the >> spec text, examples, and tests are all pretty clear about >> what is meant, but certainly don't want to cause problems for >> anyone who thinks otherwise. >> >> thanks, >> .greg >> >> >>
Received on Tuesday, 9 October 2012 13:45:26 UTC