Re: Action Item

A few notes/comments:

(i) Do we need additional text for, or changes to, the existing  
section 3.2 which describes use of the wsoap:module construct instead  
of wsaw:UsingAddressing ? As it stands, the existing section 3.2  
covers the semantics of wsaw:UsingAddressing but not for the proposed  
wsaw:Anonymous.

(ii) Editorially I would promote the proposed "3.1.1 wsaw:Anonymous  
element" to be a new 3.x peer subsection to the existing "3.1  
UsingAddressing Extension Element" section. A stronger treatment of  
the co-occurrence constraints between wsaw:UsingAddressing and  
wsaw:Anonymous is also required - something similar to that done for  
wsaw:Action would probably suffice.

(iii) I think we need a new subsection for the proposed 3.1.1  
wsaw:Anonymous element that provides the equivalent of the existing  
"3.1.1 WSDL 2.0 Component Model Changes". I.e. we need a section that  
describes the impact of the wsaw:Anonymous element on the WSDL 2.0  
component model.

(iv) As I raised in the call last week, I don't think that the  
majority of the text in the proposed "3.1.2 SOAP 1.1/HTTP Extension  
Semantics by using wsaw:UsingAddressing element" belongs in the WSDL  
binding document. It is SOAP specific and describes runtime binding  
operation details rather than description details. There is also  
significant duplication with the proposed "3.1.1 wsaw:Anonymous  
element" text when discussing the meaning of the 3 values of  
wsaw:Anonymous.

(v) Regardless of the eventual home for the text in the proposed  
3.1.2, I wonder if rather than restating how one-way for SOAP1.1/HTTP  
works we should just refer to the WS-I Basic Profile specification of  
same.

Marc.

On Dec 2, 2005, at 5:42 PM, Yalcinalp, Umit wrote:

> This completes my action item from last week [1].
>
> Please find the updated writeup for the  option1 [2] named  
> ProposalLast. Purple is the changed/new text in comparison to the  
> editor's draft [3].
>
> Let me remind everyone that this writeup reflects the consensus  
> point of the f2f and past 2 weeks discussion in the tc to rewrite  
> the agreed semantics up to this point.
>
> - We have two elements, UsingAddressing and Anonymous (changed from  
> AnonymousUse as suggested last week)
> - UsingAddressing may appear in binding/endpoint. (as it is)
> - I removed the default attribute, however UsingAddressing  
> indicates support for both anon and non-anon URIs as addresses as  
> it was in the previous writeup [2].
>
> - Anonymous element uses required/prohibited/allowed as values. It  
> can only appear within a binding operation. The values are changed  
> per the decision last week [1].
>
> - SOAP1.1/HTTP binding is described. I cleaned it up from the last  
> writeup [2].
> - I deleted one of the examples.
>
> David Hull, I did NOT include your suggestions to this as I have  
> made some changes to the current SOAP1.1/HTTP section (some  
> restructuring/simplification). Since you felt that your changes  
> were additive, my suggestion for you is to take the text and  
> illustrate the changes with this latest writeup.  I really do not  
> have the cycles to include your text and find the conflicts/ 
> synergy, at least not this week, or whatever is left of it :-(
>
> Marc, editorial comments are appreciated esp. with the last  
> paragraph of 3.1 prior to 3.1.1 if we decide to use this writeup in  
> the spec.
>
> Thanks,
>
> --umit
>
>
> [1] http://www.w3.org/2002/ws/addr/5/11/28-ws-addr-minutes.html
> [2] http://lists.w3.org/Archives/Public/public-ws-addressing/ 
> 2005Nov/0084.html
> [3] http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr- 
> wsdl.html?content-type=text/html;%20charset=utf-8
>
>
> Ps. It feels like Jonathan is trying to take the wind from my sails  
> with the policy assertion debate :-D.
> <<ProposalLastWithoutDefaults.html>>
> ----------------------
>
> Dr. Umit Yalcinalp
> Standards Architect
> NetWeaver Industry Standards
> SAP Labs, LLC
> umit.yalcinalp@sap.com
> Tel: (650) 320-3095
>
> <ProposalLastWithoutDefaults.html>

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