- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Sun, 3 Oct 2010 21:40:44 +0100
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: public-rdf-dawg-comments@w3.org
Eric, If you write in the spec that they should serve XHTML, then they will serve you tag soup. This is not a realistic option. Richard On 3 Oct 2010, at 21:08, Eric Prud'hommeaux wrote: > * Richard Cyganiak <richard@cyganiak.de> [2010-10-03 19:36+0100] >> 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. > > I think the XML parser they use for the SPARQL Results will be fine. > If they were using DOM to parse, they can getElementById; if they're > using SAX, they can: > > public void startElement(String namespaceURI, String localName, > String qName, Attributes atts) throws > SAXException { > userMessage = false; > for (int att = 0; att < atts.getLength(); att++) { > if (atts.getLocalName(att) == "id" && > atts.getValue(att) == "malformedQueryFault") { > userMessage = true; > } > } > } > > public void characters(char[] ch, int start, int length) throws > SAXException { > if (userMessage) > ... > > Either way, I think that the additional client code required to get > the user message is between 1 and 10 lines. For user code, they > already have some way to entity-encode text so it's basically > print(template.top + entityEncode(errorMessage) + template.bottom); > > >> 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 > > +1 to inlcuding the header in the example. We can just use text/html > and every browser on the planet will handle it. > > >> X-Malformed-Query-Fault: Parse error at [5:17], unexpected ' ' > > Interesting, I could see doing this if the client's error-parsing > burden were higher, but I've pretty much convinced myself (above) > that it's easy (especially compared to getting at headers when I'm > running as a CGI, servlet, webkit client, etc.). > > >> <?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 > > but via heuristics; I have to have two handlers. > > >> 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. > > My first interpretation was that you should give plain text, but if > you weren't content with that, maybe something like this HTML here... > I now understand that this is to encourage exactly one of these two > alternatives. > > While this does allow me to convey structured info while still giving > nice-to-read info to the primitive clients, I don't think that the > text/plain avoids much effort. The clients will still need to > implement both and the servers have a trivial amount of work to do to > implement the XHTML. I think the net work is lower, and the protocol > is simpler, if the only SHOULD is the XHTML alternative. > > > >> 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 >> > > -- > -ericP
Received on Sunday, 3 October 2010 20:47:54 UTC