Re: SPARQL 1.1 Protocol: Format of fault messages

I don't really have time to contribute usefully to this conversation
but I'll add a couple of additional data points:

Returning a plain text response is incredibly useful for logging error
responses received by applications (for later inspection by humans!)

We're only talking about a single class of errors for this change yet
there are quite a few other HTTP errors that could be encountered by a
client, most of which aren't under the control of the sparql endpoint.
Gateways and intermediaries can introduce proxy errors or temporary
failures. The server may not be able to allocate enough resources to
do more than respond with 500 error. The server may be down for
maintenance. There may be authentication failure messages. The
suggestion in this thread is to introduce a format constraint on
basically one error response (400) yet the client still has to deal
with all the other error message formats. I think that is why most
vendors of http infrastructure generally converge on simple html or
plain text messages.

Finally, what error response should be given for construct/describe
queries (by a long long way the most popular queries we see at Talis).
I have several applications that don't have code to understand sparql
results format because they never issue that type of query, but they
definitely have an rdf parser to hand.



On Tue, Oct 5, 2010 at 1:14 AM, Eric Prud'hommeaux <eric@w3.org> wrote:
> * Richard Cyganiak <richard@cyganiak.de> [2010-10-04 21:17+0100]
>> Eric,
>>
>> On 4 Oct 2010, at 19:53, Eric Prud'hommeaux wrote:
>> >I've not seen any endpoints which don't have HTML interfaces.
>>
>> Then look again.
>
> Ahh, I meant that they have built-in HTML query interfaces, indicating
> that they cater to browsers, though your survey indicates that they
> don't go so far as to do that for error messages.
>
>
>> You could use a list of popular SPARQL Protocol implementations [1]
>> to check your claim. I just did the work for you.
>>
>> Many endpoints serve an HTML query form at the endpoint URL, but not
>> all (see Joseki, D2R, Sesame, RAP).
>>
>> Just a few (D2R, Joseki) serve error messages in HTML. They actually
>> only serve generic web server exception pages, so the use of HTML is
>> developer laziness rather than by design. These are the only
>> implementations I could find that return error messages in HTML. The
>> vast majority of implementations serve error messages in plain text
>> (Virtuoso, Talis Platform, Sesame, ARC2). 4store serves them in XML;
>> RAP fails with a 500 and no message body.
>>
>> Virtuoso is the only server implementation I'm aware of that
>> actually returns query results in HTML; all others default to XML
>> and some support JSON as well.
>>
>> Not a single implementation supports HTML for *all* aspects of the
>> protocol (result and failure).
>>
>> So I think it's more accurate to say that they all aim for machine
>> clients, but most implementors have expended some effort towards
>> making the testing, exploring and debugging of an endpoint possible
>> from a browser as well. None of them have been built with web
>> browsers as a primary client in mind.
>
> agreed.
>
>
>> I conclude that your call for XHTML as the error result format
>> addresses a need that you perceive, but that doesn't actually exist.
>
> Hmm, I'd argue that the fact that they've all made some efforts
> towards browser use indicates that the need does exist. While most
> haven't provided structured HTML errors, it was early on the list of
> things I implemented in SWObjects, and I expect others will want to
> do the same. I can pull it out of my implementation, but I'm not sure
> we want to rule out that sort of user-friendliness.
>
>
>> Hence, using a format that is more easily parsed, less verbose, and
>> more in line with the format for successful responses, while still
>> providing acceptable user experience when
>> testing/debugging/exploring with a browser, better serves both
>> client and server implementors.
>
> I think we agree on having an extensible model. You suggested
> text/plain or HTML with a new plain text header. I'm not sure
> how the plain text simplifies client implementations if they
> also have to code for HTML messages.
>
> What about including the header and the ID element, so clients
> can use which ever works for their pipeline?
> [[
> A malformedQueryFault response SHOULD be an XHTML document in which an
> element with an XML ID of <code>malformedQueryFault</code> conveys a
> human-readable representation of the error. The human-readable message
> SHOULD also be the value of a Malformed-Query-Fault HTTP header. For
> example:
>
>  HTTP/1.1 500 Bad Request
>  Content-Type: text/html
>  Content-Length: 363
>
>  <?xml version="1.0" encoding="UTF-8"?>
>  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml.dtd">
>  <html xmlns="http://www.w3.org/1999/xhtml">
>    <head>
>      <title>Malformed Query</title>
>    </head>
>    <body>
>      <h1>Malformed Query</h1>
>      <pre id="malformedQueryFault">Parse error at [5:17], unexpected ' '</pre>
>    </body>
>  </html>
>
> Other HTML elements in the response do not change the interpretation
> of the element with the XML ID of <code>malformedQueryFault</code>/
> ]]
>
> This makes it easy to implement the no-brainer client if you've got
> access to the headers, not too hard, given you already have an XML
> parser otherwise. Fancy responses can be gracefully handled by naive
> clients, and they can be exploited by fancy clients.
>
> Intuitively, it seems like the plain text is simpler, but given an
> extensibility path that requires also handling HTML, I don't see it
> saving implementation effort. The header addresses this, but only if
> we write off extensibility in environments where the clients don't
> have header access.
>
> Steve's suggestion of extending the XML Results Format would address
> extensibility if we gave them an ANY element where they could stick
> extensions. They'd then be able to include e.g.
>  <?xml-stylesheet type="text/xsl" href="myErrorToHTML.xsl"?>
> to pleasantly render all of their extended data (or maybe some AJAX
> app which randomly changes characters until the syntax works). That
> nicely puts the burden on the browser use case, which is already
> well-accustomed to computational burden.
>
>
>> Best,
>> Richard
>>
>> [1] http://lists.w3.org/Archives/Public/public-lod/2010Oct/0001.html
>
> --
> -ericP
>
>

Received on Tuesday, 5 October 2010 01:20:18 UTC