W3C home > Mailing lists > Public > public-ws-addressing@w3.org > April 2007

Re: Policy alternatives, negation, [Non]AnonResponse assertion and the none URI

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Mon, 16 Apr 2007 14:49:09 -0700
Message-ID: <4623EF55.70800@oracle.com>
To: Paul Fremantle <pzfreo@gmail.com>
CC: "Rogers, Tony" <Tony.Rogers@ca.com>, public-ws-addressing@w3.org

Paul Fremantle wrote:
> Anish
> 
> I think you are making a logical mistake by associating the
> acceptability of the none with those assertions. The mistake you are
> making can be better explained with some analogous logic.
> 

I don't think I'm doing that. You are assuming that the assertions are 
only about anon and non-anon uris. They are not defined that way. The 
assertions talk about that fact that making that assertion => none uris 
must be accepted.

> If I state that it is not true that Paul likes cheese, you can't infer
> anything about whether I like chocolate!
> 
> In other words neither assertion should state anything about the
> acceptability of the none replyto. That should be stated elsewhere.
> 

My point is that the assertions currently do. If they hadn't I would not 
have raised this issue.

To use your analogy, the assertion says:
Paul likes cheese and paul likes chocolate.

There was a discussion about this where folks said that negation of that 
means 'paul does not like cheese' and I'm merely pointing out that if 
negation means paul does not like cheese then it has to mean that paul 
does not like chocolate as well.

BTW, it is not clear what 'negation' means here. The ws-policy spec IMHO 
is very ambiguous about this.

BTW2, why don't you like coffee? ;-)

> Paul
> 
> 
> 
> On 4/16/07, Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote:
>>
>> Rogers, Tony wrote:
>> > I believe we have always intended that the "none" URI is acceptable for
>> > any response EPR.
>> >
>>
>> That is exactly the issue. Because of this, the assertions become
>> overlapping. When one brings in the negation effect because of
>> alternatives, this results in self-contradiction.
>>
>> -Anish
>> -- 
>>
>> > I wonder if we need another assertion to state that the "none" URI is
>> > explicitly not allowed? I'd strongly prefer that it be an assertion 
>> that
>> > "none" is NOT acceptable, rather than have an assertion that it was
>> > acceptable (because it is permitted all the time at the moment). 
>> Then if
>> > you specify AnonResponse + NoneUnacceptable you would be insisting upon
>> > the Anon URI (because the None URI is forbidden).
>> >
>> > Why do I think I may regret asking this question?
>> >
>> > Tony Rogers
>> > CA, Inc
>> > Senior Architect, Development
>> > tony.rogers@ca.com <mailto:tony.rogers@ca.com>
>> > co-chair UDDI TC at OASIS
>> > co-chair WS-Desc WG at W3C
>> >
>> > 
>> ------------------------------------------------------------------------
>> > *From:* public-ws-addressing-request@w3.org on behalf of Anish 
>> Karmarkar
>> > *Sent:* Mon 16-Apr-07 12:55
>> > *To:* public-ws-addressing@w3.org
>> > *Subject:* Policy alternatives, negation, [Non]AnonResponse assertion
>> > and the none URI
>> >
>> >
>> > There is view among the WS-Policy wonks (not sure how widely accepted
>> > this is or whether the WS-Policy specs explicitly calls this out) that
>> > when there are alternatives present and the selected alternative does
>> > not contain an assertion X but another alternative does, then the 
>> effect
>> >   of such a selection consists of negation of X.
>> >
>> > We have two assertions AnonResponse and NonAnonResponse assertions. 
>> Both
>> > of them require that the 'none' URI be allowed for the response EPR.
>> > Does that mean that negation of any of these implies 'none' must not be
>> > used?
>> >
>> > If so, that is a problem, none is useful for things like one-way
>> > operations that don't use the response EPR for that MEP.
>> >
>> > Additionally, if one has two alternatives one with AnonResponse only 
>> and
>> > one with NonAnonResponse only, then that would be self-contradictory.
>> >
>> > -Anish
>> > --
>> >
>> >
>> >
>>
>>
>>
> 
> 
Received on Monday, 16 April 2007 21:50:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:17 GMT