- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Mon, 9 Jan 2006 13:53:50 -0500
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Jan 6, 2006, at 3:41 PM, Seaborne, Andy wrote: > So if a server sends back 403, it isn't a success. It isn't > MalformedQuery or QueryRequestRefused either so it isn't part of > the SPARQL interface. My implementation experience is that status > codes other than 200, 400 and 500 arise when using common > deployment platforms. My proposal is to (for HTTP) state > explicitly that other status codes can be used in a SPARQL interface. Quoting from the CR version of WSDL 2.0 Part 1: Core Language: Faults other than the ones described in the Interface component may also be generated at run-time, i.e. faults are an open set. The Interface component describes faults that have application level semantics, i.e. that the client or service is expected to handle, and potentially recover from, as part of the application processing logic. For example, an Interface component that accepts a credit card number may describe faults that indicate the credit card number is invalid, has been reported stolen, or has expired. The Interface component does not describe general system faults such as network failures, out of memory conditions, out of disk space conditions, invalid message formats, etc., although these faults may be generated as part of the message exchange. Such general system faults can reasonably be expected to occur in any message exchange and explicitly describing them in an Interface component is therefore uninformative. Cheers, Kendall
Received on Monday, 9 January 2006 18:53:58 UTC