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

It is very important that we do not confuse programming model with a
description of message-level interoperability.

If you need a hint about how to surface something in the programming
model, you should consider defining that as something that may be
ignored by endpoints that have their own, potentially-very different
idea of programming model.

--Jeff

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of paul.downey@bt.com
> Sent: Tuesday, October 28, 2003 2:26 AM
> To: gdaniels@sonicsoftware.com; Roberto.Chinnici@Sun.COM;
> sanjiva@watson.ibm.com
> Cc: www-ws-desc@w3.org
> Subject: RE: PROPOSAL: Drop
interface/operation/(input|output)/@headers
> 
> 
> Glen wote:
> > 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.
> 
> One problem we have with current tools is some generate application
code
> for headers defined in WSDL whist other ignore them altogether.
> 
> I think it would useful if a toolkit could *know* if a header was
intended
> for an application or for a lower-layer protocol ?
> 
> - could F&P be used to describe which /role/ a header is intended for
?
> - or maybe headers *and* F&P would provide this distinction ?
> - or am i barking ?
> 
> 
> --
> Paul Sumner Downey
> Web Services Integration
> BT Exact
>

Received on Tuesday, 28 October 2003 20:45:14 UTC