Re: SPARQL 1.1 Protocol: Format of fault messages

Eric,

Your logic is bizarre. I surveyed 141 SPARQL endpoints with at least  
eight different server implementations. There is only one  
implementation out there that serves responses in HTML. Not a single  
implementation does any attempt at structured errors. Not a single of  
the implementations that come with HTML query forms also does HTML  
error messages. All but three of the implementations report errors in  
text/plain. I started this thread because I want better machine- 
readable error messages. Everyone who spoke up in this thread except  
you wants either machine-readable error messages, or wants to make  
sure that the mechanism is kept really simple, or wants it to be kept  
close to the protocol. The SPARQL protocol result format has no  
extension mechanism. But from all this evidence, you somehow conclude  
that what the world needs is some bloated, overcomplicated mechanism  
that solves a non-problem and serves an audience that is already  
served sufficiently well by the status quo.

Forget about it. I'll go talk to Andy Seaborne, Steve Harris and  
myself to get the out-of-line implementations to serve text/plain as  
well, and code my clients against that. Leave the spec as it is.

Best,
Richard


On 5 Oct 2010, at 01:14, 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 08:16:20 UTC