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

Hi Asir

Thanks, it'a good example for this discussion.

"Let's consider a slightly different example. Say provider X has an open privacy policy (X collects personal information and sells 
them). Provider X uses a policy assertion Y to advertise this behavior. Requestor Z doesn't understand assertion Y.

I can't think of a reason why requestor Z should interact with provider X."

I think in this case providers adverizing this assertion will have to follow some rules, specifically, it must not mark this as 
optional as optional. Presumably, this assertion's documentation will state that everyone wishing to use must not mark this 
assertion as being optional.

<oasis:Replicatable/> is different. For this kind of assertion, there's no reason why a requester which does not understand what it 
means should not intercat with it...

Agree ?

So it depends on what kind of assertion it is.

>> marking assertions like <oasis:Replicatable/> with
>> wsp:optional is considered to be a wrong approach.
> Agree.

I proposed that the wording for wsp:optional be updated so that it was acceptable to mark
assertions like <oasis:Replicatable/> with wsp:optional :

http://lists.w3.org/Archives/Public/public-ws-policy/2006Oct/0113.html

Cheers, Sergey


> it's important to ensure
> policy-aware clients which have no knowledge
> of these assertions can proceed
> consuming the service advertsing this assertion.

I'd like to understand this case better.

Let's consider a slightly different example. Say provider X has an open privacy policy (X collects personal information and sells 
them). Provider X uses a policy assertion Y to advertise this behavior. Requestor Z doesn't understand assertion Y.

I can't think of a reason why requestor Z should interact with provider X.

> marking assertions like <oasis:Replicatable/> with
> wsp:optional is considered to be a wrong approach.

Agree.

Regards,

Asir S Vedamuthu
Microsoft Corporation




From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
Sent: Wednesday, October 04, 2006 2:15 AM
To: public-ws-policy@w3.org
Subject: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requeste

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3789

Target : WS-Policy Framework and policy guidelines

Justification :

There's a class of policy assertions which have no behavioral requirements on the requester but can be still usefully processed by
requesters which are aware
of what assertions mean.
For example : <oasis:Replicatable/>

An assertion like this one can be a useful source of information for requesters. Providers having expected properties like
<oasis:Replicatable/> can be chosen/searched.
At the same time, given the fact assertions like <oasis:Replicatable/>
have no behavioral requirements on the provider it's important to ensure
policy-aware clients which have no knowledge of these assertions can proceed
consuming the service advertsing this assertion.

Currently the way to advertise such an assertion is to use a normal form with two policy alternatives(simple case), with only one
alternative containing this assertion thus making it optional, or, in other words, giving a chance to requesters to ignore it.
Such normal form expression is equivalent to a compact form with the optional assertion marked with wsp:optional attribute with a
value 'true'.

However, at the moment the primer recommends using wsp:optional when one needs to mark asssertions which identify optional
capabilities/requirements with behavioral requirements on a requester should the requester wishes to use it.

Thus marking assertions like <oasis:Replicatable/> with wsp:optional is considered to be a wrong approach.

Proposal :

Clarify the text describing the optionality in the policy guidelines and in the Framework spec on how a policy author should use
assertions like
<oasis:Replicatable/>.
It's important that assertions like these can be usefully interpreted by knowledgeble requesters and safely ignored by requesters
unaware of them.

Received on Wednesday, 18 October 2006 16:25:46 UTC