W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > May 2009

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

From: Gilbert Pilz <gilbert.pilz@oracle.com>
Date: Fri, 15 May 2009 12:28:01 -0700
Message-ID: <4A0DC241.4000202@oracle.com>
To: Bob Freund <bob@freunds.com>
CC: Yves Lafon <ylafon@w3.org>, Doug Davis <dug@us.ibm.com>, Geoff Bullen <Geoff.Bullen@microsoft.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>

Your idea sounds interesting but I don't think I completely understand 
it. What do you mean by "alternative discrimination using policy syntax"?

- gp

On 5/15/2009 3:05 AM, Bob Freund wrote:
> 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

Received on Friday, 15 May 2009 19:28:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:49 UTC