- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Fri, 6 Jan 2006 12:04:15 -0500
- To: andy.seaborne@hp.com
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Jan 6, 2006, at 10:45 AM, Seaborne, Andy wrote: > Your reasons are that the document does not say anything about > other HTTP codes. My reason is that silence is equivalent to permissibility. Or, put another way, I don't agree that a WSDL description proscribes anything, least of all every possible, legal HTTP status code or, say, header. I've never heard anyone say that about WSDL. I've heard people say the opposite, which is the reason it's called WS*D*L instead of WS*P*L. > My reading is that the document does talk about them by exclusion > because it says: > > """ > QueryRequestRefused > > This fault message must be returned when a client submits a request > that the server is unable or unwilling to process, perhaps because > of resource consumption or other policy considerations. > """ > > The "must be returned" means that for any condition (other that > MalformedQuery) QueryRequestRefused is to be used, restricting the > use of HTTP conditions such as "403 - Forbidden". I don't agree... "is to be used *when the server is unable or unwilling to process the request"... I think, however, I will drop the "unable or" bit. QueryRequestRefused is supposed to be used for queries that the service refuses to answer, as opposed to ones it cannot answer (because, say, they are illegal). The doc explicitly says that there is no implication in QueryRequestRefused that subsequent invocations of the same operation will also be refused. It's not supposed to be the catchall fault to be used in every other case except malformedness. If the document says that, I believe that's a bug. (I don't believe the document says that, but this confusion suggests it's not clear enough.) > Server errors like the front-end generated 502 also fall into > that category. > > if a SPARQL Protocol service supports HTTP bindings, it must > support the bindings as described in sparql-protocol-query.wsdl. > """ > so that depends on whether the WSDL is prescriptive as to the range > of faults that that interface can return. My understanding is the > WSDL is a complete description of the interface. It's not a complete description in the sense of being prescriptive. How could it be? We're mostly (ignoring SOAP for a minute) using WSDL to describe some HTTP URIs and some subset of messages that software processes that are somehow connected to those URIs will consume or produce. But unless otherwise stated, the underlying semantics of any binding still apply. That includes, in the HTTP case, other HTTP status codes and headers and so on. Consider an example. I have a service "fully described" (whatever that means -- here, yr using it as a synonym of "prescribed") by WSDL with HTTP bindings. Upon receiving a legal In Message, the service returns a legal Out Message, but it includes headers like this: Date: Fri, 06 May 2005 20:55:11 GMT Server: Apache/1.3.29 (Unix) Connection: close Under yr view, I should be able to find in the "fully described" WSDL for this interface the place where it says that an Out Message must include a Date: and Server: header. But it's not there because WSDL doesn't fully prescribe all underlying HTTP semantics or bits or bobs. Which leads me to conclude that implementers can return 403 or 502 to their heart's content. Without us saying, in suitable spec- ese, "implementers can return 403 or 502 to their heart's content". (So, for example, as I understand SOAP, you can do all sorts of arbitrary, intermediate message routing between endpoints. And, while I don't believe anyone's really implemented all of that, I do not think WSDL forbids any of that by not explicitly saying, in a "full description", that it may happen. Of course it may! Why aren't we also making an explicit statement about all of that?) > You have mentioned that is not your reading of the document so > maybe just clarifying with some text will fine. The minimum change > that would clear this up might be to clarify it in the HTTP section > with something like: I prefer this: "A SPARQL Protocol service may employ the full range of HTTP status codes consistent with the usage of QueryRequestRefused and MalformedQuery as describe in section 2.1.4." But the reason I *don't* want to say this, ideally, is that it may suggest a wrong implication, namely, that in all *other* areas of HTTP semantics, except for status codes, the WSDL *does* constrain what implementers can do. WSDL is just a description of some messages, types, and how those are connected to HTTP things. But by singling this status code issue out, but not saying the equivalent thing across other parts of HTTP, the implication that status codes are special in this regard may be communicated. I'd prefer something like this: "Note that while this document uses WSDL 2.0 to describe SPARQL Protocol, there is no obligation on the part of any implementation to use any particular implementation strategy, including the use of any WSDL library or programming language framework." Which is already in the document. Maybe it can be broadened a bit to include the general issue you raise. Thus, "Note that while this document uses WSDL 2.0 to describe SPARQL Protocol, there is no obligation on the part of any implementation to use any particular implementation strategy, including the use of any WSDL library or programming language framework, nor is there any limitation on the usage or semantics of the concrete protocols -- HTTP and SOAP -- for which bindings are given, other than the explicit descriptions of behavior given in the bindings themselves." That covers status codes and everything else in SOAP or HTTP. Cheers, Kendall
Received on Friday, 6 January 2006 17:04:22 UTC