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

Sanjiva Weerawarana wrote:
 > "Roberto Chinnici" <Roberto.Chinnici@Sun.COM> writes:
 >
 >>I'm in favor of this proposal, but I think it should be conditional
 >>on features/properties being fully clarified and understood.
 >
 >
 > I understand this concern, but I think they're orthogonal. Even
 > when we do clarify F&P, I don't expect we will define language
 > syntax to talk about when headers will be added, who owns them,
 > who shares them 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).

 >>Till then, I'd prefer to keep @headers in, so that we don't risk
 >>ending up with a net loss of functionality.
 >
 > Per above, my proposal is that we do lose this functionality
 > as a language feature of WSDL. Are you actually proposing that
 > the F&P clarification will create replacement language syntax
 > for this? If not these decisions can be decoupled.

I'm not proposing that and yet the decisions are not decoupled.

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.

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?

Roberto

-- 
Roberto Chinnici
Java Web Services
Sun Microsystems, Inc.
roberto.chinnici@sun.com

Received on Monday, 27 October 2003 13:02:56 UTC