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

Hi Sergei,

 

If the assertion (capability) MUST be understood by the clients it must not
be marked "optional", otherwise it is marked with "optional=true".

Why would that not work, given the client still needs to understand what
<oasis:highlyAvailable/> means to make any sense of it?

 

Regards,

Prasad

 

  _____  

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
Sent: Tuesday, October 31, 2006 9:32 AM
To: Sergey Beryozkin; public-ws-policy@w3.org
Subject: Re: NEW ISSUE :Clarify usage of assertions with no behavioral
requirements on the requester

 

Hi

 

While the group is looking at what to do with wsp:local attribute, I'd also
appreciate some feedback on what a guideline/resoultion should be on
advertizing capabilities like

<oasis:highlyAvailable/>

 

Thanks, Sergey

----- Original Message ----- 

From: Sergey <mailto:sergey.beryozkin@iona.com>  Beryozkin 

To: public-ws-policy@w3.org <mailto:public-ws-policy@w3.org>  

Sent: Thursday, October 26, 2006 10:29 AM

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

 

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.