Re: service description discovery

On 14 Sep 2009, at 10:21, Alexandre Passant wrote:
> Hi,
>
> On 11 Sep 2009, at 03:31, Gregory Williams wrote:
>
>> I'm trying to sort out where we left the discussion on service  
>> description discovery. As best I can tell, there are (roughly) four  
>> remaining options that we've discussed:
>>
>> option 1: link header that points to a URI where the service  
>> description can be downloaded (2,9,0)
>> option 2 - use the HTTP OPTION verb on the endpoint URI (8,4,1)
>> option 7 - standard query, using content negotiation to get the  
>> service description (4,1,4)
>> option 8 - new protocol operation (no strawpoll results yet)
>>
>> The numbers in parentheses represent the strawpoll votes for (-1,  
>> 0, +1), respectively.
>>
>> 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 ?
>
>> Having said that, I think we also left off on the August 18th  
>> telecon without discussing the option 7' variant with RDFa.
>>
>> So, I guess I'd like to hear what people think of option 8 and the  
>> RDFa variant(s) of option 7. Steve has previously discussed an  
>> implementation problem when using option 8 and reverse proxies, and  
>> there was some worry about the lack of widespread support for RDFa.  
>> Anything else?
>
> 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 ?

It seems to be pretty common in industry. We don't do it for SPARQL  
endpoints, but most of our technology partners (eg. the BBC) do.

> 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

Isn't it an HTTP header?

> 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

XMLHttpRequest supports it on all major browsers, the only real issue  
is the caching situation.

> option 7: proper conneg is a pain to specify and implement
> option 7' (RDFa): pb with (non-X)HTML + implies there is a webpage  
> at the endpoint URL.
>
> So, shouldn't we simply focus on the one that has no issue, if any.

Is that Option 1?

> And it not, consider the ones with the less problematic issues (to  
> me, would be 8 in that case).

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD

Received on Monday, 14 September 2009 10:24:00 UTC