W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > November 2005

Re: SPARQL Protocol Spec Examples

From: Leigh Dodds <leigh@ldodds.com>
Date: Fri, 04 Nov 2005 21:49:34 +0000
Message-ID: <436BD76E.4030809@ldodds.com>
To: Kendall Clark <kendall@monkeyfist.com>
Cc: public-rdf-dawg-comments@w3.org

Kendall Clark wrote:

> On Nov 4, 2005, at 3:30 PM, Leigh Dodds wrote:
>> However I still think its worth defining the format(s) in which
>> faults will be returned otherwise a client won't be able to
>> reliably extract an error message: will it be the complete response  
>> body, within some arbitrary XML structure, embedded somewhere in an  
>> (X)HTML document?
> Well, as I said, it's the HTTP status code. A client can reliably  
> extract that like:
> if response.status_code == "500":
>    print "Hi mom!"

You're extracting the fact that there's an error, not the message.
I understand the the fault is signified in the response code. (see
my other comment re: separating out the errors from refusal to
process requests).

>> While the types in the spec may be used abstractly in the WSDL, I
>> don't think there reason not to mandate them as the preferred format
>> for the error message.
> Well, sure there is. Lotsa people might want to use RDF or XHTML or  
> HTML or... We didn't reach any consensus about this yet.

Well, the same is true of the results format. I can use content
negotiation (Accept: header) to request alternatives.

Consider an AJAX client: in that scenario I certainly don't want a
full XHTML document describing the error, I just want to get an error
message to stick on the page in an alert.

> I suspect the only way to bring this up again for WG consideration is  
> if there is some new information that vitiates or problematizes the  
> existing design. Do you know of anything like that?

OK. I've nothing extra to add. I still think a client is not going to
be able to reliably extract an error message, just detect the fault.


Received on Friday, 4 November 2005 21:49:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:06 UTC