- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Fri, 6 Jan 2006 13:08:05 -0500
- To: andy.seaborne@hp.com
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Jan 6, 2006, at 12:33 PM, Seaborne, Andy wrote: > I checked with WSDL CR: > http://www.w3.org/TR/wsdl20/#meaning > > """ > A WSDL 2.0 service description indicates how potential clients are > intended to interact with the described service. > """ > so other interactions (and I would include other sattus codes > because status cdoes are visible as WSDL faults) that are not in > the service description are not intended. Nope. I completely disagree. "Intended to interact" does not mean or imply "no other thing may happen than what is explicitly described in WSDL". And that's what yr reading needs it to mean. Yr quotation cuts off the crucial bit, the next sentence: "It represents an assertion that the described service fully implements and conforms to what the WSDL 2.0 document describes." Which says *nothing* about what the WSDL 2.0 does *not* describe. Hence, if WSDL 2.0 doesn't claim to be complete, final, and explicit, then it isn't. Underlying semantics apply. Hence, other HTTP status codes may be returned. > I can see two differences here: > > 1/ Date: etc are not visible to the client executing a SPARQL > request as per the WSDL description. Here I agree with you that > not mentioned can mean it's open. What do you mean "not visible"? They're as visible as any other bit on-the-wire, which is what you say matters below. > 2/ Faults are in the WSDL description so 1 does not apply. Yes, these two faults are. But that doesn't constrain the use of HTTP status codes for *HTTP* layer problems, rather than for WSDL faults that don't exist. Here's my position: 1. Having a WSDL for a service doesn't constrain the HTTP layer in any other way. It simply cannot do so. 2. The only thing WSDL can say or describe (and thus "constrain" if a service conforms to WSDL) is (relevantly) WSDL *faults*, which in HTTP are serialized as HTTP status codes (and in other ways, I think, but that's not relevant here). So, if these status codes yr worried about people thinking they can't use are WSDL faults, let's make them WSDL faults and choose HTTP status codes to serialize them. Otherwise they are merely HTTP status codes, in the HTTP layer, and WSDL doesn't say anything about them, and thus doesn't abjure them. If you want a statement to that effect in the document, I drafted one in my previous message. You reject it because you think it contradicts "intended interaction". But it doesn't. (The contrast to "intended" of course is "unintended", that is, something that the WSDL is simply silent about. Which is precisely my point.) How about this syntatic variant: > "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." "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. All other semantics, including status codes and headers, of HTTP and SOAP are available and in effect, except for the explicitly stated concrete protocol bindings for HTTP and SOAP in SPARQL Protocol's normative WSDL 2.0 description." > The description says "this rec intends that you use status codes > 400 and 500". Well, it says there are two WSDL faults, Foo and Bar. And *for the HTTP binding*, those faults are serialized with HTTP status codes 400 and 500. > > That text does not work for me because it is about implementation > and status codes aren't implementation - they are on-the-wire > protocol. It's a starting point though. Everything on the wire is implementation! :> > That is better although it seems to read agains the meaning of a > WSDL description as being the intended interaction. How so? "Intended interaction" for the service. Which sits on top of some concrete protocol. The rules of which apply, unless the WSDL explicitly says otherwise. *That's* the issue separating us, I believe. The rest of this is distraction. > What I'd like is to see that distinction between the SPARQL > protocol and the underlying protocol to be drawn out. But yr trying to collapse the distinction by insisting that WSDL prohibits any HTTP bits that aren't explicitly described. In my view that totally obliterates the distinction between abstract and concrete protocols. The idea that the two should be layered and loosely coupled proves my point that higher, more abstract layers don't blanketly constrain lower layers per se. > It is this lack of layering that I see as leading to alternative > readings as to what it applies to. Because the WSDL #meaning is > the "intended interaction" and SPARQL defined some faults, those > become the intended ones. Yes. But for this to be a convincing reading, you still need one more premise which I don't believe you have, can have, and is the whole crux of the issue, namely: "And no underlying protocol semantics are applicable except the ones that the WSDL describes abstractly and then binds concretely." And that's *not* the meaning of "intended interaction". Cheers, Kendall
Received on Friday, 6 January 2006 18:08:10 UTC