RE: Options 1 and 3 Here we go.

Jonathan, 
 
Some reactions to your comments. 
 
ProposalLast: I used some of the same techniques that were in place for
WSDL 2.0. We have styleDefault attribute, mepDefault, etc. Hence the
attribute notation, since there is a prior example. I am not tied to
this, but since you brought up the defaulting behaviour in the last
concall, I used WSDL 2.0 as an example. 
 
The reason I thought constraints could be useful is because addressing
is an endpoint/binding level engagement. Specific message exchanges may
restrict/constrain the use. From an implementation perspective, I do not
expect a defaulting at a higher level to specify (say prohibitied/never)
but specific operations to require full support of anonymous values. It
seems strange to me. This is why I wanted to open it for discussion and
included in the note. 
 
ProposalLastWithThreeElements: If we were to allow only tweaking of
Anonymous granularity behaviour at the operation level as you suggest
and not allow addressing support at the operation level , then it seems
to me this particular proposal actually would be very similar to
ProposalLast. I really do not see the benefit of having three different
elements in that sense, we should just work with ProposalLast and not
pursue this option. 
 
--umit
 


________________________________

	From: Jonathan Marsh [mailto:jmarsh@microsoft.com] 
	Sent: Monday, Nov 28, 2005 12:34 PM
	To: Yalcinalp, Umit; public-ws-addressing@w3.org
	Subject: RE: Options 1 and 3 Here we go. 
	
	

	Thanks for the write-ups.  Some initial thoughts:

	 

	ProposalLast:
	
	

	As I said last time, for naming I prefer
<wsaw:Anonymous>optional|required|prohibited</>.  I also don't like the
@anonymousUseDefault syntax.  It is strange to set an element default by
way of an attribute.  I also like having anonymous control completely
separate from wsaw:UsingAddressing, so these facilities can be reused
by, for instance, policy assertions (just as wsaw:Action can).  So I'd
prefer an <wsaw:AnonymousDefault>optional|required|prohibited</>
element, a sibling of <wsas:UsingAddressing>, over the attribute syntax.
I don't see why there should be constraints on consistent values either
- the "property" is an operation level property - the defaulting is just
syntax.

	 

	ProposalLastWithThreeElements:

	 

	You have opened up as a discussion point the possibility of
allowing WS-A to be turned on and off at operation level granularity.
If that's open for discussion, I'd like also to discuss the possibility
of not providing operation level granularity for the async control.
That would radically simplify both of the proposals, but especially this
one.  An endpoint or binding could include any one of the three
UsingAddressing elements - binding and endpoint assertions cannot be in
conflict.  Such an approach seems like the best simplicity/functionality
tradeoff to me.

	 

	 

	
________________________________


	From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Yalcinalp,
Umit
	Sent: Sunday, November 27, 2005 8:57 PM
	To: public-ws-addressing@w3.org
	Subject: Options 1 and 3 Here we go. 

	 

	 

	I slugged away on Turkey weekend for the following two writeups.
I am not sure what kind of bonus/booby trap I will get with this effort,
so apologies in advance if there are small mistakes, etc in the writeups
in advance. I want to send these out so that we can discuss tomorrow. 

	I do hope that I covered all the input from last week's concall
meaning: 

	Option 1: (Labelled ProposalLast): I have incorporated defaults
for anonymous uri usage on the definition of wsaw:UsingAddressing
element with an attribute to indicate default usage similar to WSDL 2.0
definition of defaults for some extensions. Since using attribute
extensions were known to be problematic for operations and keeping
granularity for operation specific semantics was important for some, I
have used WSDL 2.0 as my example and defined wsaw:AnonymousUse element
to override defaults only in binding operation components. I think this
writeup is in the spirit of defining the granularity with an attribute
at the operation level, but does not have the same pitfall that we
discussed last week with respect to BP1.1/WSDL 1.1 inconsistencies wrt
extensibility hoopla. 

	So, there it is. I also included the semantics of SOAP 1.1/HTTP
in both Options 1 and 3. 

	Option 3 (labelled ProposalLastWithThreeElements): I had to
invent some restrictions so that three different elements did not appear
in multiple places with semantics which were inconsistent with each
other. Otherwise, you will quickly notice that allowing multiple
elements, i.e. one in binding one in binding operation will get you in
the same land that is defined by Option 1. If you want to allow this
kind of mix and match, I suggest we actually drop Option 3 and consider
Option 1 instead, since it is cleaner. 

	I kept Option 3 because I introduced a restriction (see Note in
the writeup) for simplification of scopes, otherwise it is the same
semantics as Option 1 and is not cleaner (due to attachment granularity
issues). 

	For both proposals, I included Notes to reader for those things
that I anticipated a lot of discussion. 

	Please note that I included different examples to illustrate the
different proposals in detail at the end. <<ProposalLast.htm>>
<<ProposalLastWithThreeElements.htm>> 

	All changed/new text is in purple with no specific meaning, I
just happened to like purple today. 

	--umit 

	 

	---------------------- 

	Dr. Umit Yalcinalp 
	Standards Architect 
	NetWeaver Industry Standards 
	SAP Labs, LLC 
	umit.yalcinalp@sap.com 
	Tel: (650) 320-3095