[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 Monday, 18 June 2007 13:22:43 UTC