Bob, 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