Re: SPARQL 1.1 Protocol: Format of fault messages


I want to address your assertion (which Ian made as well) that XML as  
error message format breaks human interaction.

On 4 Oct 2010, at 13:20, Eric Prud'hommeaux wrote:
>> To be honest, given that you seem to be happy with XML as the
>> default successful result format, I don't understand why you go to
>> such efforts for a human-readable and extensible *error* format. You
>> have that a bit backwards.
> Just because all of the existing clients have browser-friendly error
> messages and I doubt they want to break those human interactions.
> Putting e.g. sparlq-xml-results in user's faces will turn some folks
> off.

Here's a page that returns application/xml with a 400 status code.  
Please open it with a few browsers of your choice and with curl.

Are you done? Did you see a usability problem? This isn't any worse  
than shipping text/plain, as most server implementations do today. If  
you want a truly beautiful page then you can add some XSLT, although  
it's sufficiently human-friendly without.

(In all fairness, this only works for application/xml. With the  
perhaps more correct application/sparql-result+xml media type, Firefox  
and Chrome don't render the XML's text content but show a generic  
error page, and Safari downloads the XML rather than rendering it --  
see [1] if you want to try that one yourself. I also had to add some  
padding to make the body larger than 512 byte because Google Chrome  
thinks it's a good idea to copy IE bug-for-bug. None of these issues  
are an obstacle IMO, they can be pointed out in a note in the spec.)

So I really think that XML as error format has it all:

- is machine-processable
- shows up well in browsers, hence human-friendly (if done with care)
- requires no other parser than the format for successful responses
- is as extensible as the format for successful responses
- is conformant with the SPARQL 1.0 protocol

If the use of XML is recommended with a SHOULD in the spec, then all  
existing implementations remain conformant, and innovative new  
approaches that want to go beyond what's recommended in the spec would  
still be conformant as well.

Oh and finally, I just discovered that 4store reports errors like this:

<?xml version="1.0"?>
<sparql xmlns="">
error at URI 3store:default#:1 - syntax error, unexpected $end

Nice one, Steve!



>> Richard
> -- 
> -ericP

Received on Monday, 4 October 2010 19:02:08 UTC