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

Glen Daniels wrote:
> 
> Hi Roberto, all:
> 
> 
>>etc. - those will be the purview of the document  > 
>>specifying each feature (most likely in English or Sinhalese).
>>
>>Certainly not. I'd be fine with replacing an explicit way of 
>>defining headers with an implicit one (F&P) as long as it's 
>>clear that all reasonable uses of explicit abstract headers 
>>are covered. In other words, I'd like to see evidence that 
>>the kind of headers that people would declare today using 
>>@headers are good candidates for being abstracted into a 
>>feature, possibly parameterized by one or more properties (if 
>>I understood Glen's writeup).
> 
> 
> Correct.  Essentially, the only kinds of headers that are worth specifying
> with the mechanism that exists today are the "cookie-esque" ones - i.e.
> "please send me the value 'xq57jb' back in the header 'myns:SeekritCode'.
> Oh, and send it on every single message, too."  Anything with more complex
> semantics than that can't really be accommodated with the current syntax.
> So I think it's a pretty simple matter to define a "sideband data" SOAP
> module which simply takes a property consisting of a set of elements, and
> inserts them as SOAP headers.

My head is spinning dangerously fast right now. Can you write down an
example? I don't quite see how you'd translate the declaration of a
header ns1:bar of type ns2:Foo into propertiese (or featurese, the
language). In a SOAP-independent way, if possible.

>>I know today what burden is placed on the WSDL author who 
>>decides to add an abstract header to an operation. I can 
>>surmise that replacing it with a feature would be n times 
>>more work. Perhaps this factor of n doesn't matter because 
>>features are the right way to solve this problem and @headers 
>>are just a hack, but I'd like to see some proof of it.
> 
> 
> There are two ways of thinking about the current way of dealing with
> headers.  First, I can describe a given header QName and leave the value up
> to the user - in this case, I am trusting the code or the user to understand
> what the appropriate value is to stick in there, which is exactly the same
> thing as asking them to understand a feature/property/policy identifier (the
> semantics are external).  Aside from the fact that this is a really bad way
> to do things (you can't easily specify extensions for which certain headers
> may or may not appear depending on context, for instance), the work involved
> is the same as in the F&P case.

Not quite. I can describe a header qname and type and leave the
semantics up to the user. This is exactly how operations are dealt with
-- cheaply and effectively. Do you want to have more semantics in the
WSDL itself? Use RDF or your favorite formalisms and sprinkle it on
the document as extensions. I'm worried by F&Ps requiring users to
provide specifications for a feature, its properties and their
binding-specific realization(s) to do the equivalent of @headers.
It sounds like an awful lot of work.

> Second, I can describe a particular value for a given header, as in the
> "cookie-esque" description above.  There is arguably some use in this sort
> of thing (dispatch, for instance?), and as noted we could define a normative
> "sideband data" module to handle this.  It would need to be very clear in
> the spec for the module that you can use it to send/receive arbitrary
> headers, and it's up to the user to make sure that the receivers are capable
> of correctly understanding those headers.

OK, so it can be done. But is it desirable? I mean, it would make for a
very odd feature! It almost makes F&Ps sounds like another extensibility
mechanism parallel to the built-in one (the extensible content model,
that is).

>>BTW, I'd be interested in furthering the policy discussion a 
>>bit. In particular, your argument about @headers being 
>>useless without a policy would seem to extend to features and 
>>properties as well. Would you then argue for removing F&P on 
>>the same grounds?
> 
> 
> Not to speak for Sanjiva here, but I would say this doesn't make sense.  F&P
> is a way of expressing policies, as well as controlling their realizations
> in on-the-wire messages.  The @headers syntax is simply a way to
> mechanically control the structure of a SOAP message in a very blunt
> fashion, which is why it's confusing and not as generally useful.

Now it really sounds like F&P is a sort of policy framework scoped to a
single operation only, as opposed to the whole service or even groups of
interacting services. I guess I'm either on a path to understanding or
hopelessly confused...  ;-)

Thanks,
Roberto

Received on Monday, 27 October 2003 19:42:49 UTC