- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Tue, 10 Jan 2006 13:17:20 +0000
- To: Kendall Clark <kendall@monkeyfist.com>
- CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Kendall Clark wrote: > 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 > > Kendall, Thnaks for finding that extract - it certainly helps me. Given that faults are an open set, then we just need to be sure that the language of the SPARQL protocol is not providing a stronger condition. It does do that for QueryRequestRefused where it places a "must" requirment (MalformedQuery only uses "should"). Andy
Received on Tuesday, 10 January 2006 13:23:13 UTC