- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Tue, 7 Nov 2006 06:33:01 -0800
- To: "Sergey Beryozkin" <sergey.beryozkin@iona.com>, <public-ws-policy@w3.org>
- Message-ID: <2BA6015847F82645A9BB31C7F9D641650293D169@uspale20.pal.sap.corp>
I believe the guideline is in the proposal:
If an assertion applies to all consumers, do not mark it with
wsp:include. Use it with caution. Thus the guideline is the same.
We can elaborate and put it in a specific paragraph to the guidelines
document. Would that be acceptable?
--umit
________________________________
From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
Sent: Tuesday, Nov 07, 2006 9:16 AM
To: Yalcinalp, Umit; public-ws-policy@w3.org
Subject: Re: NEW ISSUE :Clarify usage of assertions with no
behavioral requirements on the requester
Hi Umit
Quick question :
<example:Logging
wsp:include="htpp://www.example.com/clientspecific">
What is the guideline on this one :
* has to be excluded at all from the requester's view or made
visible ?
How would a requester at design tiem will figure whether it's
something that a user should not worried about or something a user
should be asked about ?
Thanks, Sergey
----- Original Message -----
From: Yalcinalp, Umit <mailto:umit.yalcinalp@sap.com>
To: Sergey Beryozkin <mailto:sergey.beryozkin@iona.com>
; public-ws-policy@w3.org
Sent: Tuesday, November 07, 2006 2:08 PM
Subject: RE: NEW ISSUE :Clarify usage of assertions with
no behavioral requirements on the requester
Lets take one of these from the thread:
<Policy>
<m:MTOM wsp:optional="true"/>
<sp:security/>
<!-- server-specific stuff, of no interst to
requesters-->
<example:Logging
wsp:include="htpp://www.example.com/clientspecific">
</Policy>
Assume the policy is attached to the endpoint. This
example will yield ONE Policy two alternatives. One with MTOM, and one
without MTOM. Both alternatives contain sp:security and example:Logging.
There are three different assertion types, m:MTOM,
sp:security, example:Logging.
(a) From the clients perspective, if wsp:include was not
present, all three assertion types WOULD BE in the vocabulary thus must
be understood. Thus if you want to log the messages all the time, the
intersection algorithm would fail.
(b) Since wsp:include is present, the clients must
understand only MTOM and sp:security, but not example:Logging.
The clients who do not understand URI
"htpp://www.example.com/clientspecific" will have two alternatives where
example:Logging does not occur in the vocabulary.
This allows the logging to be present in all the
alternatives without affecting specific clients that need to understand
this vocabulary.
Does that help?
--umit
________________________________
From: Sergey Beryozkin
[mailto:sergey.beryozkin@iona.com]
Sent: Tuesday, Nov 07, 2006 8:54 AM
To: Yalcinalp, Umit; public-ws-policy@w3.org
Subject: Re: NEW ISSUE :Clarify usage of
assertions with no behavioral requirements on the requester
Hi Umit
Thanks...
Can you please provide some simple examples
which show the usage of wsp:optional and wsp:include (marking both truly
private assertions and those which may be of interest to requesters and
which you believe should be marked with wsp:include rather rthan with
wsp:optional) at the same time.
This would really help (myself at least) in
understanding your proposal better
Cheeers, Sergey
----- Original Message -----
From: Yalcinalp, Umit
<mailto:umit.yalcinalp@sap.com>
To: Sergey Beryozkin
<mailto:sergey.beryozkin@iona.com> ; public-ws-policy@w3.org
Sent: Tuesday, November 07, 2006 1:46 PM
Subject: RE: NEW ISSUE :Clarify usage of
assertions with no behavioral requirements on the requester
Please note that wsp:include only
applies during the intersection (after normalization) and after
alternatives are determined.
Thus, there is no change in the usage of
wsp:optional as it stands today. Therefore, just as before, the
assertion marked with wsp:optional will appear in one of the
alternatives.
I believe this approach does fit into
your view of the problem 3789, because it affects the vocabulary in
contrary to optional. I believe it is an extension to the provider-only
markup in proposal 3.
I am not in favor of Proposal 1.
--umit
________________________________
From: Sergey Beryozkin
[mailto:sergey.beryozkin@iona.com]
Sent: Monday, Nov 06, 2006 9:54 AM
To: Yalcinalp, Umit;
public-ws-policy@w3.org
Subject: Re: NEW ISSUE :Clarify usage of
assertions with no behavioral requirements on the requester
Hi Umit
Can you please give few simple examples
on how wsp:optional and wsp:include (targeting various types of
assertions) can be used at the same time...
Thanks, Sergey
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.
Received on Tuesday, 7 November 2006 14:34:04 UTC