RE: Issue i009 - Multiple actions. Proposal

Hey Gudge,

> 
> I had an action to make a proposal for closing issue i009 - Multiple
> actions. The general feeling in the room at the face-to-face seemed to
> be that sticking with one action (possibly per actor/role depending on
> how we close issue i007) was fine, but we needed to call this out in
the
> spec and point out that layered specifications need to take this into
> account. Here is the proposal:
> 
> Add the following sentence to the description of the [action] property
> in section 3 of the core spec.
> 
> 	Protocol and application designers building on this
> specification are encouraged to take care when designing their
protocols
> or 	applications that they do not violate the requirement that there
> be exactly one [action] property.
> 
> Flames, comments, suggestions to the usual address.
> 

I think the above may be confusing. Someone may take (perhaps it's just
me) the above to mean that if a new message-based protocol shouldn't use
wsa:action just in case another protocol, with which the new protocol
has to be composable, may use it. That means that ALL protocols should
not use wsa:action. If there was a wsa:action per actor/role then that
wouldn't be a problem. Unless wsa:action is meant to be consumed only by
the ultimateReceiver?

Also, while reading the semantics of wsa:action in the latest published
version of the spec, I noticed that it is RECOMMENDED that the value of
wsa:action be related to WSDL constructs. Why does the spec must provide
this recommendation? If wsa:action has clear semantics, there shouldn't
be a need to do that. I think it should be the other way around. The
WSDL spec should say that the value for its constructs become values for
wsa:action. What if there was another WS description language in the
block? (I just happen to know that a proposal for one is coming :-)
 
Regards,
.savas.

Received on Thursday, 20 January 2005 11:01:31 UTC