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

Re: SPARQL 1.1 Protocol: Format of fault messages

From: Richard Newman <rnewman@twinql.com>
Date: Mon, 4 Oct 2010 12:34:35 -0700
Cc: Richard Cyganiak <richard@cyganiak.de>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
Message-Id: <12ABC92F-4F28-41B9-A441-AAF50AF88636@twinql.com>
To: Eric Prud'hommeaux <eric@w3.org>
> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:11 UTC