Re: Issue i017 - Purpose of the Action property -- my action item

Comments inlined.
-Anish
--

Jonathan Marsh wrote:
> Below.
> 
> 
>>-----Original Message-----
>>From: public-ws-addressing-request@w3.org [mailto:public-ws-
>>addressing-request@w3.org] On Behalf Of Anish Karmarkar
>>Sent: Sunday, December 19, 2004 9:59 PM
>>To: public-ws-addressing@w3.org
>>Subject: Issue i017 - Purpose of the Action property -- my action item
>>
>>
>>During the 2004-12-13 I took an AI to send an email out to the ML regd
>>issue i017.
>>Going through the archives of the mailing list I see that I had
>>already
>>sent an email regarding this (on nov 15th). It is located at [1].
>>
>>To recap that email:
>>
>>1) The [action] property is supposed to uniquely identify the
>>semantics
>>implied by the message. Since the value of this property is fixed by
>>the
>>WSDL description (either through the defaulting mechanism or through
>>the
>>use of wsa:Action attribute), 
> 
> 
> More accurately, when WSDL is used to describe how a message is
> constructed, that WSDL also provides facilities for specifying the
> [action] property.  It is important to keep metadata separate from the
> runtime.  Metadata and metadata formats may evolve.  WS-Addressing
> should work well with WSDL (1.1 and 2.0), but not require services to be
> built using metadata from a WSDL document in order to process messages
> which use WS-Addressing.
> 

Makes sense.
To ensure that I understand your concern, essentially you want to tackle 
the usecase where, say, the service is described using .Net description 
language (or something else) and the [action] value from such a 
description does not map well with the WSDL default algorithm. Therefore 
it makes sense to have such an attr to override the default.
Did I get that right?

> 
>>this value is really per message type
>>within an MEP/operation/transmission primitive. Note that there are
>>semantics associated with the MEP/operation grouping within an
>>interface/portType as well as semantics associated with the individual
>>input/output/fault message defined in WSDL. Why is it necessary to
>>provide a mechanism, specifically the wsa:Action attribute, which
>>overrides the default (where the default algorithm does produce a
>>unique value)? 
> 
> 
> We already debated just such a use case when we considered whether we
> should have separate action defaults for WSDL 1.1 and WSDL 2.0.  Though
> we decided this time that there were benefits in excess of costs in
> keeping the defaults the same between 1.1 and 2.0, those tradeoffs might
> change in a new version of WSDL or when a different description language
> is used.
> 

The usecase that I described above?

> 
>>What is the usecase for this? At the very least identical
>>(wsa:Action) attribute values should be disallowed, otherwise the
>>[action] property will not uniquely identify the semantics implied by
>>the message (type).
> 
> 
> The WSDL operation is (currently) a reasonable stand-in for the
> "semantics of the message".  But the contract of the service might go
> far beyond that, or might be captured in a form other than by making a
> WSDL document available.  We should not limit the values of <wsa:Action>
> to those which are conveniently mapped to WSDL.  We should instead
> provide facilities to describe in WSDL the possible values that
> <wsa:Action> might have.  WSDL describes the message, it doesn't
> constrain what a message may be.
> 

Could u elaborate on the last sentence?
There is a meaning and a reason to the MEP grouping in WSDL and the 
specific in/out/fault message. Do u disagree?


> 
>>2) There is a operation name mapping requirement in WSDL 2.0 [2].
>>Given
>>that we have resolved issue i031 to make [action] property required, I
>>see the [action] property can be used to satisfy the operation name
>>mapping requirement. WS-Addressing WSDL 2.0 binding should define how
>>this is done.
> 
> 
> A proposal would be nice :-).
> 

I would be happy to make such a proposal if the WG thinks that there is 
a value in pursuing this.

> 
>>HTH.
>>
>>-Anish
>>--
>>
>>[1]
>>http://lists.w3.org/Archives/Public/public-ws-
>>addressing/2004Nov/0380.html
>>[2] http://www.w3.org/TR/2004/WD-wsdl20-
>>20040803/#Interface_OperationName
> 
>

Received on Monday, 20 December 2004 19:59:19 UTC