- From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 22 Jan 2007 18:18:46 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv12284
Modified Files:
ws-policy-primer.xml
Log Message:
Editors AI 118, implemented resolution for issue 4141
Index: ws-policy-primer.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.xml,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -d -r1.29 -r1.30
--- ws-policy-primer.xml 19 Jan 2007 00:09:05 -0000 1.29
+++ ws-policy-primer.xml 22 Jan 2007 18:18:43 -0000 1.30
@@ -930,7 +930,8 @@
<p>The assertion parameters are the opaque payload of an assertion. Parameters carry
additional useful pieces of information necessary for engaging the behavior described by
an assertion. In the XML representation, the child elements and attributes of an assertion
- are the assertion parameters.</p>
+ excluding the child elements and attributes from the WS-Policy language XML namespace name,
+ are the assertion parameters. For example @wsp:Optional and @wsp:Ignorable are not assertion parameters.</p>
<p>We considered nested policy expressions in the context of a security usage scenario. Let
us look at its shape in the policy data model. In the normal form, a nested policy is a
policy that has at most one policy alternative and is owned by its parent policy
@@ -2043,6 +2044,13 @@
<loc href="http://www.w3.org/2007/01/18-ws-policy-irc#T22-09-36">resolution</loc> corresponding to
Editors' action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/143">143</loc>.
</td>
+ </tr>
+ <tr>
+ <td>20070122</td>
+ <td>PY</td>
+ <td>Completed action item:
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/118">118</loc>
+ Resolution for issue <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4141">4141</loc></td>
</tr>
</tbody>
</table>
Received on Monday, 22 January 2007 18:18:53 UTC