- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Thu, 29 Dec 2005 12:47:46 -0500
- To: dawg mailing list <public-rdf-dawg@w3.org>
Folks, Leigh Dodds (who's done good work building SPARQL web front ends) suggests, in a sequence of messages starting here, http:// lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Nov/0002, that, given the current spec, "a client is not going to be able to reliably extract an error message, just detect the fault"... The fault type, for the HTTP binding, is determined by the HTTP status code, which is reliably detectable. But our current design intentionally says that there may be a human readable explanation of this fault carried in the body of the HTTP response, and that the type of the body is unspecified. Some services may want to return XHTML, others XML, others RDF, etc. Leigh believes (err, I think) that it's this bit that's the "error message", but WSDL 2 only knows about faults and for the HTTP binding you signal faults with HTTP status codes. The body of the HTTP response is not (as I understand things) the fault itself. SPARQL services are free to put whatever they want in the body, and I don't see any good reasons to constrain them on this point. I don't believe Leigh means literally that clients can't extract those bits, since every HTTP client library allows one to access the contents of the body of an HTTP response. What he wants is a standardized format or vocabulary or type for the body itself. I'm satisfied with the design as it stands (including my expectation that there will be a way in some future SPARQL service description language like SADDLE to state what a service puts into the body of a fault message), but I told Leigh I'd raise this issue with the WG to see if that represents some consensus or something we haven't thought explicitly about. Cheers, Kendall
Received on Thursday, 29 December 2005 17:47:40 UTC