- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Mon, 4 Oct 2010 21:17:28 +0100
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: Richard Newman <rnewman@twinql.com>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
Eric, On 4 Oct 2010, at 19:53, Eric Prud'hommeaux wrote: > I've not seen any endpoints which don't have HTML interfaces. Then look again. You could use a list of popular SPARQL Protocol implementations [1] to check your claim. I just did the work for you. Many endpoints serve an HTML query form at the endpoint URL, but not all (see Joseki, D2R, Sesame, RAP). Just a few (D2R, Joseki) serve error messages in HTML. They actually only serve generic web server exception pages, so the use of HTML is developer laziness rather than by design. These are the only implementations I could find that return error messages in HTML. The vast majority of implementations serve error messages in plain text (Virtuoso, Talis Platform, Sesame, ARC2). 4store serves them in XML; RAP fails with a 500 and no message body. Virtuoso is the only server implementation I'm aware of that actually returns query results in HTML; all others default to XML and some support JSON as well. Not a single implementation supports HTML for *all* aspects of the protocol (result and failure). So I think it's more accurate to say that they all aim for machine clients, but most implementors have expended some effort towards making the testing, exploring and debugging of an endpoint possible from a browser as well. None of them have been built with web browsers as a primary client in mind. I conclude that your call for XHTML as the error result format addresses a need that you perceive, but that doesn't actually exist. Hence, using a format that is more easily parsed, less verbose, and more in line with the format for successful responses, while still providing acceptable user experience when testing/debugging/exploring with a browser, better serves both client and server implementors. Best, Richard [1] http://lists.w3.org/Archives/Public/public-lod/2010Oct/0001.html
Received on Monday, 4 October 2010 20:39:39 UTC