Re: Syntax options for Async

On Nov 16, 2005, at 1:58 PM, David Hull wrote:

> 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"/>

Same here, adding 'Anon' to the value seems superfluous given that it  
is already the name of the attribute.

Marc.

> 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.html
>> [Marc] http://lists.w3.org/Archives/Public/public-ws-addressing/ 
>> 2005Nov/0039.html
>> [Action Item] http://www.w3.org/2002/ws/addr/5/11/f2f-minutes.html
>>
>>
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.