- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Tue, 17 Jan 2006 16:54:38 -0500
- To: Kendall Clark <kendall@monkeyfist.com>
- Cc: Leigh Dodds <leigh@ldodds.com>, dawg comments <public-rdf-dawg-comments@w3.org>, Dan Connolly <connolly@w3.org>
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 UTC