Re: SPARQL 1.1 Protocol: Format of fault messages

* 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 00:15:32 UTC