- From: Alexandre Passant <Alexandre.Passant@deri.org>
- Date: Tue, 15 Sep 2009 07:23:10 +0100
- To: Gregory Williams <greg@evilfunhouse.com>
- Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
On 14 Sep 2009, at 18:46, Gregory Williams wrote: > 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: My mistake, I read (+1, 0, -1) :-/ Alex. > > 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 > -- Dr. Alexandre Passant Digital Enterprise Research Institute National University of Ireland, Galway :me owl:sameAs <http://apassant.net/alex> .
Received on Tuesday, 15 September 2009 06:23:50 UTC