- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Sun, 3 Oct 2010 12:03:41 -0400
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: public-rdf-dawg-comments@w3.org
* Richard Cyganiak <richard@cyganiak.de> [2010-10-03 16:31+0100] > > On 1 Oct 2010, at 21:24, Eric Prud'hommeaux wrote: > >>1. To state in the HTTP binding that clients SHOULD use the XML > >>fault message format when reporting faults. > > > >It may be polite to still have two, one for SOAP interfaces, which > >have some standard tooling and contracts, etc. > > I'm just concerned about the HTTP bindings. I don't really see the > SOAP bindings used out there in the wild; my clients certainly don't > support them, and I had no user requests for SOAP support. I read that as you're OK with the SOAP binding specifying a SOAP fault which is different from the HTTP bindings, so <malformed-query/> stays as is. > >I expect your principle > >issue is with the free-form beat poetry style of the rest bindings. > > My issue is with two things: > > 1. The current spec says: “Use this HTTP status code, everything > else is up to you.” > > It should say: “You SHOULD report the error message this way.” > > 2. The current spec has an example that shows the error message > embedded in HTML in a way that it can't be gotten out by a client. > > It should not use such an example. > > >We'd kind of like to leave room for implementors to innovate > > Saying that you SHOULD use a certain format leaves enough wiggle > room for implementors to innovate, IMO. Sure, but we'd also like to encourage a backwards-compatible extensibility model which allows me to have a great new idea without breaking all the old code which e.g. reports errors to humans. > I think the spec should really communicate one no-brainer way of > implementing error reporting, for anyone who really just wants to be > conformant without any desire to do fancy innovative stuff. I really > want that format to be machine-readable; beyond that I really don't > care much. > > I have no objection against also proposing alternative response > formats, as long as one option is clearly highlighted as the “no- > brainer” option. And I'm interested in making sure that the alternatives subsume the no-brainer in a way that the no-brainer parser can use. > >and reply with > >our baseline error response plus some structured stuff to say what > >line and character caused what sort of error. > > I'm all for reporting line and column in a structured format if > possible, but that would be the cherry on the cake. > > I'd be sufficiently happy with just the cake. +1, I wanted to illustrate to you how the no-brainer could grow. > >We'd also like that to > >show up in browsers. What if we say that it must appear in a pre with > >a particular class? > > > ><?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>D'oh!</title> > > </head> > > <body> > > <pre class="malformedQueryFault" style="display:none">Parse > >error at [5:17], unexpected ' '</pre> > > Why would you make it display:none? If you use HTML already, then at > least make the error message show up in the browser! Oops, I meant that to be display:none only in the more structured extensions. > And RDFa would be better than a magic class name. I'm afraid of demanding a generic RDFa parser for consumers of error messages. (Of course, I'm happy to see that practice flourish on its own.) Class was a poor choice, how about ID? New proposal: [[ 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. For example: <?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>/ ]] > Best, > Richard -- -ericP
Received on Sunday, 3 October 2010 16:04:17 UTC