RE: MOAP v2

On the question about the use of nested policy assertions we had discussed during the previous WG call, here are my thoughts:


*       Defining nested policies using the extension point in a parent policy doesn't work because extensions are ignorable whereas nested policy assertions (and the associated semantics) are not ignorable.

*       The policy attachment point is at the endpoint level.

o   When policies are defined at the endpoint level, the policy intersection algorithm allows matching the capabilities (of the client and the endpoint) and allows the client to engage the right behavior. That is, in Example 9-1, the security policy assertion and the EventSource policy assertions can be defined as siblings; this ensures that the client will use the right intersection of these policies to engage with the endpoint. The policies apply to all the operations supported by the endpoint.

*       Operation is not an attachment point for policies

o   If the intent in Example 9-1 is to describe operation level policies, that is, application of policies scoped to a specific operation, it cannot be supported using the general policy mechanism, since it does not allow operation as an attachment point for policies.

*       If the intent is NOT to define a nested policy assertion (as Ashok described earlier), then it can be done using a policy parameter (of the parent policy) that wraps the collection of inner policies.

Thanks.

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Tuesday, February 23, 2010 11:45 AM
To: public-ws-resource-access@w3.org
Subject: MOAP v2


All,
  after several rounds of talks between Oracle, Microsoft and IBM, the latest version of MOAP can be found here: http://www.w3.org/2002/ws/ra/10/02/MOAPv2.zip

The zip file contains all proposed spec changes and the changes include:

WS-EVD: no changes since last time

WS-Eventing/Enum/Frag/Transfer - look for edits done by "Dugv5":
- Only minor wordsmithing/editing to the definitions of the assertions

WS-MEX:
- there are two MEX docs in the zip file.
- the v1 version is the one sent to the WG a few weeks ago - no new edits were made.
- the v6 version contains all of the edits since v1.  All v1 edits were "accepted" so it should be easy to see the diff from v1.
- the edits were done in stages so that's why you'll see several Dugv? names.  It wasn't until round 4 of edits that I remembered to change the user name.

The MEX edits include:
- lots of minor editorial tweaks
- there's a new Terminology section.  This was added because it was felt that the two roles ('service endpoint' and 'metadata resource') needed to be defined and clarified.  People should read/review this carefully.
- the assertion was modified to advertise whether GetMetadata is supported - and the Dialect/Content params are now under GetMetadataSupported.
- there's a new section 12 about Bootstrapping.  This section was added to pretty much put all of the various pieces of the puzzle together when trying to bootstrap the process of talking to an endpoint.
- updated the xsd/wsdl for GetWSDL

Note: I'm planning on moving section 5 before section 4.  This will make it so that we define the new mex:Metadata type before we use it.  I didn't move it in the doc because then it would show up as modified.

Outstanding MEX issues for the WG to discuss:
- Example 8-5 - see comments in the doc
- Example 12-1 - see comment in the doc

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.