- From: David Orchard via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 17 Jul 2007 15:46:53 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv407
Modified Files:
ws-policy-guidelines.xml
Log Message:
Update to section 5.5 for partial resolution of 4661/4462
Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -d -r1.97 -r1.98
--- ws-policy-guidelines.xml 17 Jul 2007 11:47:41 -0000 1.97
+++ ws-policy-guidelines.xml 17 Jul 2007 15:46:49 -0000 1.98
@@ -725,7 +725,19 @@
semantics of a policy assertion.
</quote>
</p>
-
+
+ <p role="practice" id="DefineIgnorable"><quote>Assertion Authors Should Document Ignorable Behavior</quote> >
+ <quote>An assertion description should include guidance as to the use of (or
+constraint against the use of) the wsp:Ignorable attribute to indicate
+whether or not the behavior indicated by the QName may be ignored by policy
+intersection. </quote>
+ </p>
+ <p role="practice" id="ignorableAssertions"> <quote>Assertion Authors Should Document Use of the Ignorable
+Attribute in XML </quote> >
+ <quote> An Assertion Author should document, in the XML outline and/or schema for
+the assertion, whether or not the assertion allows for the use of the wsp:Ignorable attribute.
+ </quote>
+ </p>
</div3>
<div3 id="self-describing">
@@ -1036,37 +1048,28 @@
</div3>
</div2>
- <div2 id="Ignorable">
+ <div2 id="Ignorable">
<head>Designating Ignorable Behavior</head>
- <ednote>
- <edtext>Looks incomplete – carries Best Practices but there isn’t any explanatory text.</edtext>
- </ednote>
- <p>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.
- </p>
- <div3 id="doc-ignorable-assertions">
- <head>Assertions and Ignorable Behavior</head>
- <p role="practice" id="DefineIgnorable"><quote>Assertions Document Ignorable Behavior</quote> >
- <quote> An assertion description should use the wsp:Ignorable attribute
- to indicate that the behavior indicated by the QName may be ignored by policy intersection.
- </quote>
- </p>
- </div3>
- <div3 id="XML-ignorable-assertions">
- <head>XML Outline for Ignorable </head>
- <p role="practice" id="ignorableAssertions"> <quote>Ignorable Attribute in XML</quote> >
- <quote> An assertion XML outline should allow for the use of the wsp:Ignorable attribute
- to indicate ignorable behavior.
- </quote>
- </p>
- </div3>
+ <div3>
+ <head>Ignorable behavior in authoring</head>
+ <p>
+ The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict). The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatability assessment between two alternatives. [see <bibref ref="WS-Policy"/> and <bibref ref="WS-Policy-Primer"/>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <specref ref="DefineIgnorable"/> and <specref ref="ignorableAssertions"/> to include this guidance in the assertion's definition.</p>
+ </div3>
+ <div3>
+ <head>Ignorable behavior at runtime</head>
+ <p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
+ indicate the semantic of the runtime behavior in the description of the assertion.
+ </p>
+
+ <p>
+As said in <xspecref href="&w3c-designation-primer;#strict-lax-policy-intersection">section 3.4.1 Strict and Lax Policy Intersection</xspecref> in <bibref ref="WS-Policy-Primer"/>, "Regardless of the chosen intersection mode, ignorable assertions do not express any wire-level requirements on the behavior of consumers - in other words, a consumer could choose to ignore any such assertions that end up in the resulting policy after intersection, with no adverse effects on runtime interactions." Therefore, any assertion that is marked with ignorable should not impose any wire-level requirements on the part of consumers. Assertion Authors are reminded that regardless of whether an assertion is marked as ignorable, policy consumers using strict intersection will not 'ignore' the assertion.
+ </p>
+ </div3>
+
</div2>
+
+
<div2 id="optional-policy-assertion">
<head>Designating Optional Behaviors</head>
<div3>
@@ -2083,6 +2086,9 @@
</item>
<item><p>Made editorial changes to align with the OASIS WS-SecurityPolicy specification.</p></item>
<item><p>Made editorial changes to align with the W3C WS-Addressing 1.0 Metadata specification.</p></item>
+ <item>
+<p>Updated Section 5.5 for 4661/4662.</p>
+</item>
</ulist>
</inform-div1>
<inform-div1 id="change-log">
@@ -2738,7 +2744,14 @@
Editors' action
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/332">332</loc>.
</td>
- </tr>
+ </tr>
+ <tr>
+ <td>20070717</td>
+ <td>DBO</td>
+ <td>Implemented partial resolution, section 5.5 updates,
+ for issue <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4662">4662</loc>, Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/332">332</loc> #2.</td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Tuesday, 17 July 2007 15:47:01 UTC