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:30:32 -0700
Message-ID: <2BA6015847F82645A9BB31C7F9D64165026D1A1A@uspale20.pal.sap.corp>
To: "Sergey Beryozkin" <sergey.beryozkin@iona.com>, "William Henry" <william.henry@iona.com>
Cc: "Frederick Hirsch" <frederick.hirsch@nokia.com>, <public-ws-policy@w3.org>
It is my understanding that presence of wsp:local or wsp:advisory would
provide the same functionality. So, the question is to come up with an
appropriate name everyone agrees. 
 
--umit
 


________________________________

	From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] 
	Sent: Wednesday, Oct 18, 2006 10:28 AM
	To: William Henry
	Cc: Frederick Hirsch; Yalcinalp, Umit; public-ws-policy@w3.org
	Subject: Re: NEW ISSUE: New Attribute keyword to identify
'local' policies #3721
	
	
	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 
		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"/>
		 <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:32:00 GMT

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