Re: Status of comment RC-2

On 2012-09-25, at 13:20, Andy Seaborne wrote:
> On 25/09/12 12:32, Steve Harris wrote:
>>>> 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.
> 
> It is?  In what way?

I don't think I've ever seen an implementation of http://www.w3.org/TR/rdf-sparql-protocol/#fault-messages

> Sending plain text has it's own issues.  I had one report that Fuseki was generating internal errors because the user saw plain text and assumed it was the internal system throwing up an internal fault in unsubtle way.  In fact, it was a parse in their query.

I don't think that's the fault of the result format… sounds like a client bug to me.

To be clear, I don't really care whether we use SPARQL XML, HTML, or plain text, but some sort of commonality is good so that people have a hope in hell of writing SPARQL clients that work with more than one system. text/plain seems to be the closest thing we have to consensus at the moment, though I've not done a survey.

Conneg is a little fraught because the client (probably) isn't expecting an error, if you ask for
   application/sparql-results+xml, text/turtle, text/json, text/plain
It's rather hard for the server to interpret that w.r.t errors. Should it try to squeeze the error into SPARQL XML (which is what 4store used to do by default IIRC), or JSON, or what?

- 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

Received on Tuesday, 25 September 2012 12:34:38 UTC