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

Chris,
Could you provide a concrete example of what you are suggesting, please?  Perhaps the XML of a subscribe message?
Thanks
Geoff


From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Friday, May 15, 2009 5:00 AM
To: Bob Freund
Cc: Doug Davis; Geoff Bullen; Gilbert Pilz; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org; Yves Lafon
Subject: 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