RE: NEW ISSUE :Clarify usage of assertions with no behavioral r equirements on the requeste

Hi Ashok et al,

 

  _____  

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Ashok Malhotra
Sent: Friday, October 06, 2006 3:51 PM
To: Paul Cotton; Sergey Beryozkin; public-ws-policy@w3.org
Subject: RE: NEW ISSUE :Clarify usage of assertions with no behavioral
requirements on the requeste

 

I'm sorry, but I disagree with this direction.  wsp:Optional is orthogonal
to assertions that

that have no behavioral requirements (or do not affect the wire format).

 

PY>I agree with this.

 

wsp:Optional is used to indicate that an assertion may or may not be used.
For assertions

that do not affect the wire format this has no meaning.  

PY> I agree with the 1st sentence but not the 2nd.  I don't think we can
make a blanket statement that it has no applicability (meaning).

That depends IMO. Marking assertions "optional" makes sense for some and for
others it would not, based on the nature of the assertion itself, orthogonal
to, if it has wire manifestations or not (as you stated in your 1st
paragraph above).

 

These assertions are in some sense

just advertising.  The provider says "I will keep yr information
confidential" -- well fine, but how

would Optional apply to such an assertion or, more strongly, make sense with
such an assertion.

Would you want two alternatives that say keep it confidential and don't keep
it confidential?

OK.  If you want that you can say that but that has no relation to whether
the assertion impacts

the wire format or not.

 

I support an attribute that marks such assertions as "non-operational" and
so takes them out 

of the intersection algorithm.  This would simplify policy processing.

 

PY>I agree that it would be useful to have a flag such as "wsp:advisory" /
"wsp:ignorable" to mark such assertions that the interacting party side can
safely ignore (and factor out of intersection algorithm etc.). 

 

Regards,

Prasad

All the best, Ashok 

 

 


  _____  


From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Paul Cotton
Sent: Friday, October 06, 2006 10:57 AM
To: Sergey Beryozkin; public-ws-policy@w3.org
Subject: RE: NEW ISSUE :Clarify usage of assertions with no behavioral
requirements on the requeste

>1. Add an example to a primer and/or policy guidelines 

 

Can you formulate your required example even in outline form?

 

>2. Explain why policy authors should make such assertions optional for
those requesters which are not aware of them.

 

I assume you want this text in the primer and/or guidelines doc.  Is that
correct?

 

If so can you offer proposed text?

 

> 3. Make any necessary changes to the wsp:optional related wording so that
a policy author can use wsp:optional as a recognized but not a workaround
way to mark such assertions.

 

Can you please clarify what you mean by "so that a policy author can use
wsp:optional as a recognized but not a workaround to mark such assertions"?

 

Are you saying the Framework should warn policy assertion authors from using
wsp:optional to describe "assertions with no behavioural requirements on the
requester"?

 

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (613) 225-5445 Fax: (425) 936-7329
mailto:Paul.Cotton@microsoft.com <mailto:Paul.Cotton@microsoft.com> 





  _____  


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

 

Hello,

 

This is the resolution I think would adequately address this issue :

 

1. Add an example to a primer and/or policy guidelines
2. Explain why policy authors should make such assertions optional for those
requesters which are not aware of them. 
3. Make any necessary changes to the wsp:optional related wording so that a
policy author can use wsp:optional as a recognized but not a workaround way
to mark such assertions.

 

Thanks, Sergey

 

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3789
<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 Monday, 9 October 2006 18:44:20 UTC