Re: comment: SPARQL Protocol: inconsistent parameter names [Was: agenda: RDF Data Access 30Aug]

Kendall Clark wrote:
> On Mon, Aug 29, 2005 at 06:31:28PM +0100, Seaborne, Andy wrote:
> 
> 
>>Would it be possible to do it the other way round?
> 
> 
> Yes, of course. I considered doing it this way around, precisely for the
> reasons you suggest:
> 
> 
>>There are deployed HTTP based examples services (mine, Dave's, cwm's SPARQL 
>>server) and there are already embedded links using the "query=" form e.g. 
>>on http://esw.w3.org/topic/DawgShows
> 
> But I was gonna go with sparql-query because it's more specific, and "query"
> could be used in a future version of the protocol for RDF query languages
> other than SPARQL. I think that's worth the change over, since
> "sparql-query" does work, for both, today, though with the cost you suggest.
> 
> So it's certain, but small incompatible change today versus probable, but
> larger incompatible change in the future. I'm not hugely committed either
> way, but I will note that folks deploying to an unfinished standard should
> be prepared for gratuitous-seeming changes... :>
> 
> I'm happy leaving the change to a straw poll during tomorrow's call.
> 
> Cheers, 
> Kendall
> 

In the SOAP form, the element is already qualified by the namespace so using 
"query" not "sparql-query" is clear.  (It also happens to be the outer element 
name.)

For the HTTP form, the argument is that "query" could be used in a future 
version of the protocol and that there will be a "probable, but larger 
incompatible change in the future.".  But SPARQL is the protocol - I dont 
understand the "probable".

This seems to be weakly reserving the word against an unspecified need and thus 
does not even encourage migration from todays services which do use "query" - 
they shouldn't offer both "sparql-query" and "query" for compatibity because 
"query" is for something else.

The other oddity I see is that we now have the query language name in the 
request when we have previously decided not to have a "lang=" parameter. I 
thought we settled on the query language being part of the service - different 
language, different service. "sparql-query" to allow for other query languages 
seems to be moving back a multi-language per service design and that is better 
done with a "lang=" parameter.  This does given an extension point - if there is 
no "lang=" it would mean "SPARQL classic", if there is a "lang=" parameter, it 
woudl name the language.

	Andy

Received on Tuesday, 30 August 2005 08:57:38 UTC