Re: Status of comment RC-2

Algebraix Data has a unique perspective on this (RC-2) , as a newcomer to RDF and SPARQL.  We started a new implementation of SPARQL in mid December 2011.  We appreciate the precision and clarity of the specification and the hard work and dedication that has gone into it.  However, when we encounter areas of the specification that are not normative, we have to expend a lot of effort to determine how best to proceed.    For example, we first  determine if there are de-facto standards or whether there exists some commonality among  implementations of SPARQL.  Of course we always check WWAD (What Would Andy Do) :)

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

Best regards

Arthur


On Sep 25, 2012, at 6:32 AM, Steve Harris <steve.harris@garlik.com<mailto:steve.harris@garlik.com>>
 wrote:

On 2012-09-25, at 11:46, Andy Seaborne wrote:

On 25/09/12 11:28, Steve Harris wrote:
On 2012-09-25, at 09:45, Andy Seaborne wrote:
....

I think making a change to adapt to one, or a very few, toolkits
(which might change anyway) is a bad principle.  It is not "many
cases".  HTTP has a mechanism; inventing another at the last minute
another to duplicate the functionality of HTTP is a bad idea.

Reading http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html doesn't
seem to encourage custom status lines to me. It says you MAY replace
"reason phrases" by local equivalents.

or discourage :-)

When we return error message their often quite verbose, and not
appropriate to fit in a status line. The longest recommended reason
phrase is 4 words long.

Agreed.

SPARQL 1.0 protocol didn't say anything about this.

So it is not clear to me that making the change does in fact help
at all.  I do know it makes server side harder (servlets).

HTML errors message are the default setup for Apache httpd, tomcat
and many other servers.  If we are not fixing the text, then the
text is for display and text/plain is not a good choice
(internationalisation issues for example).  Conneg applies.

FWIW, 4store returns text/plain; charset=UTF-8. I think we used to
return SPARQL Results XML, but consensus seemed to be around
text/plain.

The best course of action is to submit a patch to the toolkit(s)
that does not expose the HTTP status line so that they do - that
will benefit lots of people.

I don't agree that packing error messages into the status line is a
good idea. Seems like an abuse of the protocol to me.

I'm also surprised if most toolkits allow you to change the status
text.

All the ones I have used do but, yes, the text is not really of much weight.

But that's not the proposal as I understand it.

OK, I think I got the wrong end of the stick.

My understanding is that the proposal is to normatively describe a
mechanism for passing back error messages.

It is not clear what for - as there is no definition of the error
messages its not for a programme to parse out (a json structure would be
easier anyway!) so I can only assume it's for display.  Existing servers (aside from specialied SPARQL endgines :-) send HTML by default.

I think at this point display is all we can expect.

So I don't see a proposal on the table at this point other than a vague "send text/plain in the body".  I think that is more harm than good to give it any weight.

Something informative, suggesting that people return text/plain (or whatever is the consensus) seems beneficial, I'm not sure about anything normative.

And it mildly conflicts with SPARQL 1.0.

Yeah, but so does common practice (as I understand it). Totally ignoring the fact that common practice is mildly different from what's written in SPARQL 1.0 doesn't seem ideal either.

- Steve

--
Steve Harris, CTO
Garlik, a part of Experian
+44 7854 417 874  http://www.garlik.com/
Registered in England and Wales 653331 VAT # 887 1335 93
80 Victoria Street, London, SW1E 5JL



[cid:9A30A3A1-8A64-4C3B-A44A-D6B4A4E1EE52@adc.local]
Arthur Keen, PhD.
Vice President of Products and Strategy
9601 Amberglen Blvd, Suite 119, Austin, TX 78729
OFFICE: 512.651.5834 x1126
MOBILE: 512.433.9537 | Fax: 512.651.5844