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

FW: [Bug 4664] Proposal for AI 286

From: Asir Vedamuthu <asirveda@microsoft.com>
Date: Wed, 20 Jun 2007 20:32:11 -0700
To: "'mhondo@us.ibm.com'" <mhondo@us.ibm.com>, "public-ws-policy@w3.org" <public-ws-policy@w3.org>
Message-ID: <C9BF0238EED3634BA1866AEF14C7A9E543156D8183@NA-EXMSG-C116.redmond.corp.microsoft.com>

Scrapping Microsoft comments that are relevant to issue 4664 from the Action 316 mail thread (See http://lists.w3.org/Archives/Public/public-ws-policy/2007Jun/0052.html):

A. Section 5.4.2

1)
>In particular, when assertion authors define nested assertions, it is
>important that the semantic of an empty policy element be defined.

Cannot understand why assertion authors should define the semantics of an empty policy element. Not aware of any domain that defined the semantics of an empty policy element. <Policy/> is a policy with one policy alternative that has no behaviors specified (0 assertions).

We think that you meant - "In particular, when assertion authors define nested assertions, it is important to also define the semantics of the parent assertion when it is not qualified by any nested assertions." If so, then you should say that instead.

2)
>In the example above, the first alternative vocabulary
>(V1) indicates that the full WS-Addressing spec is supported.

To resolve issue 4544, the Working Group dropped all the vocabulary related definitions. To avoid confusion, we suggest not to use the term vocabulary.

Regards,

Asir S Vedamuthu
Microsoft Corporation

-----Original Message-----
From: public-ws-policy-qa-request@w3.org [mailto:public-ws-policy-qa-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org
Sent: Monday, June 18, 2007 6:45 AM
To: public-ws-policy-qa@w3.org
Subject: [Bug 4664] Proposal for AI 286


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 Thursday, 21 June 2007 03:32:28 GMT

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