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