Re: Possible v.next issue : simple policy language extension

Hi

The idea is that something like

<wsp:PolicyAssertion namespace="http://purl.org/atompub/features/1.0/supportsDraft"/>

is a standalone primitive assertion which in this case claims that a 
given policy subject supports a 'Draft' capability.

As I said, I believe the way one can express primitive assertions today, using a compact form, is good.
It's compact enough and Policy operator is much richer than just as an assertions container.
Also I don't feel accepting this proposal (in v.next) will make much difference to the idea of using a WS-Policy vocabulary as the uniform vocabulary for dealing with policies.

What kind of attracts me in something like 

<wsp:PolicyAssertion asserts="http://purl.org/atompub/features/1.0/supportsDraft"/>

is that it sort of eliminates in some cases the need for dealing with new schemas required for creating primitive assertions.
For ex, lets take the (old) wsa:UsingAddressing policy assertion.
One needs to create a UsingAddressing element in the schema for http://www.w3.org/2005/08/addressing, in order be able to express such a capability. This is good in that it facilitates the validation, but for primitive assertions no much validation is needed, spelling needs to be checked only.
Another thing is that it seems some policy authors might be attracted to the idea of just asserting the policies by using simple strings. It might make the process of associating capabilities with arbitrary xml documents simplier in that no retrievals will be needed to resolve the policy references, especially when inlining is not preferred.

In simple cases operators like this one might eliminate the need for using a policy engine at all, simple string comparisons might do.

One thing though is that I'm not quite comfortable with the normalization hack I've suggested :
1. If PolicyAssertion is found then assume that the value of "asserts" attribute will qualify the local
PolicyAssertion name :

<wsp:PolicyAssertion asserts="http://purl.org/atompub/features/1.0/supportsDraft"/>

==>
<wsp:Policy>
<ns:PolicyAssertion xmlns:ns="http://purl.org/atompub/features/1.0/supportsDraft"/>
</wsp:Policy>

that is, we have 
a unique qualified {http://purl.org/atompub/features/1.0/supportsDraft}PolicyAssertion policy assertion type.

It seems like a hack, not sure about it. Perhaps there's a cleaner trick which can be done. Neither I'm not sure about other possible sideefects of introducing such an operator.

So, if someone sees an extension like this might be of any future use then lets create a v.next issue. I'm not planning to open any bugs to track this issue nor will I insist on putting it on the (concall) agenda. If not then, as I said, I feel the absence of such an operator won't affect the overall utility of a WS-Policy language as a uniform format for dealing with policies. 

Thanks, Sergey


> Sergey, is this a reference to a single assertion?
> 
> Ashok
> 
> Sergey Beryozkin wrote:
> 
>> Hi
>>  
>> I'd like to suggest a possible simple policy language extension for 
>> the *next version* of WS-Policy.
>> Please consider this request as a low-priority issue, I don't want to 
>> distract the working group from more important/urgent things it needs 
>> to finalize. If the groups find this suggestion of any interest then 
>> the only thing I'd expect is a list of v.next issues be updated.
>>  
>> So here it goes. If a policy author wants to express the simplies 
>> capability/requirement, the most compact way to do it is to use a 
>> compact form, for ex :
>>  
>> <Policy>
>>  <wsm:MTOM/>
>> </Policy>
>>  
>> I personally have no problems with it at all, it's compact enough for 
>> me and a Policy operaror provides for more than just serving as a 
>> simple container about the primitive (<wsm:MTOM/>) policy assertion.
>>  
>> Now, I've had a look recently at APP Feature Discovery Draft [1].
>> According to the draft one can express a capability like this :
>>  
>> <f:feature xmlns:f="http://purl.org/atompub/features/1.0"
>>              ref="http://purl.org/atompub/features/1.0/supportsDraft" />
>> />
>>  
>> I think it's kind of neat. It's simple and compact. It reminds me of 
>> those SAX properties.
>>  
>> I don't think one can express primitive assertions the same compcat 
>> way using a WS-Policy language.
>> I don't see it a language limitation but at the same time it seems it 
>> would be good if one could go as compact
>> as suggested in the Atom draft[1] using the policy language.
>>  
>> The language has a PolicyReference (and PolicyURIs attribute) but I 
>> believe its semantics require the policy engine to dereference the 
>> reference.
>>  
>> So what about introducing, say, a top-level element <PolicyAssertion>.
>> It can be used like this, compact form:
>>  
>> <wsp:PolicyAssertion 
>> namespace="http://purl.org/atompub/features/1.0/supportsDraft"
>>          xmlns:wsp="http://www.w3.org/ns/ws-policy 
>> <http://www.w3.org/ns/ws-policy%22/>"/ 
>> <http://www.w3.org/ns/ws-policy%22/>>
>>  
>> Normalization :
>>  
>> <Policy>
>>    <ExactlyOnce>
>>        <All>
>>           <ns:PolicyAssertion 
>> xmlns:ns="http://purl.org/atompub/features/1.0/supportsDraft 
>> <http://purl.org/atompub/features/1.0/supportsDraft%22/>"/ 
>> <http://purl.org/atompub/features/1.0/supportsDraft%22/>>
>>        </All>
>>    </ExactlyOnce>
>> </Policy>
>>  
>> Similarly, a top level Policy(Assertion) attribute is introduced :
>>  
>> <atom:collection 
>> wsp:PolicyAssertion="http://sberyozkin.blogspot.com/2007/09/atom-and-ws-policy.html"/>,
>> normalization rules are the same.
>>  
>> What can it give :
>> * more compact way to express simple primitive assertions
>>  
>> The normalization rule may seem like a hack, not sure about it. 
>> Perhaps saying that PolicyReference does not always have to be 
>> dereferenced may do the trick.
>>  
>> Does it make any sense to anyone ?
>>  
>> This message is not driven by any internal requirements, and I'm not 
>> expecting any support for it, but I'd just like experts's opinion on 
>> this proposal for the next version of the spec.
>>  
>> I've tried to motivate it all at [2]
>>  
>> Cheers, Sergey
>>  
>> [1] http://tools.ietf.org/html/draft-snell-atompub-feature-10
>> [2] http://sberyozkin.blogspot.com/2007/09/atom-and-ws-policy.html
>>
>>----------------------------
>>IONA Technologies PLC (registered in Ireland)
>>Registered Number: 171387
>>Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>>  
>>
> 
> 
> -- 
> All the best, Ashok

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland