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 UTC