- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Sun, 3 Oct 2010 19:36:45 +0100
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: public-rdf-dawg-comments@w3.org
On 3 Oct 2010, at 17:03, Eric Prud'hommeaux wrote: > 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 don't know what a SOAP fault is. I'm just concerned with the HTTP bindings. >> 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 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. Fair points. >> And RDFa would be better than a magic class name. > > I'm afraid of demanding a generic RDFa parser for consumers of error > messages. I see your point. But I'm afraid of even demanding an XHTML parser. In reality, too much XHTML ends up as tag soup. How about this: [[ A malformedQueryFault response SHOULD be a text/plain document containing a human-readable representation of the error. For example: HTTP/1.1 400 Bad Request Content-Type: text/plain Content-Length: 37 Parse error at [5:17], unexpected ' ' Conformant implementations MAY convey the error message using other formats than text/plain. If they do so, or include more content besides the one-line error message in a text/plain response, then they MUST include a one-line human-readable representation of the error as an X-Malformed-Query-Fault HTTP header: HTTP/1.1 400 Bad Request Content-Type: application/xhtml+xml X-Malformed-Query-Fault: Parse error at [5:17], unexpected ' ' <?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> ]] Advantages: 1. Anyone can still do anything, as long as they include one HTTP header 2. Machine-readability is *always* given 3. Backwards compatible: If a client checks for presence of the header, and if absent checks for a text/plain body, then it will always get the message. Best, Richard > (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 18:37:20 UTC