RE: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requester

Folks, 

Here is my proposal to close issues [3789] and [3721]. Call it proposal
5. 

I am including here only the changes that will impact the framework.
There has been quite a discussion on the use cases for both of these
issues. I will be happy to draft text to illustrate the use of the
attribute if we accept the proposal for specifically the guidelines
document and the primer. Since we are trying to close all the issues on
the framework, I targeted text for this section only. Note that for the
configuration parameters, only the providers tools will understand them.
For those which have no behavioral requirements and not affect the wire,
the client can choose to understand the vocabulary. 

IMO, this proposal has the advantage of addressing different uses of an
assertion, allows different consumers to be able to include them into
their intersection algorithm, allows the provider only or client tools
to process intersections in a uniform way and thus satisfies both the
issues at hand with a minimum disruption to the framework. 

If you think we should include a "default" value to the attribute and
assume all assertions exhibit a predetermined value to target all
consumers, I am open to that. However, the way I wrote it, the
assertions that do not have this attribute do get included into the
alternative vocabulary so, that would be an addition which may not be
necessary. 

Note that I am not tied to the name of the attribute. If you want to
call it mustUnderstand, I do not care, but I like my name better. These
assertions are included only when the consumer understands them. 

[3789] http://www.w3.org/Bugs/Public/show_bug.cgi?id=3789
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=3789> 

[3721] http://www.w3.org/Bugs/Public/show_bug.cgi?id=3721
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=3721> 

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

Here is the proposal: 

Section 3.1: Add the following section

3.1.1 wsp:include attribute information item 

WS-Policy framework provides a global attribute information item to
enable authors to selectively designate the consumers of the assertion
based on the value of the attribute. 

		A [local name] of include .

		A [namespace name] of "http://www.w3.org/@@@
<http://www.w3.org/@@@> ".

	The type of the include attribute information item is a list
xs:anyURI. Its actual value MUST be an absolute IRI as defined in [IETF
RFC 3987 <outbind://85/l%20RFC3987> ]. 

	The presence of this attribute indicates that the assertion is
targeted to a specific set of consumers for processing this attribute.
Although the type of the assertion is part of a policy expression's
vocabulary it appears, however it is only utilized by targeted consumers
for intersection [See Section 4.4 Policy Intersection]. Authors should
not utilize this attribute for assertions that are required for
interoperability targeted to all consumers. 

	Changes to Section 4.4 

	Replace the paragraph: 

{As a first approximation, an algorithm is defined herein that
approximates compatibility in a domain-independent manner; specifically,
for two policy alternatives <outbind://85/l%20policy_alternative>  to be
compatible, they must at least have the same policy alternative
vocabulary <outbind://85/l%20policy_alternative_vocabulary>  (see
Section 3.2 Policy Alternative <outbind://85/l%20rPolicy_Alternative>
).}

With the following/Make this sentence a paragraph:

{As a first approximation, an algorithm is defined herein that
approximates compatibility in a domain-independent manner; specifically,
for two policy alternatives <outbind://85/l%20policy_alternative>  to be
compatible, they must at least have the same policy alternative
vocabulary <outbind://85/l%20policy_alternative_vocabulary>  (see
Section 3.2 Policy Alternative <outbind://85/l%20rPolicy_Alternative> )
subject to the assertions that are present in an alternative that are
marked with wsp:include attribute in the vocabulary. Each assertion that
uses wsp:include attribute is included in the alternative only if a
consumer of the alternatives (for example, a requestor) handling the
intersection understands the value of the wsp:include URI value.
Otherwise, the assertion type is not considered part of the alternative.
The following rules apply after this processing: }

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

Dr. Umit Yalcinalp

Architect

NetWeaver Industry Standards

SAP Labs, LLC

Email: 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

"You die. Gandhi was an optimist" Roberto Chinnici


________________________________

	From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
	Sent: Wednesday, Nov 01, 2006 10:42 AM
	To: Sergey Beryozkin; public-ws-policy@w3.org
	Subject: Re: NEW ISSUE :Clarify usage of assertions with no
behavioral requirements on the requester
	
	
	Hello
	 
	I'd just like to explore a Proposal3 below in a bit more detail,
copying it here for convenience :
	 
	Proposal 3. Introduce a new attribute wsp:provider-only and
leave wsp:optional the way it is now.
	 
	Ex :
	 
	<Policy>
	<m:MTOM wsp:optional="true"/>
	<sp:security/>
	<!-- of potential interest to requesters -->
	<m:highlyAvailable wsp:provider-only="true"/>
	<!-- server-specific stuff, of no interst to requesters-->
	<m:myCustomServerLogging wsp:provider-only="true"/>
	</Policy>
	 
	I'd like to remove server-only private stuff from here and
concentrate only on capabilities which can be of interest to clients.
Additionally, just for the purpose of this example I'll use wsp:advisory
instead of wsp:provider-only because I just like wsp:advisory the name
:-). Lets assume for a sec wsp:advisory is good for advertizing
capabilities which can be ignored, server-specific stuff does not go
here at all :
	 
	<Policy>
	<m:MTOM wsp:optional="true"/>
	<sp:security/>
	<!-- of potential interest to requesters -->
	<m:replicatable wsp:advisory="true"/>
	</Policy>
	 
	Normal form :
	 
	
	<Policy>
	<ExactlyOnce>
	<All>
	  <m:MTOM/>
	  <sp:security/>
	  <m:replicatable wsp:advisory="true"/>
	</All>
	<All>
	  <sp:security/>
	  <m:replicatable wsp:advisory="true"/>
	</All>
	</ExactlyOnce>
	</Policy>
	 
	With wsp:optional we only mark optional assertions with some
behaviours a requester will need to do.
	With wsp:advisory we only mark things a requester may choose
either to notice or ignore. Note that in the case of
	 
	I've thought more about it. I feel that it's kind of nice to
have this separation of concerns. It makes sense. However I'm not sure
that it makes things simplier/less unambiguous and confusing from a
practical perspective :
	 
	* there's some overlap here in that both <m:MTOM/> and
<m:replicatable/> are assertions a requester may optionally ignore. I
just feel it will cause a lot a lot of confusion for users to figure out
what should be marked as wsp:optional and wsp:replicatable (and then
withsome standard wsp:local attribute marking pure server-only
assertions :-)). I think the above example shows there's some ambiguity
in  how <m:replicatable wsp:advisory="true"/> should be interpreted, it
is in the alternative, but at the same time it's not because it can be
ignored, it kind of dilutes the meaning of alternative.
	 
	* people would still be able to make <m:replicatable/> with
wsp:optional
	* people would likely start marking server-only assertions like
<m:myCustomServerLogging/> with wsp:advisory/as well as with
wsp:optional.
	* it's not clear what a requester seeing <m:replicatable
wsp:advisory="true"/> should do if does not understand what it means :
just ignore it, or ignore it and warn a user ? 
	* it's not clear what a requester seeing
<m:myCustomServerLogging wsp:advisory="true"/> should do if does not
understand what it means : just ignore it, or ignore it and warn a user
? this is an example of misused <m:myCustomServerLogging/> 
	* I think it will slow down the requester's processing because
even though <m:replicatable wsp:advisory="true"/> is marked as something
which can be ignored a requester will still to process it and check if
it's something it actually understands or not...
	 
	So far Proposal1 with a possible renaming to wsp:ignorable (and
controversial 2 :-)) or Proposal4 (workaround) work for me...they just
seem simplier, don't really require to do anything major. I'm not sure
adding a new attribute will simplify/clarify things but lets think more
Proposal3 too...
	 
	And I can't help waiting reading a Proposal 5 from Umit :-)
	 
	Enjoy
	Sergey
	 
	 
	 

		
		
		Hello,
		 
		As part of the action assigned to me at the yesterday's
concall, I'd like to offer to your attention 4 alternative proposals on
how to resolve this issue which I believe have been mentioned before. I
hope the subsequent discussions will point to a best/preferred/least
controversial/simpliest/easy to understand solution. 
		 
		I'd like to clarify that the purpose of resolving this
issue is to have a guideline to policy authors which wish to advertize
some of provider's capabilities. For ex, custom:free,
custom:infoConfidential, custom:highlyAvailable, custom:replicatable
which requesters can ignore or do something about.
		I'll add my own comments (S.B) to each of the proposal.
However, please do not consider them as something which represents the
position of Iona at this stage.
		 
		 
		Proposal1.
		Drastically simplify the meaning of wsp:optional.
Explain that wsp:optional marks an assertion which can be ignored by a
requester. In other words wsp:optional is identical in meaning to
wsp:ignorable. Clearly state that wsp:optional assertions are by no
means optional to a provider. 
		Explain that wsp:optional is a shortcut which simplifies
creating different policy alternatives/vocabularies.
		Ex : <custom:infoConfidential wsp:optional="true"/>
means a requester can ignore it.
		 
		 
		<S.B>  IMHO this is the simpliest solution which works.
IMHO the current treatment of wsp:optional is too complicated. For ex, I
think stating that if there's something a provider always does should
not be marked as optional, otherwise it has to be optional will only
confuse the users. IMHO it's wrong to say a provider optionally does
MTOM, it always does it, one requester can choose an alternative with no
MTOM but it does not mean the provider does not do it with the other
requester. In other words an alternative is a piece of vocabulary. If
MTOM is not in the selected alternative or not it does not mean that a
provider has lost its capability to do MTOM. Viewing wsp:optional as a
simple marker to indicate ignorable assertions is a very simple and
working solution IMHO.
		<S.B> additional advantage is that it cleanly alligns
with a proposed wsp:local attribute in that a user will be guided to
mark server-specific stuff as being wsp:local. Imagine a GUI asking a
question : 
		* "Is this assertion must be understood by a requester",
YES-normal assertion.
		* "Is this assertion may be ignored by a requester",
YES-multiple vocabularies are created, addional question : "Can this
ignorable assertion be of any interest to a requester ?" NO - mark it as
wsp:local.
		Nothing will prevent a user by exposing
<myLocalServerOnlyAssertion/> by marking it as wsp:optional. This
approach will proactively teach a user not to do it and only expose
assertions which can be of interest to a requester.
		 
		Proposal 2. Similar to proposal1. Drop wsp:optional
altogether and find out how simple things have become. The reason it
works is that if we forget about wsp:optional for a second, we can
easily see that if one assertion is contained in one alternative and not
in the other one then it's an optional/ignorable assertion. Another
reason it works is that we can imagine policy authors using GUI tools
which guide them. Imagine questions like : "Is this assertion must be
understood by a requester" ? "Is this assertion may be ignored by a
requester" ? Yes to the last question will result in a tool creating two
alternative vocabularies.
		 
		<S.B> the same comments as above
		<S.B> disadvantage is that more work will be requiored
in a manual edit mode.
		 
		Proposal 3. Introduce a new attribute wsp:provider-only
and leave wsp:optional the way it is now.
		 
		Ex :
		 
		<Policy>
		<m:MTOM wsp:optional="true"/>
		<sp:security/>
		<!-- of potential interest to requesters -->
		<m:highlyAvailable wsp:provider-only="true"/>
		<!-- server-specific stuff, of no interst to
requesters-->
		<m:myCustomServerLogging wsp:provider-only="true"/>
		</Policy>
		 
		<S.B.> This works only if wsp:provider-only="true" are
not stripped but this means wsp:provider-only="true" pointing to
server-specific stuff only won't be stripped and be consistently leaked
(and confuse a user at a design-time). If it's stripped then we'll lose
<m:highlyAvailable/> which is of interest to knowledgeable requesters.
IMHO it's a can of worms. 
		 
		Proposal 4. Noop. Think of workarounds : multiple
endpoints, different Policies, WSDLs, etc...
		 
		 
		Enjoy, Sergey.