W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

RE: Issue 019: WSDL Version Neutrality

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Tue, 9 Nov 2004 21:42:07 +0100
Message-ID: <99CA63DD941EDC4EBA897048D9B0061D0E07DC04@uspalx20a.pal.sap.corp>
To: "'Hugo Haas'" <hugo@w3.org>
Cc: public-ws-addressing@w3.org

>-----Original Message-----
>From: public-ws-addressing-request@w3.org 
>[mailto:public-ws-addressing-request@w3.org] On Behalf Of Hugo Haas
>Sent: Tuesday, Nov 09, 2004 9:46 AM
>To: Yalcinalp, Umit
>Cc: public-ws-addressing@w3.org
>Subject: Re: Issue 019: WSDL Version Neutrality
>
>
>Hi Umit.
>
>* Yalcinalp, Umit <umit.yalcinalp@sap.com> [2004-11-09 03:02+0100]
>> >- the action MIH has some WSDL 1.1 language associated to 
>it. I would
>> >  propose:
>> >
>> >    It is RECOMMENDED that value of the [action] property is a URI
>> >    identifying an input, output, or fault message within a WSDL
>> >    description.
>> >
>> >- the main issue with the action MIH comes from:
>> >
>> >    An action may be explicitly or implicitly associated with the
>> >    corresponding WSDL definition. Section 3.3 below describes the
>> >    mechanisms of association.
>> >
>> >  However, section 3.3 describes a WSDL 1.1-specific 
>mechanism. If the
>> >  service has a WSDL 2.0 description, another mechanism needs to be
>> >  used, which is actually defined by the WSDL 2.0 specification[4].
>> >
>> >  I would therefore propose that section 3.3 be introduced as a
>> >  mapping of a WSDL 1.1 description to an action URI, that we note
>> >  that for WSDL 2.0, the message reference component URI should be
>> >  used.
>> >
>> 
>> 
>> After many hours of discussions in WSDL 2.0 wg with respect 
>to how to carry operation names on the wire, the  content of 
>[action] with the fragment identifier as proposed looks a lot 
>like the operation name feature for WSDL 2.0 [1], which is 
>described in Section 2.2.1.1. Interestingly, there has been 
>resistence to make it a required feature [2]. 
>> 
>> Action delivers exactly the requirement that the operation 
>name feature was trying to deliver with your proposal, namely 
>making the operation name on the wire to be present. If Action 
>is required to be present, as being debated now, consequently 
>the operation name will always present as suggested by the 
>fragment identifier value ONLY IF the value of [action] MUST 
>be the fragment identifier.  
>> 
>> Therefore, I am trying to get a clarification to whether you 
>are suggesting that the value SHOULD be the fragment 
>identifier or MUST be? Following the similar debate, the 
>answer begs the question as to whether it is possible to 
>define a "null" action (even if Action is required) or whether 
>the proposed [action] values MAY contain URI values including, 
>but not limited to, fragment identifiers of message reference 
>components.  
>
>As it stands, this is only a default value for people who have a WSDL
>in their hands (a SHOULD). However, you could not use a "null" value
>as the [action] URI is mandatory, though you could certainly use an
>unhelpful one such as "http://unhelpful.example/".

That is what I was getting at ("null"/not meaningful). There are two different things here

-- whether Action is required or not. 
-- What its value must/should be

Even if the Action is required, it is possible to define a meaningless Action (aka "null"). As far as I understand your proposal, one would not be required to constrain the Action values to URIs for message reference components, but would be recommended to. 
 
>
>Basically, the use of addressing will give people the ability to
>fulfill the operation name requirement, but I think that it will only
>fulfill it if they use it to provide useful information, which the
>implicit value does.


>
>Cheers,

Thanks for the clarification, 

--umit

>
>Hugo
>
>-- 
>Hugo Haas - W3C
>mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
>
Received on Tuesday, 9 November 2004 20:42:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT