RE: PROPOSAL: Drop interface/operation/(input|output)/@headers

[ Tom's keyboard writing checks his body can't cash elided... :) ]

> The syntax for declaring a property that is a header, after 
> declaring that you are using the feature that *is* headers, 
> is NOT simple.

We could easily build in to WSDL a simple syntax for using the "cookie"
module/feature I described, although I don't think the property approach is
really that awful.  I'm not against syntactic shortcuts.  I AM, as I
realized in the last message, against the idea of allowing WSDLs to
arbitrarily specify headers.  I would have no problem with introducing a
well-known "cookie" header, inside which we could throw whatever you wanted
to put in the WSDL as "state" to carry with messages.  I object to the idea
that headers should be "opaquely" inserted, for instance by clients who have
no idea what the semantics implied by the given QNames are other than "just
put it in, trust me".

> As to whether the headers belong in the abstract interface to 
> my server or not, I don't think that we should waste time 
> talking too much about that.  Yes, I will need to know what 
> the headers are for, or more specifically what *values* to 
> put in the headers.  BUT THAT IS OK.  I don't think I need a 
> feature spec if I want to require an identity key for my web service.

I have no problem with the idea of reflecting state information, for
whatever purpose, back to a service based on a WSDL.  That's a perfect
candidate for a simple SOAP extension, which I think we could easily define
and bake into WSDL, with syntactic sugar, even.

If you, the user, are actually putting particular values into headers, and
you expect to "know" what the semantically appropriate values are, you
should NOT be using the "headers" syntax, or anything like it.  You should
be using a syntax which says "use this SOAP module".  Why?  Because the
"headers" syntax is completely inadequate for any but the most basic (always
send this particular header) extensions, whereas the module syntax allows
for anything that the spec defines.

--Glen

Received on Tuesday, 28 October 2003 16:33:43 UTC