Re: HTTP Status Codes for QueryRequestRefused

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