- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Thu, 27 Sep 2012 08:07:45 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- CC: public-rdf-dawg@w3.org
On 9/27/2012 7:40 AM, Andy Seaborne wrote: > > > On 26/09/12 01:13, Arthur Keen wrote: >> Having a standard way to report errors makes sense in general and would >> help newcomers (like Algebraix) in the market, by increasing >> interoperability with existing client libraries and applications. >> However we agree that it would be risky to add it to the spec right at >> the end of the process and we do not wish to hold up the >> standardization process for SPARQL 1.1, however we ask that error >> messages be considered in subsequent standardization activity beyond >> SPARQL 1.1 > > The issue I see is that SPARQL exists in a wider context of standards > and code. > > HTTP is widely (!) deployed and well understood. Many client-side > toolkits exist to work with it. > > Reuse is good. Adding additional mechanisms is good to make the system > better for one purpose (SPARQLing) but comes with a cost of making > general web frameworks toolkits less suitable for app building and > adds to web developer overload. This cost is something we all (self > included) tend to underplay when we are in the midst of a technical > design. > I don't think this particular use case is well-understood in HTTP, is it? Is there a standard understanding for how to report (detailed) errors over HTTP with respect to media types? Lee > Andy > >
Received on Thursday, 27 September 2012 12:08:16 UTC