Action-324 (was FW: [Bug 4662] [Guidelines] Proposal for AI 305

>ACTION-324 Asir to follow-up on 4662 to relate Microsoft comments

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

B. Section 5.5.1

Note: there is an editorial note in Section 5.5.1 - "Looks incomplete - carries Good Practices but there isn't any explanatory text." Does the omnibus proposal resolve the editorial note in Section 5.5.1?

3)
>At a minimum, assertion authors need to document the semantics of the
>assertions [Best Practice 2] and included in that definition should be
>some indication about any impact of the assertion behavior at
>intersection

Cannot understand what does it mean to say "assertion behavior at intersection".

As you know, the behavior indicated by an assertion plays no role in the policy intersection.

The assertion description may define domain specific intersection rules. However, this is not in the minimum to define an assertion.

4)
>When policy expression authors include assertions in service policies

We think you meant "policy expressions" instead of "service policies".

5)
>Ignorable behaviors indicate behavior at the time of intersection.

A policy assertion (ignorable or not) indicates a behavior of a policy subject. It is unclear what does it mean to say "behavior at the time of intersection".

6)
>Assertion authors should indicate the semantic of the runtime behavior
>in the description of the assertion that allows the ignorable
>attribute.

Regardless of ignorable or not, we think that an assertion author should clearly and completely specify the semantics of a policy assertion.

7)
>In the case where one party chooses to engage in runtime behavior with
>another party based on alternatives from a lax mode intersection
>algorithm, the runtime behavior is out of scope of the policy
>framework.

Regardless of the chosen mode for policy intersection, any runtime behavior is always out of scope for the policy framework.

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:23 AM
To: public-ws-policy-qa@w3.org
Subject: [Bug 4662] [Guidelines] Proposal for AI 305


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

           Summary: [Guidelines] Proposal for AI 305
           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: Ignorable Section should be parallel to Optional Section
Target: Guidelines

Description: The current section on ignorable should have comparable sections
to the optional section.

This proposal has 2 parts:
-------------------------------------------------------------------------------
Part 1 ---IGNORABLE SECTION CHANGES
------------------------------------------------------------------------------

<change from>

Policy assertions can be marked with an attribute to indicate that the
assertion can be ignored by the interstection algorithm. Assertion Authors
should consider whether the behavior represented by the Assertion they are
defining can be ignored for the purposes of intersection, and indicate this in
the definition of the assertion. The use of the ignorable attribute influences
whether or not certain assertions are part of the compatability assessment
between two alternatives. See [tbd] for details on the use of the ignorable
attribute.

5.5.1 Assertions and Ignorable Behavior
Best practice 14: Assertions Document Ignorable Behavior

An assertion description should use the wsp:Ignorable attribute to indicate
that the behavior indicated by the QName may be ignored by policy intersection.

5.5.2 XML Outline for Ignorable
Best practice 15: Ignorable Attribute in XML

An assertion XML outline should allow for the use of the wsp:Ignorable
attribute to indicate ignorable behavior.



----------
<change to>
5 Designating Ignorable Behavior

5.5.1 Ignorable behavior in intersection
Ignorable behaviors represent behaviors that may be ignored by the intersection
 algorithm. At a minimum, assertion authors need to document the semantics of
the assertions [Best Practice 2] and included in that definition should be some
 indication about any impact of the assertion behavior at intersection and  at
runtime.

When policy expression authors include assertions in service policies, some
behaviors may be  marked by using wsp:Ignorable attribute with a value of
"true". (In order to simplify reference to such assertions, we just use the
phrase "ignorable assertions" in this section.)  It is recommended that
assertion authors indicate this in the XML outline[Best Practice 7x].

During  intersection, there are two defined modes for processing, lax and
strict.
Policy assertions marked with an attribute to indicate that the assertion can
be ignored by the interstection algorithm are processed differently by
algorithms in strict and lax mode [see Framework & Primer for details] .
Assertion authors should consider whether the behavior represented by the
Assertion they are defining can be safely ignored for the purposes of
intersection, and indicate this in the definition of the assertion. The use of
the ignorable attribute influences whether or not certain assertions are part
of the compatability assessment between two alternatives.

5.5. 2 Ignorable behavior at runtime
Ignorable behaviors indicate behavior at the time of intersection. At runtime,
a party that indicated an ignorable behavior in its policy may engage the
behavior that was marked "ignorable" for intersection. Assertion authors should
indicate the semantic of the runtime behavior in the description of the
assertion that allows the ignorable attribute.

Policy intersection in strict mode will result in an alternative that consists
only of assertions known to both parties.  Hence the runtime behavior is known
to both.

Policy intersection in lax mode may result in alternatives with assertions that
exist in one parties policy but not the other parties policy.  In the case
where one party chooses to engage in runtime behavior with another party based
on alternatives from a lax mode intersection algorithm,  the runtime behavior
is out of scope of the policy framework.
-------------------------------------------------------------------------------Part
2 ---OPTIONAL SECTION CHANGES
-------------------------------------------------------------------------------

<change last sentence in this section to include a reference to the XML outline
section (5.3.2)>

Optional behavior in Compact authoring

An assertion author should clearly indicate in the assertion definition that it
is possible to be optional and to allow the use of the wsp:Optional attribute
in the XML definition[SEE SECTION 5.3.2].
------------------------------------------------------------------------
<delete>
-----------------------------------------------------------------------
Best practice 16: Assertion XML should allow use of wsp:Optional attribute

An assertion XML outline should allow the use of the wsp:Optional attribute to
indicate optional behaviors.

To give a general example, the definition of assertion syntax for a
hypothetical assertion such as SampleAssertion, should allow attribute
extensibility as part of the XML definition, allowing the wsp:Optional
attribute to be used:

Example 5-8. Use of @any for attribute extensibility

/samplePrefix:SampleAssertion/@any
This is an extensibility mechanism to allow additional attributes to be added
to the element, including wsp:Optional.

The portion of the assertion definition that describes policy subjects and
assertion attachment should indicate that wsp:Optional can be used to indicate
that the behavior is optional for the policy subject.

Best practice 17: Assertion description should explicitly indicate that
wsp:Optional is allowed.

An assertion description should use the wsp:Optional attribute to indicate that
the behavior indicated by the QName is optional for the associated policy
subject.

Continuing the example with the hypothetical SampleAssertion, the section on
Assertion Attachment should include discussion of optionality.

Example 5-9. Assertion Attachment text mentions optionality for policy
assertion subjects

The SampleAssertion policy assertion indicates behavior over all messages in a
binding, so it has an Endpoint Policy Subject and must be attached to a
wsdl:binding or wsdl:port.  The assertion may be optional when attached to
these subjects, allowing use of wsp:Optional.

Received on Thursday, 21 June 2007 03:32:31 UTC