Re: service description discovery

On 14 Sep 2009, at 11:16, Steve Harris wrote:

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

Ok - I was not aware of that - so that might indeed be a more complex  
issue than I thought.

>
>> 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?

My mistake - I thought about the link rel element in the HTLM 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
>

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Received on Monday, 14 September 2009 11:14:37 UTC