Re: service description discovery

On Sep 14, 2009, at 5:21 AM, Alexandre Passant wrote:

> On 11 Sep 2009, at 03:31, Gregory Williams wrote:
>
>> I don't believe we ever got a vote on option 8. Between the other  
>> 3, option 7 had the most +1 votes, as well as the highest +1:-1  
>> ratio.
>
> You mean option 2 ?

I didn't think so, but I suppose I could be wrong. I believe the  
preferences I tried to summarize were correct, but I also believe I  
got some of the vote counts wrong. This is all based on the chatlog at  
[1]. At this point, I believe the proper counts are:

option 1: link header that points to a URI where the service  
description can be downloaded
	-1: 2 votes
	0: 9 votes
	+1: 0 votes

option 2 - use the HTTP OPTION verb on the endpoint URI
	-1: 8 votes
	0: 3 votes
	+1: 1 vote

option 7 - standard query, using content negotiation to get the  
service description
	-1: 5 votes
	0: 1 vote
	+1: 4 votes

option 8 - new protocol operation (no strawpoll results yet)
	no votes yet

If you think I've misunderstood the strawpoll results, please to  
correct me.

> It seems to me that the issues raised by Steve with option 8 happen  
> is really particular cases - any idea on how often that reverse  
> proxy setting happens ?
>
> In addition, all others from the list (besides option 2 ?) also got  
> issues:
>
> option 1: link header implies that there is an HTML page at the  
> endpoint URL which is not always the case
> option 2: don't see any particular issue here, but I'm wondering how  
> easy is that, from a usual Web browser, to send that HTTP OPTION verb


As mentioned by others, there's the caching issue to be concerned  
with. Also, and I realize this doesn't apply to everyone (depending on  
implementation and use cases), I would very much like to see a  
solution where I could use the service description URI in a FROM  
clause with an implementation that dereferences FROM URIs. This would  
allow querying of the service description with either the endpoint in  
question or with any other endpoint so long as the FROM URI could be  
dereferenced. This isn't possible with option 2 but is possible with  
options 1, 7, and 8 (possibly involving an extra request to determine  
what the SD URI is).

thanks,
.greg

[1] http://www.w3.org/2009/sparql/meeting/2009-08-18

Received on Monday, 14 September 2009 17:47:16 UTC