- From: David Wood <dwood@softwarememetics.com>
- Date: Wed, 4 Jan 2006 14:03:53 -0500
- To: Kendall Clark <kendall@monkeyfist.com>
- Cc: Dan Connolly <connolly@w3.org>, public-rdf-dawg-comments@w3.org
- Message-Id: <A8C378E3-9381-4ECC-809F-BA5A1E7F8D0C@softwarememetics.com>
On 4 Jan2006, at 12:39, Kendall Clark wrote: > d about some of off-line, but I owe you a public response. All of > the following changes can be found in the latest editor's draft: > > $Revision: 1.83 $ of $Date: 2006/01/04 17:38:08 $ > http://www.w3.org/2001/sw/DataAccess/proto-wd/ Thanks for the response. Happy new year to all. >> OMISSION: In the "Malformed Query" paragraph of Section 2.1.4, >> it is unclear what behavior is expected from a query processing >> service if a malformed query does not result in a MalformedQuery >> fault. One way to solve this is to make such a fault mandatory >> ("must" instead of "should"). If that is not done, the document >> should say what kind of behavior to expect (is a >> QueryRequestRefused OK? How about returning nothing?). > > The WG explicitly decided to make MalformedQuery optional. I'm not > clear why you think the document must say what must happen in the > case where the spec says an implementation may do something or may > not. Can you say more about this? Well, an implementor will have to make exactly that decision. Either they will choose to implement MalformedQuery or they won't. If they don't, then what should they do? Return nothing? Drop the connection? QueryRequestRefused? As an implementor, I'd be looking first to the spec for guidance. Failing to find any, I'd do what I thought best - which is another way of saying that I'd make a different decision to someone else and hence potentially cause an interoperability problem. >> SUGGESTION: Section 3.0, "Policy Considerations", states that >> query services MAY refuse to process certain query requests. In >> that case, I suggest making it clear that they MUST do so as >> defined in Section 2.1.4. > > Hmm. Section 3.0 says that some queries, because of various policy > considerations, can be simply not processed by services. So, a > query asks a service to retrieve a 1GB KB over the Web, and the > service is under heavy load, then that service can simply refused > to process that request. Section 2.1.4 tells implementers how, > having made that decision, it is to be carried out: namely, by > returning QueryRequestRefused. > > So, there's two parts: > > 1. a service *may* refuse to process a request > 2. if it so chooses, then it *must* return QueryRequestRefused Yes, we are saying the same thing. I was suggesting, however, that the language in Section 3.0 (under Security) explicitly point a reader to Section 2.1.4 to ease compliance. >> QUESTION: Was the Content-Type of the example query intended to >> be "application/x-www-form-urlencoded"? > > Which example? Err. Umm... I couldn't find it after a quick look :( I do note where the doc says: "The HTTP binding for the query operation contains two parts. The first uses [HTTP] GET with application/x-www-form-urlencoded serialization and UTF-8 encoding. The second uses [HTTP] POST with application/x-www-form-urlencoded serialization and UTF-8 encoding. The GET binding should be used except in cases where the URL-encoded query exceeds practicable limits, in which case the POST binding should be used." So I guess that's OK. If it were me, I would probably add Content- Type headers in /all/ the examples to be clear (in Section 2.2.1). Regards, Dave
Received on Wednesday, 4 January 2006 19:03:59 UTC