RE: New Alternative G to resolve LC comment on WS addr metadata

Yes, I think we should retain mention that the qualifying assertions are nested. So I prefer Tom's text.

-----Original Message-----
From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
Sent: Tuesday, March 27, 2007 4:19 PM
To: tom@coastin.com; Marc Goodner
Cc: public-ws-addressing@w3.org
Subject: RE: New Alternative G to resolve LC comment on WS addr metadata

Or, perhaps even simpler (for 3.1.1):

"The wsam:Addressing assertion indicates that there are no restrictions
on the use of WS-Addressing unless qualified by nested policy
assertions."

Or do we worry that this doesn't say that the qualifying assertions are
nested inside it?


Tony Rogers
tony.rogers@ca.com

-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Tom Rutt
Sent: Wednesday, 28 March 2007 8:37
To: Marc Goodner
Cc: public-ws-addressing@w3.org
Subject: Re: New Alternative G to resolve LC comment on WS addr metadata


I am now leaning toward alternative G, because it is more concise for
typical response sender endpoint claims. However I recommend the
following changes to the attached PDF prpoposal, from Marc, for clariity
of exposition and example.



3.1.1 sentence 3 is convoluted:

Change:
"
The wsam:Addressing assertion does not indicate any restrictions on the
use of WS-Addressing unless otherwise qualified by assertions in its
nested policy expression.
"

To (reads better and is more direct in its statement) " The
wsam:Addressing assertion indicates that there are no restrictions on
the use of WS-Addressing, unless otherwise qualified by assertions in
its nested policy expression.
"


Examples in section 3.1.6:

The examples are not realistic. The examples for proposal F are more
representative of actual support requirements a Client might be looking
for.

It is better to for proposal G to recast the same examples from the
proposal F .

Change:
"
Consider the following example, where we have a client who does not care
whether the endpoint explicitly requires anonymous responses, and a WSDL
which states that the endpoint does explicitly require anonymous
responses.
Example 3-7. Client looking for an endpoint which supports Addressing,
WSDL states explicit requirement for anonymous responses <wsp:Policy>
<wsam:Addressing> <wsp:Policy/> </wsam:Addressing> </wsp:Policy> The
client's policy (above) states the requirement for Addressing, but no
requirement for explicit support of responses.
<wsp:Policy>
<wsam:Addressing>
<wsp:Policy>
<wsam:AnonymousResponses/>
</wsp:Policy>
</wsam:Addressing>
</wsp:Policy>
The policy attached to the endpoint in the WSDL (above) requires
explicit support for anonymous responses. The intersection of this
policy with the client's policy will be empty, so the client will miss a
compatible endpoint.
<wsp:Policy>
<wsam:Addressing>
<wsp:Policy>
<wsam:AnonymousResponses wsp:Optional="true"/> </wsp:Policy>
</wsam:Addressing> </wsp:Policy> This is what the client's policy could
be; by stating that the wsam:AnonymousResponses assertion is optional,
there will be a non-empty intersection with endpoint policies that do
and do not contain this assertion.

strict intersection. The strict intersection of this policy with the
client's policy will still be empty. The lax intersection, on the other
hand, will not be empty, so the client will find a compatible endpoint.
These two
This example shows the use of wsp:Optional, and how it can be used to
produce non-empty intersections between client and endpoint policies.
For more detailed descriptions of the use of wsp:Optional,
wsp:Ignorable, and strict and lax intersection, please refer to the
WS-Policy Primer [WS Policy 1.5 - Primer].
"

To:
"
Example 3-7. Client looking for an endpoint which supports Addressing,
and which supports anonymous responses <wsp:Policy> <wsp:ExactlyOne>
<wsp:All> <wsam:Addressing> <wsp:Policy> <wsp:ExactlyOne> <wsp:All>
<AnonymousResponses Optional="true"/> </wsp:All> </wsp:ExactlyOne>
</wsp:Policy> </wsam:Addressing> </wsp:All> </wsp:ExactlyOne>
</wsp:Policy>

Example 3-8. Client looking for an endpoint which supports Addressing,
and does not require support for responses (will intersect with
anything) <wsp:Policy> <wsp:ExactlyOne> <wsp:All> <wsam:Addressing> <--
supports all response types --> <wsp:Policy> </wsp:Policy>
</wsam:Addressing> </wsp:All> <wsp:All> <wsam:Addressing> <-- requires
Anonymous responses --> <wsp:Policy> <wsp:ExactlyOne> <wsp:All>
<AnonymousResponses /> </wsp:All> </wsp:ExactlyOne> </wsp:Policy>
</wsam:Addressing> </wsp:All> <wsp:All> <wsam:Addressing> <- requires
nonAnonymous responses --> <wsp:Policy> <wsp:ExactlyOne> <wsp:All>
<NonAnonymousResponses /> </wsp:All> </wsp:ExactlyOne> </wsp:Policy>
</wsam:Addressing> </wsp:All> </wsp:ExactlyOne> </wsp:Policy>

For more detailed descriptions of the use of wsp:Optional,
wsp:Ignorable, and strict and lax intersection, please refer to the
WS-Policy Primer [WS Policy 1.5 - Primer].
"



Marc Goodner wrote:
>
> I agree with Tom that nested expressions is the way we should go to
> resolve this issue. We've been working on a slightly different variant

> to handle this that is attached.
>
> It proposes the following changes:
> 1. States that the Addressing assertion applies to the endpoint
> subject 2. Prohibits abstract (interface/portType) attachment points
> 3. The Addressing assertion without any qualifiers (nested assertions)

> means that the use of WS-Addressing is required and has no
restrictions.
> 4. The AnonymousResponses and NonAnonymousResponses assertions
> indicate that anonymous or non-anonymous responses respectfully are
> required.
> 5. The AnonymousResponses and NonAnonymousResponses assertions cannot
> be used in the same alternative. There semantics conflict with each
> other.
> 6. Removes wsp:Ignorable example
> 7. Editorial work to clean up the examples to be consistent with the
> assertion semantics.
>
> This proposal has the following benefits
>
> * The simplest case (addressing is required and may be used without
> restrictions) is represented by just the Addressing assertion
>
> * The assertions express requirements as suggested by the WS-Policy WG
>
> * An endpoint can clearly indicate what response are and are not
> allowed
>
> * No new assertions added. A subject that requires mixed-mode
> responses can use the Addressing assertion with no qualifiers
>
> * Authoring policies that work with Intersection is straight-forward
> to do
>
> * The assertions compose well with other assertions that depend on
> addressing (ex. MakeConnection would be used in conjunction the
> Addressing assertion qualified by the NonAnonymousResponses assertion)
>

--
----------------------------------------------------
Tom Rutt        email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Monday, 2 April 2007 17:01:39 UTC