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

Hi Jean-Jacques!

> I'm really talking about application data, not utility data. I see
> several scenarios of use. One is to use a processor's underlying (header
> block) streaming machinery, without having to implement this by hand
> with the body, for each application.

That sounds very dubious to me, since you'd be using knowledge of the
internals of the receiving processor's implementation to attempt to gain
something.  First, we certainly don't want to directly support anything like
that in WSDL, and second, if you know so much about the remote processor,
why not just switch to some proprietary binary protocol?

> Another is polymorphism and indexing. You get this for free at the
> header block level (depending on your SOAP processor).

Please expand on this one?  You can certainly get polymorphism with schema
types, but maybe that's not what you're talking about...

> Yet another is being able to restructure and distribute the
> service/ultimate receiver at run time (as compared to design time). For
> example, a SOAP message may contain a document to print. The document
> may need to be rasterized first. This is likely to be done by the
> ultimate receiver; but in some settings it may be rasterized instead by
> an intermediary. It will help if the document is targeted to a role that
> may be played by the ultimate receiver or an intermediary.

Nope, don't like this one either. :)  Just as a digsig intermediary may well
sign the body, a rasterizing intermediary might rasterize it.  Such an
intermediary MAY drop in a header which indicates that the rasterization was
done at such-and-such a node (and your account with was
charged $0.00003), but even that is sideband data which your actual
application (printing the document) doesn't strictly need.

So far I still don't see any reason to think of headers as part of the
actual "meat" of the application.  Got other examples?


Received on Friday, 31 October 2003 07:58:18 UTC