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

i034: scope of action defaults

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Mon, 22 Nov 2004 11:01:58 -0800
Message-ID: <41A237A6.2070508@oracle.com>
To: public-ws-addressing@w3.org


During last week's call (during the discussion of issue i019) I took an 
action to explore the implication of wsdl version to the value of the 
[action] property along with other components in EPR.

Issue i019 and i034 talk about WSDL version neutrality and focuses on 
the value of the [action] property when a service is described by 
multiple WSDL documents using different WSDL versions. But an EPR has 
components that are tied to specific WSDL artifacts. Specifically:

[selected port type]

As a resolution to issue i019 we have agreed to abstract it out (wrt to 
WSDL version) and define the mappings in the WSDL mapping specification.

If an EPR contains either the [selected port type] or [service-port] 
both of which have a QName (either QName of portType/interface or QName 
of wsdl11/12 service) which identify the version of the WSDL that the 
EPR is associated with. If any of the above two properties exist in an 
EPR, then it is clear which WSDL version is in use and the issue of 
version neutrality (wrt the value of the [action] property) does not 
arise. But since the above two properties are optional, there are indeed 
cases where it will be unclear as to which WSDL is being used and 
therefore may be unclear as to what the value of the [action] property 
should be.

I would prefer that [selected port type] and [service-port] be required 
(issue i023), but pending the resolution of that issue, I would like to 
suggest that it is upto the consumer of the EPR to figure out which WSDL 
version is in play and use the appropriate WSDL binding rules. For the 
case where the service has several versions of WSDL (describing the same 
service), it doesn't really matter which version the consumer picks.


Received on Monday, 22 November 2004 19:02:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:07 UTC