specifying one human-readable error/warning format?

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