- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 11 Jan 2006 15:39:08 +0000
- To: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
- CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Steve Harris wrote: > On Tue, Jan 10, 2006 at 01:36:36 -0500, Kendall Clark wrote: > >> >>On Jan 10, 2006, at 1:01 PM, Seaborne, Andy wrote: >> >> >>>Other than what? I am just reading the spec and making an >>>interpretation. I'm not advocating a design change. >> >>I believe that changing must to should changes the design. >> >>One easy way to solve this: if the WG agrees with you and wants >>should, I'll change it immediately. The problem is we are the only >>ones who seem to care about this, and I don't agree with you. > > > I care, but I dont totally understand the issues (I'm WSDL illiterate). I > want to be able to send back any reasonable HTTP code for uncommon > conditions (eg. server segfaults, out of memory), but as far as I can see > you both think that should be OK. I certainly hope so. The argument is now about when a service "refuses" a request because the text says: """ QueryRequestRefused This fault message *must* be returned when a client submits a request that the service refuses to process. """ The one I have difficulty is how a security problem (403) is not a refusal by the service. > > However, apache returns 500 server errors when something internal goes > wrong, and as my main HTTP mechanism is apache modules its out of my to > control to return a non SPARQL 500 if something really bad goes wrong. > OTOH I could argue that at that stage its just not a SPARQL service, as > its not capable of processing anything at all. This sort of condition is one I've encountered and started me off on all this. Andy > > - Steve >
Received on Wednesday, 11 January 2006 15:41:13 UTC