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

The change in 3.1.1 sounds good to me. I don't have strong feelings about the examples, I'm open to changes there.

-----Original Message-----
From: Tom Rutt [mailto:tom@coastin.com]
Sent: Tuesday, March 27, 2007 3:37 PM
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 16:58:57 UTC