W3C home > Mailing lists > Public > public-ws-policy@w3.org > May 2007

RE: AIN, NOBI and composition

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Thu, 10 May 2007 07:47:29 -0400
To: Daniel Roth <Daniel.Roth@microsoft.com>
Cc: Ashok Malhotra <ashok.malhotra@oracle.com>, David Orchard <dorchard@bea.com>, "public-ws-policy@w3.org" <public-ws-policy@w3.org>, public-ws-policy-request@w3.org
Message-ID: <OFCBA04876.662DE1DD-ON852572D7.003B0478-852572D7.0040AB40@us.ibm.com>
+1

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/09/2007 03:14:52 PM:

> 
> We think these sentences are different.  Let me try to explain using
> Dave's RSPAssertion example.
> 
> The RSPAssertion maps to two behaviors: (RM, Security)
> The RMAssertion maps to one behavior: (RM)
> 
> OK, so based on the two sentences below, what does the following 
> policy mean?  What behaviors does the policy subject require?:
> 
> <Policy><RSPAssertion/></Policy>
> 
> The first sentence says that the policy means the policy subject 
> requires (RM, Security).  Full stop.
> 
> The second sentence says that the policy means the policy subject 
> requires (RM, Security, NOT(RM), NOT(Addressing), NOT(MTOM), ... etc
> for all absent assertions)
> 
> The second sentence results in a very confusing situation: What does
> it mean to do RM and NOT(RM)?  Does the absence of the RMAssertion 
> cancel out the RM-ness of the RSPAssertion?  Is the policy self-
> contradicting?  This is definitely not the semantic we want for 
> policy alternatives.
> 
> The first sentence results in a clear and simple interpretation of 
> the policy and its alternatives.
> 
> Daniel Roth
> 
> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com]
> Sent: Wednesday, May 09, 2007 9:24 AM
> To: Daniel Roth; Ashok Malhotra; public-ws-policy@w3.org
> Subject: RE: AIN, NOBI and composition
> 
> We continue to talk past each other.  I think the following two
> sentences are equivalent:
> "No behaviors are to be applied for the alternative other than the
> behaviors specified by the assertions in the alternative"
> "The absence of an assertion means that the behaviour specified by the
> absent assertion should not be applied".
> 
> Cheers,
> Dave
> 
> > -----Original Message-----
> > From: Daniel Roth [mailto:Daniel.Roth@microsoft.com]
> > Sent: Tuesday, May 08, 2007 4:52 PM
> > To: David Orchard; Ashok Malhotra; public-ws-policy@w3.org
> > Subject: RE: AIN, NOBI and composition
> >
> > > AIN Closed flavour: Any assertion not in an alternative
> > should not be
> > > applied (revised chris proposal)
> >
> > Chris' revised proposal doesn't say anything about the
> > absence of assertions.  It simply says that no behaviors are
> > to be applied for the alternative other than the behaviors
> > specified by the assertions in the alternative.
> >
> > Daniel Roth
> >
> > -----Original Message-----
> > From: David Orchard [mailto:dorchard@bea.com]
> > Sent: Tuesday, May 08, 2007 4:42 PM
> > To: Ashok Malhotra; Daniel Roth; public-ws-policy@w3.org
> > Subject: RE: AIN, NOBI and composition
> >
> > Well, I think we need to have clear wording for all the "alternatives"
> > before the working group.
> >
> > The way I see it:
> > AIN Vocabulary flavour: Any assertion not in a vocabulary
> > should not be applied (Original chris proposal) AIN Closed
> > favour: Any assertion not in an alternative should not be
> > applied (revised chris proposal) AIN Removal: Any assertion
> > not in alternative means nothing.  It may or may not be applied.
> >
> > Cheers,
> > Dave
> >
> > > -----Original Message-----
> > > From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
> > > Sent: Tuesday, May 08, 2007 4:29 PM
> > > To: Daniel Roth; David Orchard; public-ws-policy@w3.org
> > > Subject: RE: AIN, NOBI and composition
> > >
> > > Dan:
> > > I'm sorry, but that's not how I read it.
> > >
> > > My reading is that you CANNOT apply assertions that are not in the
> > > selected alternative.  That, to me feels like negation.
> > >
> > > I think we shd get behind Monica's explicit wording that eliminates
> > > the fuzz factor.
> > >
> > > All the best, Ashok
> > >
> > > > -----Original Message-----
> > > > From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> > > > request@w3.org] On Behalf Of Daniel Roth
> > > > Sent: Tuesday, May 08, 2007 4:12 PM
> > > > To: David Orchard; public-ws-policy@w3.org
> > > > Subject: RE: AIN, NOBI and composition
> > > >
> > > >
> > > > This is exactly the problem with tying negation semantics to the
> > > > absence of assertion types (AIN).
> > > >
> > > > IBM's proposal fixes this by simply saying you do what you
> > > assert and
> > > > nothing else (NOBI).
> > > >
> > > > Daniel Roth
> > > >
> > > > -----Original Message-----
> > > > From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> > > > request@w3.org] On Behalf Of David Orchard
> > > > Sent: Tuesday, May 08, 2007 3:23 PM
> > > > To: public-ws-policy@w3.org
> > > > Subject: AIN, NOBI and composition
> > > >
> > > >
> > > > I wonder about AIN, NOBI, etc. and composition.
> > > >
> > > > Imagine that WS-I produces an assertion that says a "RSPAssertion"
> > > > means RMAssertion and Security, perhaps exactly one of
> > > > messageSecurity|transportsecurity.  What's the meaning
> > when some of
> > > > messageSecurity|the
> > > > assertions that are in the composition are missing?  For
> > example, I
> > > > just say RSPAssertion.  I don't say RMAssertion, though
> > > RMAssertion is
> > > > in the vocabulary.  If I get an intersection that says
> > RSPAssertion
> > > > but not RMAssertion, AIN has the implication that you
> > > shouldn't apply
> > > > RMAssertion yet RSPAssertion does.
> > > >
> > > > We don't say anything about whether an assertion that means a
> > > > behaviour "trumps" the lack of such an assertion.
> > > >
> > > > With AIN, there's a problem.  Without AIN, there's no
> > > problem because
> > > > there's no conflict.
> > > >
> > > > Cheers,
> > > > Dav3e
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> 
Received on Thursday, 10 May 2007 11:47:52 UTC

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