- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Mon, 4 Oct 2010 20:01:31 +0100
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: public-rdf-dawg-comments@w3.org
Eric, 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. http://richard.cyganiak.de/2010/sparql/error.php 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="http://www.w3.org/2005/sparql-results#"> <head> <error><![CDATA[ error at URI 3store:default#:1 - syntax error, unexpected $end ]]></error> </head> </sparql> Nice one, Steve! Best, Richard [1] http://richard.cyganiak.de/2010/sparql/error-srx.php > > >> Richard > > -- > -ericP
Received on Monday, 4 October 2010 19:02:08 UTC