Re: SPARQL 1.1 Protocol: Format of fault messages

> I think it is user-facing. I've not seen any endpoints which don't
> have HTML interfaces. I read this as a recognition that the browser
> interface is a very useful query development tool and one of the
> distinguishing features of the SemWeb.

... but the HTML endpoint is not necessarily the Protocol endpoint.

If you're making a request with Accept: text/html, then sure, put an  
HTML version of the error in the response body. Heck, do that all the  
time... so long as you also put the error in a well-defined header, at  
least for non-browser clients.

>> To flip the question around: are you seriously suggesting that it's
>> better to embed a one-line error message inside a chunk of XHTML,
>> rather than to put it in a well-known header or similar HTTP-level
>> format?
> I'd say yes because it introduces no new requirements to the pipeline.
> The requirement of access to headers can seriously limit the choice
> of libraries and architectures.

So can the requirement to process XHTML in an error handler: you just  
added, say, Jericho as a dependency to an unattended bulk fetcher, or  
made it impossible to treat SPARQL queries as opaque data fetch jobs.

For SOAP, not raising a well-described fault on error is *wrong*. I  
hope that's something with which everyone can agree, despite the fact  
that nobody seems to use SOAP.

For HTTP, my opinion remains that returning details of an error in a  
way that is not amenable to processing by the lowest common  
denominator (i.e., simple HTTP clients, probably without an XML  
parser) is unkind.

Anyway, I think I've stated my position, so I'm done; I don't want to  
get into an argument. This isn't my problem to solve, and the outcome  
is unlikely to affect me these days.



Received on Monday, 4 October 2010 19:35:09 UTC