W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > January 2006

[OK?] Re: SPARQL Protocol Spec Examples

From: Kendall Clark <kendall@monkeyfist.com>
Date: Tue, 17 Jan 2006 16:54:38 -0500
Message-Id: <0732392B-5CFB-4A25-A7E1-B8A3C273F75B@monkeyfist.com>
Cc: Leigh Dodds <leigh@ldodds.com>, dawg comments <public-rdf-dawg-comments@w3.org>, Dan Connolly <connolly@w3.org>
To: Kendall Clark <kendall@monkeyfist.com>


On Nov 4, 2005, at 4:52 PM, Kendall Clark wrote:

>
>
> On Nov 4, 2005, at 4:49 PM, Leigh Dodds wrote:
>
>>> 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.
>
> No, I suspect that that's probably correct. The "error message"  
> isn't standardized, so the only thing a client will be able to do  
> is to try to do something with the body of the response. I think  
> that's "extraction" enough, but I certainly see how it's not  
> exactly ideal. I'll bring this to the WG's attention.
>
> Stay tuned for an answer. :>

The WG discussed this issue and declined to specify any format for  
describing error messages. As far as clients being unable to  
"reliably extract an error message", I can only reiterate that in the  
HTTP case, for example, the WSDL fault is serialized by an HTTP  
status code (400 for MalformedQuery and 500 for QueryRequestRefused)  
and the (optional) fault-details part of the WSDL fault may be  
included in the body of the HTTP request, which I believe to be  
reliably extractable.

Please let us know whether this sufficiently addresses yr comments?

Cheers,
Kendall Clark
Received on Tuesday, 17 January 2006 21:54:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:50 GMT