- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Mon, 4 Oct 2010 20:14:56 -0400
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: Richard Newman <rnewman@twinql.com>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
* 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