W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > October 2010

Re: SPARQL 1.1 Protocol: Format of fault messages

From: Richard Cyganiak <richard@cyganiak.de>
Date: Mon, 4 Oct 2010 21:17:28 +0100
Cc: Richard Newman <rnewman@twinql.com>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
Message-Id: <0D7BE1A9-81C2-41EE-98EB-6C097EC77BC8@cyganiak.de>
To: Eric Prud'hommeaux <eric@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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 October 2010 20:39:40 GMT