Re: [issue 6432] - when is a policy not a policy?

Bob,

Seems to me that the "fears" are unfounded. A device can publish an 
already normalized policy expression
with a single alternative. Most sensor devices would be service endpoints, 
given an HTTP substrate, and hence 
none of the complexities of policy intersection etc need be implemented on 
those constrained devices.
In the context of handheld devices that might serve in the client role, 
our experience in implementing
policy normalization and intersection is such that it is not significant 
(though normalization requires 
recursion).

The WS-Policy WG produced a spec [1] that allows policy to be attached in 
a number of useful manners,
including by reference to a URI (@wsp:PolicyURIs attribute). Note that 
there is NOTHING that precludes
an implementation from treating a "well known policy URI" in a manner 
similar to the manner in which 
@mode is used today. The WS-Policy spec says NOTHING about how policy 
expressions are used in the
context of a runtime.

Hence, you could have a REAL policy (that COULD be processed and yield 
meaningful results) as the
resource identified by a well known URI. Those implementations that 
short-cut policy intersection
by simply comparing the URIs of the server and client policy expressions 
can hard-code the behavior.
Meanwhile, more dynamic client participants can leverage the full breadth 
of WS-Policy, all using the
same feature. Everyone wins.

[1] http://www.w3.org/TR/ws-policy-attach/

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986





From:
Bob Freund <bob@freunds.com>
To:
Yves Lafon <ylafon@w3.org>
Cc:
Gilbert Pilz <gilbert.pilz@oracle.com>, Doug Davis/Raleigh/IBM@IBMUS, 
Geoff Bullen <Geoff.Bullen@microsoft.com>, 
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Date:
05/15/2009 06:10 AM
Subject:
Re: [issue 6432] - when is a policy not a policy?
Sent by:
public-ws-resource-access-request@w3.org



Some thoughts about working-in policy:
Policy seems to be useful and flexible for negotiating behavior, but 
it seems to me that it scares device people due to some of that 
flexibility, such as normalization, nested assertions, optional, 
ignorable, and so-forth.  on the other hand, mode today seems to work 
a bit like a policy-style implementation (forgetting about fault 
behavior for a bit and forgive me while I squint) like policy metadata 
with a single alternative.  It is not really a whole policy 
implementation if all you have to do is sort through a list of simple 
alternatives, like one might with the current mode optional fault 
behavior that lists the modes supported.

Perhaps it might be possible to define a method of alternative 
discrimination using policy syntax that would be just natural for the 
large deployment users, but provide profiling guidance for the device 
end of the market so that all they need to worry about is to sort 
through a list of qnames for a method they support.

Maybe it is not like having your cake and eating it too, but we might 
offer a full-fat version as well as a lite version for those at 
opposite ends of the spectrum.

How to deal with mode then?

Maybe it goes back to delivery being just a compatibility-use of an 
extensibility point.  Eventing might not have to define fault behavior 
for a mode attribute that might be contained in that extensibility 
point.  It might be done though in a primmer , an appendix, a related 
spec o even a WG note.

If we followed that path, then current users would see a mostly- 
compatible bridge, new implementers would have full use of policy, and 
smal end sers would be able to use the abridged policy method in the 
future.

thanks
-bob