Re: Header blocks in wrpc:signature

Dear Jason,

you raised an issue CR082, with the latest email at
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2006Oct/0037

You suggest that wrpc:signature should be able to include SOAP headers
as it is practice supported by a number of SOAP toolkits.

We position the interface-level (as opposed to binding-level) RPC
signature extension as a way to help deal with WSDL interfaces in
toolkits that generate client stubs. The intended use is that a WSDL
interface (operation) is generated from a procedure, and the
wrpc:signature is there to make it easier for software to reconstruct
the signature or that procedure. By definition of out-of-band,
procedures don't contain (even formalized) out-of-band data as
parameters, so our wrpc:signature shouldn't contain it either.

Anyway, the wrpc:signature is really only a hint for the toolkit,
especially since we don't say how it is mapped to any concrete
programming language, so we do not expect interop on the level of the
procedures generated from wrpc:signature. This means that the toolkits
can easily continue to map SOAP headers to parameters, effectively
extending the signature from wrpc:signature, just like the WSDL binding
extends the interface operation with the header (out-of-band data).

I agree WSDL 2.0 loses functionality here, but it is the functionality
represented by WSDL 1.1 messages, which were dropped in favor of XML
Schema element declarations. From this point of view, the interface
operation will point to an element declaration and the binding is free
to put some parts of it in the body and some parts in headers. WSDL 2.0
SOAP binding does not have this functionality of splitting the message.

So I'd like to clarify with you what exactly you'd like: 
1) extending wrpc:signature with parameters that are not declared on the
interface level, but which can be expected to be filled in by bindings, 
2) or adding support to the WSDL 2.0 SOAP binding to allow wsoap:header
to cut out a part of the body into a header

Personally, I don't think option 1 would be useful for interop (the
intention of standardization), and option 2 would need justification for
adding such a feature.

Please let us know,

Jacek Kopecký

Received on Thursday, 26 October 2006 15:54:50 UTC