Re: Syntax options for Async

Marc Hadley wrote:
> 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.
> 

+1

I also agree with David that we should not use 'async' anywhere in this, 
this is about the anon value.

-Anish
--

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

Received on Monday, 21 November 2005 20:51:12 UTC