- From: Richard Newman <rnewman@twinql.com>
- Date: Mon, 4 Oct 2010 12:34:35 -0700
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: Richard Cyganiak <richard@cyganiak.de>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@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. Regards, -R
Received on Monday, 4 October 2010 19:35:09 UTC