RE: Syntax options for Async

I agree we need to drop async from the element/attribute names for any
of the options, too. 
 
I can go with any of them, although 2 or 3 are cleaner.  
 
--umit
 


________________________________

	From: David Hull [mailto:dmh@tibco.com] 
	Sent: Wednesday, Nov 16, 2005 10:58 AM
	To: Yalcinalp, Umit
	Cc: WS-Addressing
	Subject: Re: Syntax options for Async
	
	
	I prefer (2).  I believe the name of the attribute was to be (or
contain) "Anonymous", in which case
	

		<wsa:UsingAddressing Anonymous="Allowed"/>
		

	seems better than
	

		<wsa:UsingAddressing Anonymous="AnonAllowed"/>
		

	Again, I don't like the use of "async" anywhere in this, as the
term is too heavily overloaded.
	
	Yalcinalp, Umit wrote: 

		Folks, 

		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, namely 

		== 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). 


		--umit 


		[Proposal1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0116.ht
ml
<http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0116.h
tml>  
		[Marc]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0039.ht
ml
<http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0039.h
tml>  
		[Action Item]
http://www.w3.org/2002/ws/addr/5/11/f2f-minutes.html
<http://www.w3.org/2002/ws/addr/5/11/f2f-minutes.html>