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

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

From: Bob Freund <bob@freunds.com>
Date: Fri, 15 May 2009 06:05:12 -0400
Cc: Gilbert Pilz <gilbert.pilz@oracle.com>, Doug Davis <dug@us.ibm.com>, Geoff Bullen <Geoff.Bullen@microsoft.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-Id: <E1F3CBB6-A670-408C-AEFD-ADFF6780A3C2@freunds.com>
To: Yves Lafon <ylafon@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



Received on Friday, 15 May 2009 10:05:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:00 GMT