- From: Gregory Williams <greg@evilfunhouse.com>
- Date: Mon, 17 Aug 2009 22:25:12 -0400
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
- Cc: Jacek Kopecky <jacek.kopecky@sti2.at>
On Aug 17, 2009, at 7:26 AM, Jacek Kopecky wrote: > Hi Greg, > > there is no reason that the content returned by OPTIONS should not > also > be accessible by GET elsewhere; the HTTP header Content-Location would > help here. In this way, OPTIONS on the service endpoint would be a > clear > machine-oriented way of discovering service descriptions; for > human-oriented ways, a link from the endpoint's documentation or query > form (with conneg for HTML) or whatever should be good. > > What do you think? In addition to previously mentioned issues with OPTIONS (non- cachability), I'm hesitant to go with anything that suggests two different paths to get at a service description. If we're going to suggest that the service description be available via GET (I'm hoping via conneg), then *also* going with OPTIONS seems like an uphill battle, trying to drag public use of OPTIONS along with our desire to get widespread service descriptions. .greg
Received on Tuesday, 18 August 2009 02:49:22 UTC