W3C home > Mailing lists > Public > www-ws-desc@w3.org > November 2006

cr82: [Fwd: RE: Header blocks in wrpc:signature]

From: Jacek Kopecky <jacek.kopecky@deri.org>
Date: Thu, 30 Nov 2006 17:56:17 +0100
To: WS-Description WG <www-ws-desc@w3.org>
Message-Id: <1164905777.12027.62.camel@localhost>

Hi all, 

this email below is a reply to our response regarding issue 82,
apparently it never got to the list.

My initial (after short thought after a long time of not seeing this)
response would be that what he wants would not help interoperability;
and Jason says he won't really object if this is deferred to the next
update of the spec, seeing where we are in the process.


-------- Forwarded Message --------
From: Jason T. Greene <jason.greene@jboss.com>
To: Jacek Kopecky <jacek.kopecky@deri.org>
Cc: WS-Description WG <www-ws-desc@w3.org>
Subject: RE: Header blocks in wrpc:signature
Date: Thu, 26 Oct 2006 16:37:59 -0500

> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek.kopecky@deri.org]
> Sent: Thursday, October 26, 2006 10:48 AM
> To: Jason T. Greene
> Cc: WS-Description WG
> Subject: Re: Header blocks in wrpc:signature
> Dear Jason,
> you raised an issue CR082, with the latest email at
> You suggest that wrpc:signature should be able to include SOAP headers
> as it is practice supported by a number of SOAP toolkits.

Thank you for considering my input.

> 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.

Sometimes the information is considered part of the abstract contract,
although it's not included in the main message body because of
performance or urgency. For example, it's more efficient to put an
authentication token on a header because an intermediary device can
process it without inspecting the entire message. So really this
body/header separation is largely a binding concern.

I would agree with you, however, that there are use cases where a header
is completely transport specific, and has no mapping to the contract at
all. This was, as you know, usually hacked into WSDL 1.1 using separate

> 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
> extends the interface operation with the header (out-of-band data).

I see your point and to be honest the signature is really just a
convenience factor. Although, I do think there is benefit to having
standardized hints for this type of information. The main use case I see
is a service provider that supports multiple programming language
clients. Several languages are similar enough that interpretation of
this hint would lead to an API that was almost identical between the
various languages and toolkits.

In order to be consistent with the binding mechanism in WSDL 2.0, it
would make the most sense to allow the binding to override the
signature. However, it also seems to me that it would be far simpler,
and practical to just add a {#binding qname} token set to the
description. It would then be up to the binding implementation as to how
to map it. It could even be ignored, and the message order is still

> 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
> SOAP binding does not have this functionality of splitting the
> So I'd like to clarify with you what exactly you'd like:
> 1) extending wrpc:signature with parameters that are not declared on
> interface level, but which can be expected to be filled in by
> 2) or adding support to the WSDL 2.0 SOAP binding to allow
> 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
> adding such a feature.

I am proposing the former. I did consider (2), although I do not think
it is worth sacrificing a schema valid message. The only negative side
effect that I see in (1) is that it could potentially conflict with a
future override mechanism, should it be needed. 

I understand that my critique / suggestion is bad timing with the spec,
and I should have gotten involved earlier. So I fully understand if this
discussion is delayed for a future update of the specification.

Received on Thursday, 30 November 2006 16:56:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:07:03 UTC