W3C home > Mailing lists > Public > public-ws-policy@w3.org > October 2006

RE: NEW ISSUE: New Attribute keyword to identify 'local' policies #3721

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Wed, 18 Oct 2006 12:29:04 -0700
Message-ID: <2BA6015847F82645A9BB31C7F9D64165026D1A17@uspale20.pal.sap.corp>
To: "William Henry" <william.henry@iona.com>, "Beryozkin, Sergey" <Sergey.Beryozkin@iona.com>
Cc: "Frederick Hirsch" <frederick.hirsch@nokia.com>, <public-ws-policy@w3.org>
Nothing has been decided on whether wsp:local is not needed, although
some members of the tc probably wish that is the case :-D. 
 
The debate is still whether optional="true" is appropriate to advertise
features that may not pertain to an interaction.  
 
--umit
 


________________________________

	From: William Henry [mailto:william.henry@iona.com] 
	Sent: Wednesday, Oct 18, 2006 10:52 AM
	To: Beryozkin, Sergey
	Cc: Frederick Hirsch; Yalcinalp, Umit; public-ws-policy@w3.org
	Subject: Re: NEW ISSUE: New Attribute keyword to identify
'local' policies #3721
	
	
	I'm getting confused now. I've obviously missed some of the
discussion.  
	
	
	So it looks like wsp:local (or wsp:advisory) is not needed.
People have decided on trying to use wsp:optional for advertising
features? Is this right? (That will require extra work for dealing with
multiple assertions due to normalization. Right?)

	And on the subject of stripping out policies we are leaving that
to implementors with custom attributes. ??

	William


	On Oct 18, 2006, at 11:27 AM, Beryozkin, Sergey wrote:


		
		HI William
		 
		"The idea of using this as a mechanism for providers to
strip on configuration information gets weaker - especially when making
the above argument.  "How do it know?" ;-) to strip or not to strip?
		
		
		That ideas was that wsp:local would provide a consistent
approach for providers to have a way of stripping out such local
policies before publishing. But how do you distinguish between those
that get stripped out and those that get advertised."
		 
		Just don't put wsp:local on those assertions you want to
make visible to requesters.
		I think what you're talking about is very close to waht
Frederick suggests with a wsp:advisory <mailto:wsp@advisory>  attribute.
They mark assertions of interest to providers, clients might choose to
notice it or ignore it.
		 
		So suppose we have wsp:advisory, I thinbk it would be a
better name then.
		And we also have wsp:optional which can be used to mark
assertions which a requester can choose to ignore.
		 
		I think we'll have an overlap and more confusion as a
result. I think I like wsp:advisory, just feeling that if we adopt a new
attribute overlapping with wsp:optional then we'll have more complexity
in the end
		 
		I believe it will be simplier if a wording for
wsp:optional is updated given that wsp:optional is about assertions
which are not optional for a provider but optional for a requester to
consume... .
		 
		Cheers, Sergey

			----- Original Message -----
			From: William Henry
<mailto:william.henry@iona.com> 
			To: Beryozkin, Sergey
<mailto:Sergey.Beryozkin@iona.com> 
			Cc: Frederick Hirsch
<mailto:frederick.hirsch@nokia.com>  ; Yalcinalp, Umit
<mailto:umit.yalcinalp@sap.com>  ; public-ws-policy@w3.org
<mailto:public-ws-policy@w3.org> 
			Sent: Wednesday, October 18, 2006 6:05 PM
			Subject: Re: NEW ISSUE: New Attribute keyword to
identify 'local' policies #3721
			
			
			Hi folks, 
			
			
			The more I think about this the more I'm
convinced that it is more appropriate for advertising features or
qualities of service that do not require action by the consumer. So
using an earlier example that Sergey used with a modification
			
			
			 <wsdl:port>
			 <soap:address location="http://foo <http://foo>
"/>
			 <wsp:Policy>...
			   <sp:HTTPSToken/>
			   <custom:HighAvailability wsp:local="true"/>
			 </wsp:Policy>
			</wsdl:port>
			
			
			Though HighAvailability might require the server
to do some extra configuration the reason for putting it in the WSDL is
not for configuration but for providing extra information that MAY be of
interest to the consumer but would NOT prohibit the consumer from using
the service if they can't understand it - they can ignore it.
			
			
			The idea of using this as a mechanism for
providers to strip on configuration information gets weaker - especially
when making the above argument.  "How do it know?" ;-) to strip or not
to strip?
			
			
			That ideas was that wsp:local would provide a
consistent approach for providers to have a way of stripping out such
local policies before publishing. But how do you distinguish between
those that get stripped out and those that get advertised.
			
			
			Furthermore people in this group would say that
that is really up to the implementor and they can be responsible. (Dan
holds this position)
			
			
			HOWEVER, in this case this is also the issue of
portability. A provider that is using policies defined by another vendor
that has significance for the provider but not for the consumer would
like to understand how to handle this consistently. So for third party
policies one can imagine that a consistent way of stripping these out
would be useful.
			
			
			So then does wsp:local (or whatever it's name
is) have true, false, provideronly ??????? Otherwise how do we
distinguish between advertise-as-a-feature Vs.
provider-should-strip-before-publish?
			
			
			Regards,
			William


			On Oct 6, 2006, at 3:17 AM, Beryozkin, Sergey
wrote:


				
				Hi Frederick,
				 
				Sorry for a late response.
				 
				First of all I'd like to draw a line
between wsp:optional and something like wsp:local. We do not see any
relationship between wsp:optional and wsp:local.
				 
				The differentiator between wsp:local and
wsp:optional is simple. wsp:local marks assertions which are only
intended for a provider. Provider *should do the best effort to strip
such assertions out* of the policy to be published. If such an assertion
is leaked then the only thing the client knows about it is that it has
to skip it and move on to the next assertion. Client may choose to
notice it but there're absolutely no obligations on the provider's
behalf as to whether this assertion will be honoured or not.
				wsp:local assertions are not the ones
WS-Policy framework primer talks about when recommending best practices
for policy authors. Good interoperatable policy assertion is the one
which is understood and used by both parties involved. So why do we even
want to create a noise in the WS-Policy space with wsp:local ? We feel
there might some scenarios which I'll address in a follow-up message...
				 
				On the contrary wsp:optional and the
whole optionality tar ball is about assertions which may be of use for
requesters. wsp:local assertions may not be of use for requesters.
				 
				Optionality is a hint to a requestor.
>From the provider's point view wsp:optional assertions are not optional
at all, it guarantees to support them. 
				 
				Given what I've said I'd like to say
that I agree with some parts of your message but here're two parts which
I'n not happy about :-) :
				 
				> 2) The client can choose to include or
not in intersection operation,  
				> depending on interest.
				
				I don't think wsp:local assertions can
be of any interest to a client. I don't think we need a new attribute
like wsp:local for assertions which a client may want to do something
useful about. Policy alternatives/wsp:optional will do just fine for
this to work.
				
				 
				> Without wsp:local/wsp:optional all
assertions MUST be included in  
				> intersection operation.
				
				
				Please see above. Lets just draw the
line between wsp:local and wsp:optional :-) 
				
				> 3) This is additional information that
a client might wish to consider.
				
				Please see above. If it is of any use to
a client then it's not a wsp:local assertion
				 
				Thanks, Sergey
				
				 
				
				 
				
				 
				> Sergey
				> 
				> It was mentioned by Fabian on the call
today that different  
				> assertions can have different
properties, and I think this is where  
				> we are heading with
wsp:local/wsp:advisory (alternative names for the  
				> same concept and attribute)
				> 
				> In general an assertion present in a
policy assertion means that the  
				> client MUST understand that assertion
and that the provider WILL  
				> support it. This is regardless of
whether the assertion has a wire  
				> implication.
				> 
				> Using wsp:optional enables policy
alternatives to be easily created,  
				> either requiring and asserting the
assertion and not.
				> 
				> However there are cases where
wsp:optional is not what is desired,  
				> and where wsp:local/wsp:advisory is
needed.
				> 
				> The use case is that a provider should
be able to state an assertion  
				> that will be in effect, but it obeys
the following properties:
				> 
				> 1) It can safely be ignored by web
service client, even though true.  
				> The provider is making no obligation
to the client. It has no  
				> essential impact on a contract between
client and provider.
				> 
				> An example is an assertion that server
logging is performed (e.g.  
				> clients might not care about it, but
it is *not* optional in the  
				> sense that the server *will* do it).
				> 
				> 1a) Assertions that imply mutual
contract between client and provider  
				> cannot be wsp:local/wsp:advisory.
These include
				> 
				> + Assertions that impact wire formats
				> + Assertions that define quality of
service (service level  
				> agreements), quality/reliable
messaging.
				> 
				> 2) The client can choose to include or
not in intersection operation,  
				> depending on interest.
				> Without wsp:local/wsp:optional all
assertions MUST be included in  
				> intersection operation.
				> 
				> 3) This is additional information that
a client might wish to consider.
				> 
				> we need to distinguish optional for
agreement of a contract with or  
				> without an asserted
requirement/capability and informational items  
				> that are not necessarily optional.
				> 
				> regards, Frederick
				> 
				> Frederick Hirsch
				> Nokia
				> 
				> 
				> On Oct 4, 2006, at 4:30 AM, ext Sergey
Beryozkin wrote:
				> 
				>> Hi
				>>
				>> Reference to the thread[1] is
misleading IMHO.
				>> I was stating from the start that a
proposed wsp:local was nothing  
				>> to do with what is discussed in that
thread. The semantics of  
				>> wsp:local are : mark assertions which
*must be ignored* by a  
				>> requester. That is it, no more
semantics...
				>>
				>> Thanks, Sergey
				>> ----- Original Message -----
				>> From: Yalcinalp, Umit
				>> To: public-ws-policy@w3.org
<mailto:public-ws-policy@w3.org> 
				>> Sent: Tuesday, October 03, 2006 11:44
PM
				>> Subject: Re: NEW ISSUE: New Attribute
keyword to identify 'local'  
				>> policies #3721
				>>
				>>
				>> There has been a lot of discussion on
Issues 3721 and 3564. I am  
				>> posting this response to this thread
in order to illustrate why  
				>> there are two separate issues that
need to be tackled  
				>> independently. However, they are NOT
the same issue. Utilization of  
				>> optional assertions is a separate
concern and those issues must not  
				>> be lumped together.
				>>
				>> Please find some comments in a
different thread that explains why  
				>> there are two separate issues here
for the details [1].
				>>
				>> Thanks,
				>>
				>> --umit
				>>
				>> [1]
http://lists.w3.org/Archives/Public/public-ws-policy/2006Oct/
<http://lists.w3.org/Archives/Public/public-ws-policy/2006Oct/>  
				>> 0016.html
				>>
				>> ----------------------
				>>
				>> Dr. Umit Yalcinalp
				>> Architect
				>> NetWeaver Industry Standards
				>> SAP Labs, LLC
				>> Email: umit.yalcinalp@sap.com
<mailto:umit.yalcinalp@sap.com>  Tel: (650) 320-3095
				>> SDN:
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238
<https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238> 
				>> --------
				>> "First they ignore you, then they
ridicule you,
				>> then they fight you, then you win."
Gandhi
				>>
				>>
				>
Received on Wednesday, 18 October 2006 19:31:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:42 GMT