Re: SPARQL Protocol Spec Examples

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.

Cheers,

L.

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