- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Thu, 10 May 2007 21:31:53 -0400
- To: "David Orchard" <dorchard@bea.com>
- Cc: public-ws-policy@w3.org, public-ws-policy-request@w3.org
- Message-ID: <OF5DF798E0.EAE2DBF2-ON852572D8.0005F6F5-852572D8.00084F20@us.ibm.com>
Please see my comments inlined below. Cheers, Christopher Ferris STSM, Software Group Standards Strategy email: chrisfer@us.ibm.com blog: http://www.ibm.com/developerworks/blogs/page/chrisferris phone: +1 508 377 9295 public-ws-policy-request@w3.org wrote on 05/10/2007 05:10:31 PM: > > Here's my revised estimate of the positions: > > Overview > There are roughly 3 positions that may be taken on the issue of the > meaning of assertions in alternative(s). > > 1. AIN Vocabulary flavour: > Any behaviour not implied by an assertion that is in a vocabulary should > not be applied (Roughly original chris proposal) > > No proponents. No further elaboration planned. > > 2. AIN Closed world flavour (revised MSFT/IBM proposal): > Any behaviour not implied by an alternative must not be applied. Any > behaviors implied by assertions in an alternative must be applied. > > Questions: > 1. Is it OK to omit Ignorable="true" Assertion? Ignorable is ignorable by definition. It is expected that Ignorable has no manifestation in the context of the exchange. So, yes, if the Intersection was performed in lax mode, it is therefore included in the Intersection result. Since it is Ignorable, it can be safely ignored. If Ignorable is mis-used, and applied to an assertion that in fact does manifest itself in the interchange, then it may, or may not be applied at the discretion of the initiator of the interchange governed by that alternative (although the correct policy expression in this case would have been to mark it as wsp:Optional=true... see below) > 2. Is it OK to omit Optional="true" Assertion? By definition, there is no such thing in the data model or in the normal form of a policy. wsp:Optional=true on an assertion manifests itself in the data model and in normal form as two distinct alternatives, one with, and one without that assertion. If Intersection yields an alternative that does not include the assertion marked as wsp:Optional=true in the compact form of a policy expression, then by definition, it is not to be applied. If Intersection yields an alternative that includes the assertion marked as wsp:Optional=true > > Pros > This ensures that a provider will provide a "complete" description of > the behaviors and thus guarantee interop including optional/ignorable. I wouldn't say guarantee, but it will certainly help improve matters. > > Cons > Pending questions, may limit providers ability to apply behaviors. I don't understand these limits to which you allude. > > 3. AIN Removal (open world): > Any behaviour not implied by any assertions in an alternative may or may > not be applied. Any behaviors implied by assertions in an alternative > must be applied. > > Pros > Perception of "simpler" specification. Allows service fuller control > over application of behaviors. You haven't justified this, IMO. How does it allow the service more complete control? Control over what? Do you mean service provider or consumer? > > Cons > Provider might not provide "complete" description. Interop is > guaranteed but optional and/or ignorable behaviors may be missed by > clients. Huh? How so? See above. If I mark an assertion as Ignorable=true, then by definition it is ignorable. It is intended that it not be manifested in the interaction. It is there as an advertisement that the implied behavior is being performed regardless (by which ever entity publishes the alternative that includes the assertion). Optional is defined as described above. Depending upon which of the alternatives is compatible with the opposing endpoint's policy, either the behavior is applied (because it is IN the intersected alternative) or it is not applied (because it is absent from the intersected alternative). > > Cheers, > Dave >
Received on Friday, 11 May 2007 01:32:10 UTC