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

Syntax options for Async

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Wed, 16 Nov 2005 10:50:26 -0800
Message-ID: <2BA6015847F82645A9BB31C7F9D6416593C7F5@uspale20.pal.sap.corp>
To: "WS-Addressing" <public-ws-addressing@w3.org>

I took an [action item] to send Proposal 1 so that it can be reevaluated
and modified. I am wondering whether we could make high level decisions
on the syntax first because this is where we will end up anyway. If we
make a decision first on this, it is easier to write this section as it
is a straightforward exercise. 

We have three options to represent asyncronous capabilities of the
endpoint, binding or binding/operation to describe the granularity of
supporting anonymous and non-anonymous URI as response addresses. 

We have three granularity levels to support (full capabilities of
addressing, supporting only anonymous URIs as response addresses or
supporting only non-anon) 

(1) Two elements (as [Proposal1]) 
   usingAddressing element as currently described
   Async element which is used in conjunction with usingAddressing
element with three values. 

(2) Marc's proposal (usingAddressing element with an attribute with
three values) [Marc]. 
    He proposes "Required", "Allowed", "Disallowed". I propose
"AnonRequired", "AnonDisallowed", "AnonAllowed" to reflect the semantics
we want to capture. 

(3) (new option) This came up during our conversations in writing
Proposal 1 and I speculate it may be discussed again. 

   Use three elements:

   usingAddressing: It corresponds to the full usage of addressing
semantics including both anon/non-anon URI
   usingAddressingAnonURIRequired (obvious)
   usingAddressingNonAnonURIRequired (obvious) 

In option 1 and 2, we need to replace the text: 

{The inclusion of the wsaw:UsingAddressing element indicates that the
applicable WS-Addressing specifications are supported within the
constraints of the WSDL binding being used. That is, uses of the
WS-Addressing specifications that may violate or are inconsistent with
the semantics of the endpoint's WSDL binding are not supported unless
explicitly stated by some other mechanism.
Specifically, when included in a SOAP binding, the wsaw:UsingAddressing
marker identifies the use of Web Services Addressing 1.0 bound to SOAP
as defined by Web Services Addressing 1.0 - SOAP
Binding[WS-Addressing-SOAP <> ].
The presence of the wsaw:UsingAddressing element in the binding or
endpoint (port) components of the endpoint description does not change
the semantics of the binding. E.g. in the case of the WSDL SOAP/HTTP
synchronous binding for request-response operations, the presence of the
wsaw:UsingAddressing element does not change the requirement that the
response message be sent over the same HTTP channel over which the
request was received. In this case, the wsa:replyTo header in the
request MUST NOT contain an address with a value different from the
anonymous URI.}

The last option requires changes section 3.1 somewhat as we need to
introduce all the new elements. 

Let me know if you still want to see the full writeup for Option 1. I
will be very happy to write the target text depending on which syntax
that we choose to adopt as well. 

All syntax formulations must reflect the decision we have taken as a wg,

== there are three levels of granularity
== the new {Async element/attribute|?} is general, not targeted to
SOAP1.1/HTTP and talks about anon/non-anon URIs in their definition. 
== scoping is extended to binding operation 
== separate section targets SOAP 1.1/HTTP binding semantics (semantics
of separate connection, 202, etc). 


[Action Item] http://www.w3.org/2002/ws/addr/5/11/f2f-minutes.html
Received on Wednesday, 16 November 2005 18:49:11 UTC

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