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

[Bug 4664] Proposal for AI 286

From: <bugzilla@wiggum.w3.org>
Date: Mon, 18 Jun 2007 13:45:00 +0000
CC:
To: public-ws-policy-qa@w3.org
Message-Id: <E1I0HXQ-0004nq-B4@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4664

           Summary: Proposal for AI 286
           Product: WS-Policy
           Version: PR
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Guidelines
        AssignedTo: fsasaki@w3.org
        ReportedBy: mhondo@us.ibm.com
         QAContact: public-ws-policy-qa@w3.org


Title: Proposal for AI 286
Target: Guidelines section 5.4.2 

Description: There has been an ongoing action to deal with the Guidelines
document with regard to things we have learned from the WS-Addressing groups
efforts to create new assertions. Monica had floated several proposals dealing
with context and vocabulary.I tried to incorporate this input into the sections
5.4.2 "Nested Assertions" and Section 8 "Designing Assertions".
There is a separate bug for Section 8.


Proposal: 
---------------------------------------------------------------------------
<change from>
5.4.2 Nested Assertions
The framework provides the ability to "nest" policy assertions. For domains
with a complex set of options, nesting provides one way to indicate dependent
elements within a behavior.

The following design questions below can help to determine when to use nested
policy expressions:

Are these assertions designed for the same policy subject? 

Do these assertions represent dependent behaviors?

If the answers are yes to both of these questions then leveraging nested policy
expressions is something to consider. Keep in mind that a nested policy
expression participates in the policy intersection algorithm. If a requester
uses policy intersection to select a compatible policy alternative then the
assertions in a nested policy expression play a first class role in the
outcome. If there is a nested policy expression, an assertion description
should declare it and enumerate the nested policy assertions that are allowed.

There is one caveat to watch out for: policy assertions with deeply nested
policy can greatly increase the complexity of a policy and should be avoided
when they are not needed.


----------------------------------------------------------------------------
<change to>
5.4.2 Nested Assertions
The framework provides the ability to "nest" policy assertions. For domains
with a complex set of options, nesting provides one way to indicate dependent
elements within a behavior. The granularity of assertions is determined by the
authors and it is recommended that care be taken when defining nested policies
to ensure that the options provided appropriately specify policy alternatives
within a specific behavior. 

In particular, when assertion authors define nested assertions, it is important
that the semantic of an empty policy element be defined. 
The following design questions below can help to determine when to use nested
policy expressions:
       Are these assertions designed for the same policy subject? 
       Do these assertions represent dependent behaviors?
If the answers are yes to both of these questions then leveraging nested policy
expressions is something to consider. Keep in mind that a nested policy
expression participates in the policy intersection algorithm. If a requester
uses policy intersection to select a compatible policy alternative then the
assertions in a nested policy expression play a first class role in the
outcome. If there is a nested policy expression, an assertion description
should declare it and enumerate the nested policy assertions that are allowed.
Additional information might be needed in the description to explain the
relationship between the nested assertion semantics and the parent assertion. 
Assertion authors should be aware that the meaning of a nested assertion is
always evaluated in the context of its parent.  This can be illustrated by the
WS-Addressing assertions.

<Policy>                
<ExactlyOne>
    <Addressing>
        <Policy/>       <!V1>
    </Addressing>       
   <Addressing>
        <Policy>        <!V2>
              <AnonymousResponses />
         </Policy>
    </Addressing>       
    <Addressing>
        <Policy>        <!V3>              
            <NonAnonymousResponses />
         </Policy>
    </Addressing>
  </ExactlyOne>
</Policy>       

In the example above, the first alternative vocabulary (V1) indicates that  the
full WS-Addressing spec is supported.   The second alternative vocabulary ( V2)
indicates that another alternative is for WS-Addressing with AnonymousResponses
( to support intersection with those implementations that ONLY support
AnonymousResponses and which would not intersect with the alternative expressed
in V1).  And the third alternative vocabulary ( V3) indicates that another
alternative is for WS-Addressing with NonAnonymousResponses ( to support
intersection with those implementations that ONLY support NonAnonymousResponses
and which would not intersect with the alternative expressed in V1 or V2).

There is one caveat to watch out for: policy assertions with deeply nested
policy can greatly increase the complexity of a policy and should be avoided
when they are not needed.
Received on Monday, 18 June 2007 13:45:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:09 GMT