- From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 21 May 2007 01:54:36 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv20785
Modified Files:
ws-policy-guidelines-diff20070330.xml
ws-policy-guidelines-diff20070330.html
Log Message:
Generated diff - but it is not a useful one :-(
Index: ws-policy-guidelines-diff20070330.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines-diff20070330.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-guidelines-diff20070330.xml 1 May 2007 23:30:36 -0000 1.2
+++ ws-policy-guidelines-diff20070330.xml 21 May 2007 01:54:33 -0000 1.3
@@ -57,7 +57,7 @@
</p><p> As a companion document to the primer, this document also follows
the Socratic style of beginning with a question, and then answering
the question.
- </p></div1><div1 id="best-practices-list" diff="add"><head><phrase diff="add">List of Good Practice Statements</phrase></head><p><phrase diff="add">The following good practices appear in this document with discussion and examples, and are summarized here for quick reference:</phrase></p><olist><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-assertion-specification-parts" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Parts of an Assertion Specification</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-assertion-semantics" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Semantics of Policy Assertions</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-semantics-and-form" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Semantics of an Assertion and its form</phrase></loc></p></item><item>p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-assertion-start" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Starting to Build an Assertion</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-unique-qnames" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Unique QNames</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-assertions-and-message-semantics" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Assertions and Message Semantics</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-assertion-duplication" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Duplication of Assertions</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-assertion-definition" xlink:type="simple" xlink:actuate="nRequest" xlink:show="replace"><phrase diff="add">Definition of Policy Assertions</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-nesting" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Nesting of Assertions</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-assertion-xml-allow-optional" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Assertion XML should allow use of wsp:Optional attribute</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-assertion-description-explicitly-allow-optional" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Assertion description should explicitly indicate that wsp:Optional is allowed.</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-limit-optional-assertions" xlink:type="simple" xlink:actuate="onRequst" xlink:show="replace"><phrase diff="add">Limit use of Optional Assertions</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-entire-mep-for-optional" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Consider entire message exchange pattern when specifying Assertions that may be optional</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-indicate-optional-assertion-use" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Indicate use of an Optional Assertion</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-independent-assertions" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Independent Assertions</phrase></loc></p></item><item><p><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-policy-subject-change" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replae"><phrase diff="add">Change of the Policy Subject Over Time</phrase></loc></p></item></olist></div1><div1 id="Assertions"><head>What is an Assertion? </head><p>An assertion is a piece of metadata that describes a
+ </p></div1><div1 id="best-practices-list" diff="add"><head><phrase diff="add">List of Good Practice Statements</phrase></head><p><phrase diff="add">The following good practices appear in this document with discussion and examples, and are summarized here for quick reference:</phrase></p><ulist><item><p><specref ref="bp-assertion-specification-parts"/></p></item><item><p><specref ref="bp-assertion-semantics"/></p></item><item><p><specref ref="bp-semantics-and-form"/></p></item><item><p><specref ref="bp-assertion-start"/></p></item><item><p><specref ref="bp-unique-qnames"/></p></item><item><p><specref ref="AssertionDefinitions"/></p></item><item><p><specref ref="XMLOutline"/></p></item><item><p><specref ref="bp-not-necessary-to-understand-a-message"/></p></item><item><p><specref ref="bp-assertion-duplication"/></p></item><item><p><specref ref="bp-assertion-parameters"/></p></item><item><p><specref ref="bp-dependent-behaviors"/></p></item><item><p><specref ref="bp-declare-nested-assertions"/></p></ite><item><p><specref ref="bp-discourage-domain-specific-intersection"/></p></item><item><p><specref ref="DefineIgnorable"/></p></item><item><p><specref ref="ignorableAssertions"/></p></item><item><p><specref ref="bp-assertion-xml-allow-optional"/></p></item><item><p><specref ref="bp-assertion-description-explicitly-allow-optional"/></p></item><item><p><specref ref="bp-limit-optional-assertions"/></p></item><item><p><specref ref="bp-entire-mep-for-optional"/></p></item><item><p><specref ref="bp-indicate-optional-assertion-use"/></p></item><item><p><specref ref="bp-WSDL-policy-subject"/></p></item><item><p><specref ref="bp-WSDL-policy-subject-Granularity"/></p></item><item><p><specref ref="bp-WSDL-multiple-policy-subjects"/></p></item><item><p><specref ref="bp-WSDL-preferred-attachment-point"/></p></item><item><p><specref ref="bp-WSDL-policy-multiple-instance-semantics"/></p></item><item><p><specref ref="bp-specify-composition"/></p></item><item><p><specref ref="bp-independent-assertions"/></p></item><item><p><pecref ref="bp-policy-subject-change"/></p></item></ulist></div1><div1 id="Assertions"><head>What is an Assertion? </head><p>An assertion is a piece of metadata that describes a
capability related to a specific WS-Policy domain. Sets of domain-specific assertions
are typically defined in a dedicated specification that describes
their semantics, applicability and scoping requirements as well
@@ -203,24 +203,44 @@
relies on the QName of a policy assertion being an XML element but allows Assertion Authors to optionally
provide additional semantics through nesting assertions, or specifying assertion parameters.
This section covers several aspects of assertion design and provides some answers to the following questions:</p><ulist><item><p>What is the intended use of the policy assertion?</p></item><item><p>Which authoring style will be used?</p></item><item><p>Is this a new policy domain? Does it need to compose with other domains?</p></item><item><p>How complex are the assertions?</p></item><item><p>Is there a need to consider nesting?</p></item><item><p>Do optional behaviors need to be represented?</p></item></ulist><div2 id="assertion-target"><head>Assertions and Their Target Use</head><p>
- Assertion Authors need to have a specific goal in mind for the assertions
- that they author. Assertion Authors should also understand the
- functionality that the WS-Policy framework provides and apply the
- knowledge of the policy framework processing when defining the set of
- assertions.
- </p><p>Assertions can be simple or they can be complex. Assertion Authors may
- choose to specify multiple peer assertions, each carrying the semantic of
- a particular behavior, or they may choose to specify assertions that
- contains assertion parameters and/or nested policy expression (nested
- assertions), each of which relate to an aspect of the behavior, yet
- encapsulated within a single assertion. There are advantages to
- simplifying the set of assertions. The ultimate goal of policy is to
- enable interoperability. By keeping assertion design as simple as
- possible, Assertion Authors will more likely be able to meet that
- objective.
+ Assertion Authors <phrase diff="del">need to have a specific goal in mind for the assertions
+ that they author. Assertion Authors </phrase>should <phrase diff="del">also </phrase>understand the functionality that the WS-Policy
+ framework provides and apply the knowledge of the policy framework processing
+ when defining the set of assertions.
</p><p>
- If a set of assertions describes a wide range of behaviors, the ability to
- combine individual assertions may also need to be considered.
+ Assertions can be simple or they can be complex. Assertion Authors may
+ choose
+ to specify multiple peer assertions, each carrying the semantic of a particular
+ behavior, or they may choose to specify assertions that contains assertion parameters
+ and/or nested policy expression (nested assertions), each of which relate to an
+ aspect of the behavior, yet encapsulated within a single assertion.
+ There are advantages to simplifying the set of assertions. The ultimate goal of
+ policy is to enable interoperability. By keeping assertion design as simple as
+ possible, Assertion Authors will more likely be able to meet that objective.
+ </p><p>
+ <phrase diff="add">Therefore, Assertion Authors need to have a specific goal in mind for the assertions
+ that they author. Assertion specifications should include a detailed specification
+ of the assertion’s semantics, a set of valid policy subjects to which the asserction
+ maybe attached. The specification should also include the scope of the assertion
+ in the context of a particular policy subject. For example, an assertion with
+ Endpoint Policy Subject can be scoped to a given message exchange with that endpoint,
+ or it can be scoped to all messages exchanged with that endpoint.</phrase><phrase diff="del">If </phrase><phrase diff="add">The former case
+ permits a client to select a different alternative with each successive message
+ exchange. Finally, if </phrase>a set of assertions describes a wide range of behaviors,
+ the ability to combine individual assertions may also need to be considered.
+ <phrase diff="add">For example, if an assertion applies to the SOAP protocol, it would be necessary
+ to consider how its presence must interact with other policy assertions that
+ are defined for security.
+ </phrase></p><p role="practice" id="bp-assertion-specification-parts" diff="add"><quote><phrase diff="add">Parts of an Assertion Specification</phrase></quote>
+ <quote>
+ <phrase diff="add">Assertion Authors should include the following items in an
+ assertion specification: </phrase></quote>
+ </p><p diff="add">
+ <ulist><item><p><emph><phrase diff="add">The definition of the assertion's semantic.</phrase></emph> </p></item><item><p><emph><phrase diff="add">The specification of the set of valid policy subjects to which an
+ assertion may be attached.</phrase></emph></p></item><item><p><emph><phrase diff="add">The scope of the assertion in the context of a particular policy
+ subject.</phrase></emph></p></item><item><p><emph><phrase diff="add">Any composition considerations if the assertion is used with
+ other assertions in a context.</phrase></emph></p></item></ulist>
+
</p><p>
The WS-Policy Attachment specification defines a number of different
policy subjects to which an assertion can be attached. For attaching to
@@ -229,8 +249,8 @@
policy subjects beyond the set of subjects defined in the WS-Policy
Attachment specification.
</p><p>
- The WS-Policy Attachment specification provides various mechanisms to
- attach a policy expression to a policy subject. Although a policy
+ <phrase diff="del">The WS-Policy Attachment specification provides various mechanisms to
+ attach a policy expression to a policy subject. </phrase>Although a policy
assertion may be constrained to a specific set of policy subjects by
assertion authors, its semantics should not be dependent upon the
mechanism by which the policy expression is attached to a given policy
@@ -240,27 +260,41 @@
attachment mechanism. Independence from a specific attachment mechanism
allows policy tools to choose the most appropriate mechanism to attach a
policy without having to analyze the contents of the policy.
- </p><p role="practice" id="bp-assertion-specification-parts" diff="add"><quote><phrase diff="add">Parts
- </phrase><phrase diff="del">Best </phrase><phrase diff="add">of an Assertion</phrase><phrase diff="del">practice: </phrase><phrase diff="add">Specification</phrase></quote><quote>
- Assertion Authors should include the following items in an
- assertion specification: </quote>
- </p><p>
- <ulist><item><p><emph>The definition of the assertion's semantic.</emph> </p></item><item><p><emph>The specification of the set of valid policy subjects to which an
- assertion may be attached.</emph></p></item><item><p><emph>The scope of the assertion in the context of a particular policy
- subject.</emph> For example, an assertion with Endpoint Policy Subject can be
+ </p><p diff="del">Best practice: Assertion Authors should include the following items in an
+ assertion specification:
+
+ </p><p role="practice" id="bp-assertion-semantics" diff="add"><quote><phrase diff="add">Semantics
+ </phrase><phrase diff="del">The definition of the assertion's semantic.
+ The specification </phrase><phrase diff="add">Independent</phrase><phrase diff="del">of the set </phrase>of
+ <phrase diff="add">Attachment </phrase><phrase diff="del">valid policy subjects to which an
+ assertion may be </phrase><phrase diff="add">Mechanisms</phrase></quote><quote>
+ <phrase diff="del">attached.
+ </phrase>The <phrase diff="add">semantics</phrase><phrase diff="del">scope of the assertion in the context </phrase>of a <phrase diff="del">particular </phrase>policy
+ <phrase diff="del">subject. For example, an </phrase>assertion <phrase diff="add">should</phrase><phrase diff="del">with Endpoint Policy Subject can be
scoped to a given message exchange with that endpoint, or it can be scoped
- to all messages exchanged with that endpoint. The former case permits a
- client to select a different alternative with each successive message
- exchange.</p></item><item><p><emph>Composition</emph>. If the assertion is used with other assertions in a
- context, it is necessary to consider how the assertion may, or may not,
- affect the composition. For example, if an assertion applies to the SOAP
- protocol, it would be necessary to consider how its presence must interact
- with other policy assertions that are defined for security.</p></item></ulist>
- </p><p role="practice" id="bp-assertion-semantics" diff="add"><quote><phrase diff="add">Semantics
- </phrase><phrase diff="del">Best </phrase><phrase diff="add">of Policy</phrase><phrase diff="del">practice: </phrase><phrase diff="add">Assertions</phrase></quote><quote>
- The semantics a policy assertion should not depend on the
- attachment mechanism used.</quote>
- </p></div2><div2 id="compact-full"><head>Authoring Styles </head><p>WS-Policy supports two different authoring styles, compact form and
+ to all messages </phrase><phrase diff="chg">not depend on </phrase><phrase diff="add">the
+ attachment</phrase><phrase diff="del">endpoint. </phrase><phrase diff="chg">mechanism </phrase><phrase diff="add">used.</phrase></quote>
+ </p><ednote diff="add"><edtext><phrase diff="add">April</phrase><phrase diff="del">former </phrase><phrase diff="chg">25th 07, </phrase><phrase diff="add">editors
+ </phrase><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2007/04/25-ws-policy-eds-minutes.html#item03" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">decided</phrase></loc><phrase diff="del">a
+ client </phrase>to <phrase diff="add">add</phrase><phrase diff="del">select a different alternative with each successive message
+ exchange.
+ Composition. </phrase><phrase diff="chg">G2 </phrase><phrase diff="add">-
+ "An</phrase><phrase diff="del">the </phrase>assertion <phrase diff="add">author</phrase><phrase diff="del">is used </phrase><phrase diff="chg">should </phrase><phrase diff="add">define
+ policy</phrase><phrase diff="del">other </phrase>assertions <phrase diff="chg">for </phrase><phrase diff="add">behaviors</phrase><phrase diff="del">a
+ context, </phrase><phrase diff="chg">that are relevant </phrase>to <phrase diff="add">compatibility</phrase><phrase diff="del">consider how the assertion may, or may not,
+ affect the </phrase><phrase diff="add">tests,
+ such</phrase><phrase diff="del">composition. </phrase><phrase diff="chg">as web service protocols that manifest on </phrase>the <phrase diff="add">wire."</phrase><phrase diff="del">SOAP
+ protocol, it would be </phrase><phrase diff="chg">- </phrase>to <phrase diff="add">Section</phrase><phrase diff="del">consider how its presence must interact
+ with other policy assertions that are defined for security.
+
+
+
+ Best practice: The </phrase><phrase diff="add">5.1.
+ May</phrase><phrase diff="del">semantics </phrase><phrase diff="chg">9th 07, an issue was opened against </phrase><phrase diff="add">G2</phrase><phrase diff="del">the
+ attachment </phrase><phrase diff="chg">- </phrase><phrase diff="add">issue
+ </phrase><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4566" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">4566</phrase></loc><phrase diff="add">.
+ </phrase></edtext><phrase diff="del">used.
+ </phrase></ednote></div2><div2 id="compact-full"><head>Authoring Styles </head><p>WS-Policy supports two different authoring styles, compact form and
normal form. A compact form is one in which an expression consists of
three constructs: an attribute to decorate an assertion (to indicate
whether it is required or optional), semantics for recursively nested
@@ -290,7 +324,7 @@
</p><p role="practice" id="bp-semantics-and-form" diff="add">
<quote><phrase diff="add">Semantics
- </phrase><phrase diff="del">Best </phrase><phrase diff="chg">of </phrase><phrase diff="add">an Assertion and its</phrase><phrase diff="del">the </phrase><phrase diff="add">form</phrase></quote>
+ </phrase><phrase diff="del">Best </phrase><phrase diff="chg">Independent </phrase><phrase diff="add">of </phrase>the <phrase diff="add">Form</phrase></quote>
<quote><phrase diff="add">The </phrase>semantics of an assertion should be independent of
the form (compact or normal form) of policy expressions that contain the
assertion.</quote>
@@ -380,34 +414,65 @@
assertions to define. Interoperability testing of new policy
domains is recommended to ensure that consumers and providers
are able to use the new domain assertions.
- </p><p role="practice" id="bp-assertion-start" diff="add"><quote><phrase diff="add">Starting to Build an Assertion</phrase></quote><quote><phrase diff="add">Start with a simple working assertion that allows extensibility.
- As your design work progresses, you may add more parameters or nested policy assertions to meet
- your interoperability needs. </phrase></quote>
- </p><p>New Assertion Authors are encouraged to look at <bibref ref="WS-RM-Policy"/> to see an example of a
- relatively simple domain that has defined three assertions. Assertion Authors are encouraged to look at <bibref ref="WS-SecurityPolicy"/> to see an example of a complex domain that has been decomposed into a set of policy expressions.
- </p><p diff="del">How big should an assertion be? How many assertion parameters should the assertion
- enumerate? How many dependent behaviors should the assertion enumerate? It is always
- good to start with a simple working policy assertion that allows extensibility. As your
- design work progresses, you may add more parameters or nested policy assertions to meet
- your interoperability needs.
+
+ <phrase diff="del">New Assertion Authors are </phrase><phrase diff="chg">To facilitate </phrase><phrase diff="add">proper
+ progression</phrase><phrase diff="del">look </phrase><phrase diff="chg">of </phrase><phrase diff="add">an </phrase><phrase diff="chg">assertion, assertion authors should start </phrase><phrase diff="add">with
+ </phrase>a
+ <phrase diff="del">relatively </phrase>simple <phrase diff="add">working</phrase><phrase diff="del">domain that has defined three assertions. Assertion </phrase><phrase diff="chg">assertion that allows extensibility. As the </phrase><phrase diff="add">design
+ work </phrase><phrase diff="chg">progresses, one may add more parameters or nested policy </phrase><phrase diff="add">assertions
+ to</phrase><phrase diff="del">has </phrase><phrase diff="chg">meet one's interoperability </phrase><phrase diff="add">needs.
+ </phrase></p><p role="practice" id="bp-assertion-start" diff="add"><quote><phrase diff="add">Start</phrase><phrase diff="del">a </phrase><phrase diff="chg">with Simple </phrase><phrase diff="add">Assertion</phrase></quote>
+ <quote><phrase diff="add">An</phrase><phrase diff="del">policy </phrase><phrase diff="add">assertion</phrase><phrase diff="del">expressions.
+
+ How </phrase><phrase diff="chg">author </phrase>should <phrase diff="chg">start with a simple working </phrase>assertion
+ <phrase diff="add">that </phrase><phrase diff="del">parameters should </phrase><phrase diff="chg">allows </phrase>assertion
+ <phrase diff="del">enumerate? </phrase><phrase diff="chg">parameter extensibility. </phrase></quote>
+ </p><p diff="add"><phrase diff="add">New</phrase><phrase diff="del">dependent </phrase><phrase diff="chg">Assertion Authors are encouraged to look at </phrase><bibref ref="WS-RM-Policy"/><phrase diff="del">always
+ good </phrase>to <phrase diff="chg">see an example of </phrase><phrase diff="add">a
+ relatively</phrase><phrase diff="del">working </phrase><phrase diff="chg">simple domain </phrase>that <phrase diff="chg">has defined three </phrase><phrase diff="add">assertions.</phrase><phrase diff="del">your
+ design </phrase><phrase diff="chg">Assertion Authors are encouraged to look at </phrase><bibref ref="WS-SecurityPolicy"/><phrase diff="del">or </phrase><phrase diff="chg">to see an example </phrase><phrase diff="add">of</phrase><phrase diff="del">meet
+ your </phrase><phrase diff="chg">a </phrase><phrase diff="add">complex</phrase><phrase diff="del">needs.
- Best practice: Start with a simple working assertion that allows extensibility.
-
- </p></div3><div3 id="QName_and_XML_Information_Set_representation"><head>QName and XML Information Set representation</head><p>Web Services Policy language allows Assertion Authors to invent
+ Best </phrase><phrase diff="chg">domain that has been decomposed into a set of </phrase><phrase diff="add">policy expressions.
+ </phrase><phrase diff="del">extensibility.
+ </phrase></p></div3><div3 id="QName_and_XML_Information_Set_representation"><head>QName and XML Information Set representation</head><p>Web Services Policy language allows Assertion Authors to invent
their own XML dialects to represent policy assertions. The policy language relies only
on the policy assertion XML element QName. This QName is unique and identifies the
behavior represented by a policy assertion. Assertion Authors have the option to
represent an assertion parameter as a child element (by leveraging natural XML nesting)
or an attribute of an assertion. The general guidelines on when to use XML elements
- versus attributes apply.</p><p role="practice" id="bp-unique-qnames" diff="add"><quote><phrase diff="add">Unique QNames</phrase></quote><quote><phrase diff="add">Use a unique QName to identify the behavior and provide an XML outline
- (plus an XML schema document) to specify the syntax of an assertion. </phrase></quote>
+ versus attributes <phrase diff="add">apply is. Use a unique QName to identify a distinct behavior and provide
+ an XML outline (plus an XML schema document) to specify the syntax of an assertion. </phrase><phrase diff="del">apply.</phrase></p><p role="practice" id="bp-unique-qnames" diff="add"><quote><phrase diff="add">Use Unique QNames</phrase></quote>
+ <quote><phrase diff="add">An assertion author should use a unique QName to identify a distinct behavior.</phrase></quote>
</p><p>The syntax of an assertion can be represented using an XML outline (plus an XML schema
document). If the assertion has a nested policy expression then the assertion XML
- outline can enumerate the nested assertions that are allowed.
-
- <phrase diff="del">Best practice: Use a unique QName to identify the </phrase><phrase diff="add">An</phrase><phrase diff="del">behavior and provide an XML outline
- (plus an XML schema document) </phrase><phrase diff="chg">example is </phrase>the <phrase diff="add">following:</phrase><phrase diff="del">syntax of an assertion.
+ outline can enumerate the nested assertions that are allowed. <phrase diff="add">An example is the following:
</phrase></p><example diff="add"><eg xml:space="preserve">
+ <sp:IssuedToken sp:IncludeToken="xs:anyURI"? ... >
+ <sp:Issuer> wsa:EndpointReferenceType</sp:Issuer>?
+ <sp:RequestSecurityTokenTemplate TrustVersion="xs:anyURI"? >
+ ...
+ </sp:RequestSecurityTokenTemplate >
+ <wsp:Policy >
+ <sp:RequireDerivedKeys /> ?
+ <sp:RequireExternalReference /> ?
+ <sp:RequireInternalReference /> ?
+ ...
+ </wsp:Policy> ?
+ ...
+</sp:IssuedToken>
+
+ </eg></example><p role="practice" id="AssertionDefinitions" diff="add">
+ <phrase diff="del">Best </phrase><quote><phrase diff="add">Specify</phrase><phrase diff="del">practice: </phrase><phrase diff="chg">Semantics </phrase><phrase diff="add">Clearly</phrase></quote><phrase diff="del">a </phrase><phrase diff="add">>
+ </phrase><quote><phrase diff="del">unique </phrase><phrase diff="chg">An assertion description must clearly </phrase>and <phrase diff="add">completely specify the semantics of a policy
+ assertion.
+ </phrase></quote>
+ </p><p role="practice" id="XMLOutline" diff="add"> <quote><phrase diff="add">Provide an XML Outline</phrase></quote> <phrase diff="add">>
+ </phrase><quote> <phrase diff="add">An assertion description should </phrase>provide an XML outline
+ <phrase diff="del">(plus </phrase>plus an XML schema <phrase diff="del">document) </phrase>to specify the
+ syntax of <phrase diff="chg">the </phrase>assertion.
+ </quote>
+ </p><example diff="add"><eg xml:space="preserve">
<wsrmp:RMAssertion [wsp:Optional="true"]? ...>
...
</wsrmp:RMAssertion/>
@@ -427,18 +492,18 @@
<phrase diff="add">determine </phrase><phrase diff="chg">the behaviors engaged at runtime by additional means. </phrase><phrase diff="add">A
general</phrase><phrase diff="del">expressing, </phrase><phrase diff="add">protocol</phrase><phrase diff="del">in
policy, </phrase><phrase diff="chg">that aids in determining such behaviors may </phrase><phrase diff="add">be
- utilized, however</phrase><phrase diff="del">by </phrase>a <phrase diff="add">standard</phrase><phrase diff="del">particular
+ utilized,</phrase><phrase diff="del">by </phrase><phrase diff="add">however </phrase>a <phrase diff="add">standard</phrase><phrase diff="del">particular
endpoint, </phrase><phrase diff="chg">protocol for this purpose </phrase><phrase diff="add">is
currently</phrase><phrase diff="del">required </phrase><phrase diff="add">not available to ensure interoperability. Thus,</phrase><phrase diff="del">in </phrase>a <phrase diff="chg">private protocol </phrase><phrase diff="add">should</phrase><phrase diff="del">the
latter </phrase><phrase diff="chg">be used with </phrase><phrase diff="add">care.
- </phrase></p><p diff="add"><phrase diff="add">Another approach is to</phrase><phrase diff="del">uses </phrase>use of the <phrase diff="chg">assertion </phrase><phrase diff="add">to selectively apply</phrase><phrase diff="del">framework.
+ </phrase></p><p diff="add"><phrase diff="add">Another approach is to use</phrase><phrase diff="del">uses </phrase>of the <phrase diff="chg">assertion </phrase><phrase diff="add">to selectively apply to subjects. For example,</phrase><phrase diff="del">framework.
- As </phrase><phrase diff="add">to subjects. For example, </phrase>a
- <phrase diff="add">dedicated </phrase><phrase diff="chg">endpoint may be allocated to ensure </phrase><phrase diff="add">the engagement of</phrase><phrase diff="del">into </phrase><phrase diff="add">a
+ As </phrase>a
+ <phrase diff="add">dedicated </phrase><phrase diff="chg">endpoint may be allocated to ensure </phrase><phrase diff="add">the engagement</phrase><phrase diff="del">into </phrase><phrase diff="add">of a
behavior</phrase><phrase diff="del">account </phrase>that <phrase diff="chg">is expressed by </phrase><phrase diff="add">a policy assertion. This approach
can be considered </phrase><phrase diff="del">concepts
- </phrase>when <phrase diff="chg">messages </phrase><phrase diff="add">cannot be self</phrase><phrase diff="del">assertions </phrase><phrase diff="add">describing.
- </phrase></p><p role="practice" id="bp-assertions-and-message-semantics" diff="add"><quote><phrase diff="add">Assertions </phrase>and <phrase diff="add">Message Semantics</phrase></quote><quote><phrase diff="add">Policy assertions should not be used to express</phrase><phrase diff="del">documenting </phrase>the semantics of <phrase diff="add">a</phrase><phrase diff="del">the
+ </phrase>when <phrase diff="add">messages cannot be self describing.
+ </phrase></p><p diff="add"><phrase diff="add">Policy</phrase><phrase diff="del">designing </phrase>assertions <phrase diff="add">should not be used to</phrase><phrase diff="del">and </phrase><phrase diff="chg">express </phrase>the semantics of <phrase diff="add">a</phrase><phrase diff="del">the
assertion </phrase><phrase diff="add">message.</phrase><phrase diff="del">types.
</phrase>Firstly, an assertion type indicates a <emph>runtime</emph> behavior.
@@ -452,14 +517,17 @@
consider how to make messages self describing when utilizing
their assertions by specifying additional properties, headers,
etc. that must be present in a message as part of their assertion design.
- </quote>
- </p><p><phrase diff="add">For</phrase><phrase diff="del">If the messages could not be made self describing by utilizing additional properties </phrase><phrase diff="chg">example, if </phrase>the
- <phrase diff="del">message as required by </phrase><phrase diff="chg">details of a message's encryption ( </phrase><phrase diff="add">e.g.,</phrase><phrase diff="del">to
- determine </phrase>the <phrase diff="add">cipher</phrase><phrase diff="del">behaviors engaged at runtime by additional means. A
- general </phrase><phrase diff="chg">used, etc) are </phrase><phrase diff="add">expressed
- </phrase>in <phrase diff="add">policy</phrase><phrase diff="del">determining such behaviors may be
- utilized, however a standard protocol for this purpose is
- currently not available to ensure interoperability. Thus, a private protocol should be used with care. </phrase><phrase diff="add">that
+ </p><p role="practice" id="bp-not-necessary-to-understand-a-message" diff="add">
+ <quote><phrase diff="add">Not
+ </phrase><phrase diff="del">If the messages could not be made self describing by utilizing additional properties </phrase><phrase diff="chg">Necessary to </phrase><phrase diff="add">Understand</phrase><phrase diff="del">the
+ message </phrase><phrase diff="chg">a </phrase><phrase diff="add">Message</phrase></quote>
+ <quote><phrase diff="add">An</phrase><phrase diff="del">required </phrase><phrase diff="chg">assertion author should not define policy assertions </phrase>to
+ <phrase diff="del">determine the behaviors engaged at runtime by additional means. </phrase><phrase diff="add">represent</phrase><phrase diff="del">A
+ general </phrase><phrase diff="chg">information </phrase>that <phrase diff="add">is</phrase><phrase diff="del">aids in determining such behaviors </phrase><phrase diff="chg">necessary </phrase><phrase diff="add">to</phrase><phrase diff="del">be
+ utilized, </phrase><phrase diff="chg">understand </phrase>a <phrase diff="add">message.</phrase></quote>
+ </p><p diff="add"><phrase diff="add">For</phrase><phrase diff="del">standard protocol for </phrase><phrase diff="chg">example, if </phrase><phrase diff="add">the</phrase><phrase diff="del">is
+ currently </phrase><phrase diff="chg">details of a message's encryption ( e.g., the cipher used, etc) are </phrase><phrase diff="add">expressed
+ in</phrase><phrase diff="del">with </phrase><phrase diff="chg">policy </phrase><phrase diff="add">that
</phrase><phrase diff="del">Another </phrase><phrase diff="chg">isn't attached </phrase>to <phrase diff="del">use of </phrase>the <phrase diff="add">message,</phrase><phrase diff="del">assertion to </phrase><phrase diff="chg">it isn't </phrase><phrase diff="add">possible
</phrase>to <phrase diff="chg">later decipher it. </phrase><phrase diff="add">This</phrase><phrase diff="del">a
dedicated </phrase><phrase diff="chg">is very different from expressing, </phrase><phrase diff="add">in
@@ -489,47 +557,109 @@
of services need to find value in the set of
assertions or they will not include the assertions in
their service descriptions.
- </p><p role="practice" id="bp-assertion-duplication" diff="add"><quote><phrase diff="add">Duplication of Assertions</phrase></quote><quote><phrase diff="add">Avoid duplication of assertions.
-
- </phrase>A review by a broad community is the best way to ensure that the granularity of a set of domain
- assertions is appropriate.
-
- <phrase diff="del">Best practice: Avoid duplication </phrase></quote><phrase diff="del">of assertions.
+ </p><p><phrase diff="add">It is the responsibility of the assertion authors to avoid duplication of assertions.
+ </phrase>A review by a broad community is the best way to ensure that the granularity of a set
+ of domain assertions is appropriate.
+ </p><p role="practice" id="bp-assertion-duplication" diff="add"><quote>
+ <phrase diff="del">Best practice: </phrase>Avoid <phrase diff="chg">Duplication </phrase>of <phrase diff="add">Assertions</phrase></quote>
+ <quote><phrase diff="add">An assertion author should reuse an existing assertion (rather than create a new one) whenever possible.</phrase></quote><phrase diff="del">assertions.
</phrase></p></div3></div2><div2 id="comparison"><head>Comparison of Nested and Parameterized Assertions</head><p>There are two different ways to provide additional information in an
assertion beyond its type. We cover these two cases below followed by a
comparison of these approaches targeting when to use either of the approach.
- </p><div3 id="parameterized-assertions"><head>Assertions with Parameters</head><p>The framework allows WS-Policy domain authors to define
- policy assertion parameters to qualify an assertion.
- Policy assertion parameters are defined <bibref ref="WS-Policy"/>.
- Policy assertion parameters are the opaque payload of an assertion.
- Assertion parameters carry additional useful pieces of information
- necessary for engaging the behavior described by an assertion.
- Assertion parameters are not considered when performing policy
- intersection unless domain specific compatibility processing
- semantics are specified by the assertion.
- In the XML representation of a policy assertion the child elements
- and attributes of the assertion excluding child elements and attributes
- from the policy xml language namespace are the assertion parameters.
- </p><p>In the example below, <code>sp:Body</code> and <code>sp:Header</code>
- elements are the two assertion parameters of the
- <code>sp:SignedParts</code> policy assertion
- (this assertion requires the parts of a message to be protected).
- </p><example><head>Policy Assertion with Assertion Parameters</head><eg xml:space="preserve"><wsp:Policy>
+ </p><div3 id="parameterized-assertions"><head>Assertions with Parameters</head><p><phrase diff="chg">Policy assertion parameters are the opaque payload </phrase><phrase diff="add">of</phrase><phrase diff="del">define
+ policy </phrase><phrase diff="chg">an </phrase><phrase diff="add">assertion.
+ Parameters</phrase><phrase diff="del">parameters </phrase><phrase diff="chg">carry additional useful </phrase><phrase diff="add">information</phrase><phrase diff="del">assertion.
+ Policy </phrase><phrase diff="chg">for engaging </phrase><phrase diff="add">the
+ behavior</phrase><phrase diff="del">are </phrase><phrase diff="chg">described </phrase><phrase diff="add">by an</phrase><phrase diff="del">.
+ Policy </phrase>assertion <phrase diff="chg">and </phrase>are <phrase diff="chg">preserved through </phrase><phrase diff="add">policy
+ processing</phrase><phrase diff="del">payload </phrase><phrase diff="chg">such as </phrase><phrase diff="add">normalize,</phrase><phrase diff="del">assertion.
+ Assertion </phrase><phrase diff="chg">merge and policy </phrase><phrase diff="add">intersection.
+ Requesters</phrase><phrase diff="del">useful </phrase><phrase diff="chg">may use </phrase><phrase diff="add">policy</phrase><phrase diff="del">information
+ necessary </phrase><phrase diff="chg">intersection to select a </phrase><phrase diff="add">compatible
+ policy</phrase><phrase diff="del">described </phrase><phrase diff="add">alternative for</phrase><phrase diff="del">by </phrase>an <phrase diff="chg">interaction. </phrase>Assertion parameters <phrase diff="chg">do </phrase>not
+ <phrase diff="add">affect </phrase><phrase diff="chg">the outcome of </phrase>policy intersection unless <phrase diff="add">the assertion specifies
+ </phrase>domain specific <phrase diff="del">compatibility </phrase>processing
+ <phrase diff="del">semantics are specified </phrase><phrase diff="chg">for policy </phrase><phrase diff="add">intersection.</phrase></p><p diff="add"><phrase diff="del">assertion.
+ </phrase>In the XML representation of a policy <phrase diff="chg">assertion, </phrase>the child elements
+ and attributes of the assertion excluding child elements and attributes
+ from the policy <phrase diff="del">xml </phrase>language namespace <phrase diff="add">name </phrase>are the assertion parameters.
+ </p><p role="practice" id="bp-assertion-parameters" diff="add"><quote><phrase diff="add">Use Parameters for Useful
+ Information</phrase></quote>
+ <quote><phrase diff="add">An assertion author should represent useful (or additional)
+ information necessary for engaging the behavior represented by a policy
+ assertion as assertion parameters.
+ </phrase></quote>
+ </p><p>In the example below, <code>sp:Body</code> and <code>sp:Header</code>
+ elements are the two assertion parameters of the
+ <code>sp:SignedParts</code> policy assertion
+ (this assertion requires the parts of a message to be protected).
+ <phrase diff="add">These
+
+
+ </phrase><phrase diff="del">Policy Assertion </phrase><phrase diff="chg">two parameters </phrase><phrase diff="add">identify</phrase><phrase diff="del">Parameters
+
+
+ Best </phrase><phrase diff="chg">the parts of a wire </phrase><phrase diff="add">message</phrase><phrase diff="del">for
+ specifying </phrase><phrase diff="chg">that should </phrase><phrase diff="add">be
+ protected.</phrase><phrase diff="del">of </phrase><phrase diff="chg">These parameters carry </phrase><phrase diff="add">additional</phrase><phrase diff="del">engaging
+ the </phrase><phrase diff="chg">useful information </phrase><phrase diff="add">for
+ engaging</phrase><phrase diff="del">by </phrase><phrase diff="chg">the </phrase><phrase diff="add">behavior.</phrase></p><example diff="add"><phrase diff="del">assertion </phrase><head><phrase diff="add">Policy</phrase><phrase diff="del">but </phrase><phrase diff="chg">Assertion with Assertion </phrase><phrase diff="add">Parameters</phrase></head><eg xml:space="preserve"><wsp:Policy>
<sp:SignedParts>
<sp:Body/>
<sp:Header/>
</sp:SignedParts>
-</wsp:Policy></eg></example><p role="practice" id="bp-assertion-definition" diff="add"><quote><phrase diff="add">Definition</phrase><phrase diff="del">Best </phrase><phrase diff="chg">of </phrase><phrase diff="add">Policy Assertions</phrase></quote><quote>Define policy assertion parameters for
- specifying useful pieces of information necessary for engaging
- the behavior described by an assertion but not relevant to policy
- intersection.</quote>
- </p></div3><div3 id="nested-assertions"><head>Nested Assertions</head><p>The framework provides the ability to "nest" policy assertions. For domains with a complex set of
+</wsp:Policy></eg></example><p diff="del">policy
+ intersection.
+
+
+ </p></div3><div3 id="nested-assertions"><head>Nested Assertions</head><p>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.
- </p><p>We will use the WS-SecurityPolicy to illustrate the use of nested assertions.
+ </p><p diff="add">
+ <phrase diff="add">The following design questions below can help
+ to determine when to use nested policy expressions:</phrase></p><ulist diff="add"><item><p><phrase diff="add">Are these assertions designed for the same policy subject? </phrase></p></item><item><p><phrase diff="add">Do these assertions represent dependent behaviors?</phrase></p></item></ulist><p diff="add"><phrase diff="add">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.</phrase></p><p role="practice" id="bp-dependent-behaviors" diff="add">
+ <quote><phrase diff="add">Use Nested Assertions for Dependent Behaviors</phrase></quote>
+ <quote><phrase diff="add">An assertion author should represent dependent behaviors that are relevant
+ to a compatibility test and apply to the same policy subject using
+ nested policy assertions.</phrase></quote></p><p role="practice" id="bp-declare-nested-assertions" diff="add">
+ <quote><phrase diff="add">Declare Nested Assertions</phrase></quote>
+ <quote><phrase diff="add">If there is a nested policy expression, an assertion description should declare it
+ and enumerate the nested policy assertions that are allowed.</phrase></quote></p><p diff="add"><phrase diff="add">The main consideration for selecting parameters or nesting
+ of assertions is that </phrase><emph><phrase diff="add">the framework intersection
+ algorithm processes nested alternatives, but does not consider
+ parameters in its algorithm</phrase></emph><phrase diff="add">.
+ </phrase></p><p diff="add"><phrase diff="add">Assertion Authors should recognize that the framework can
+ yield multiple assertions of the same type. The </phrase><emph><phrase diff="add">QName</phrase></emph>
+ <phrase diff="add">of the assertion is the only vehicle for the framework to
+ match a specific assertion, NOT the contents of the
+ element. If the assertion is a parameterized assertion the
+ authors must understand that this type of assertion will
+ require additional processing by consumers in order to
+ disambiguate the assertions or to understand the semantics of
+ the name value pairs, complex content, attribute values
+ contribution to the processing. The tradeoff is the generality
+ vs. the flexibility and complexity of the comparison expected for a domain. </phrase></p><p diff="add"><phrase diff="add">If the assertion
+ authors want to delegate the processing to the framework,
+ utilizing nesting should be considered. Otherwise, domain
+ specific comparison algorithms may need to be devised and be
+ delegated to the specific domain handlers that are not visible
+ to the WS-Policy framework. However, domain specific intersection processing reduces
+ interop and increases the burden to implement an assertion.</phrase></p><p role="practice" id="bp-discourage-domain-specific-intersection" diff="add">
+ <quote><phrase diff="add">Discourage Domain Specific Intersection</phrase></quote>
+ <quote><phrase diff="add">An
+ assertion description should only specify domain specific intersection
+ semantics when policy intersection is insufficient.</phrase></quote></p><p>We will use the WS-SecurityPolicy to illustrate the use of nested assertions.
</p><p>Securing messages is a complex usage scenario. The WS-SecurityPolicy Assertion Authors have defined the
<code>sp:TransportBinding</code> policy assertion to indicate
the use of transport-level security for protecting
@@ -562,9 +692,9 @@
<Policy>
<sp:TransportToken>
<Policy>
- <sp:HttpsToken>
- <wsp:Policy/>
- </sp:HttpsToken>
+ <sp:HttpsToken>
+ <wsp:Policy/>
+ </sp:HttpsToken>
</Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
@@ -611,36 +741,65 @@
</wsp:Policy>
</sp:TransportToken></eg></example><p>A non-anonymous client who requires authentication or client
certificate will not be able to use this provider solely on the basis
- of intersection algorithm alone.</p></div3><div3 id="which-one-to-use"><head>Considerations for choosing parameters vs nesting</head><p>The main consideration for selecting parameters or nesting
- of assertions is that <emph>the framework intersection
- algorithm processes nested alternatives, but does not consider
- parameters in its algorithm</emph>.
- </p><p>Assertion Authors should recognize that the framework can
- yield multiple assertions of the same type. The <emph>QName</emph>
- of the assertion is the only vehicle for the framework to
- match a specific assertion, NOT the contents of the
- element. If the assertion is a parameterized assertion the
- authors must understand that this type of assertion will
- require additional processing by consumers in order to
- disambiguate the assertions or to understand the semantics of
-
- the name value pairs, complex content, attribute values
- contribution to the processing. The tradeoff is the generality
- vs. the flexibility and complexity of the comparison expected for a domain. </p><p>
+ of intersection algorithm alone.</p></div3></div2><div2 id="Ignorable" diff="add"><head><phrase diff="add">Designating</phrase><phrase diff="del">Considerations for choosing parameters </phrase><phrase diff="chg">Ignorable Behavior</phrase></head><ednote><phrase diff="del">The main consideration for selecting parameters or nesting
+ </phrase><edtext><phrase diff="add">Looks</phrase><phrase diff="del">of assertions </phrase><phrase diff="add">incomplete</phrase><phrase diff="del">is that the framework </phrase><phrase diff="add">–</phrase><phrase diff="del">intersection
+ algorithm </phrase><phrase diff="chg">carries Good Practices </phrase>but <phrase diff="add">there</phrase><phrase diff="del">does not </phrase><phrase diff="add">isn’t</phrase><phrase diff="del">consider
+ parameters </phrase><phrase diff="chg">any explanatory </phrase><phrase diff="add">text.</phrase></edtext></ednote><p diff="del">algorithm.
+
+
+ </p><p><phrase diff="add">Policy</phrase><phrase diff="del">Assertion Authors should recognize that the </phrase><phrase diff="chg">assertions </phrase>can
+ <phrase diff="del">yield </phrase><phrase diff="chg">be marked with an attribute to indicate </phrase><phrase diff="add">that</phrase><phrase diff="del">QName
+ of </phrase>the assertion
+ <phrase diff="add">can </phrase><phrase diff="del">is the </phrase><phrase diff="chg">be ignored by </phrase>the <phrase diff="chg">interstection </phrase><phrase diff="add">algorithm.</phrase><phrase diff="del">to
+ match </phrase><phrase diff="chg">Assertion authors should </phrase><phrase diff="add">consider
+ whether</phrase><phrase diff="del">NOT </phrase>the <phrase diff="add">behavior</phrase><phrase diff="del">contents of </phrase><phrase diff="add">represented</phrase><phrase diff="del">the
+ element. </phrase><phrase diff="chg">by </phrase>the <phrase diff="add">Assertion</phrase><phrase diff="del">assertion is </phrase><phrase diff="chg">they are defining </phrase><phrase diff="add">can</phrase><phrase diff="del">the
+ authors </phrase><phrase diff="chg">be ignored for the purposes </phrase>of
+ <phrase diff="add">intersection, </phrase><phrase diff="del">assertion will
+ require </phrase><phrase diff="add">and</phrase><phrase diff="del">additional processing </phrase><phrase diff="chg">indicate this </phrase>in <phrase diff="del">order to
+ disambiguate the assertions or to understand </phrase>the <phrase diff="chg">definition </phrase>of
+ <phrase diff="del">the name value pairs, complex content, attribute values
+ contribution to </phrase>the <phrase diff="chg">assertion. </phrase>The <phrase diff="add">use</phrase><phrase diff="del">tradeoff is the generality
+ vs. the flexibility and complexity </phrase>of the
+ <phrase diff="add">ignorable </phrase><phrase diff="del">comparison expected for a domain.
+
The following design questions below can help
- to determine when to use nested policy expressions:</p><ulist><item><p>Are these assertions designed for the same policy subject? </p></item><item><p>Do these assertions represent dependent behaviors?</p></item></ulist><p>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. 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.</p><p role="practice" id="bp-nesting" diff="add"><quote><phrase diff="add">Nesting</phrase><phrase diff="del">Best </phrase><phrase diff="chg">of </phrase><phrase diff="add">Assertions</phrase></quote><quote>If the assertion
- authors want to delegate the processing to the framework,
- utilizing nesting should be considered. Otherwise, domain
+ to determine when </phrase><phrase diff="chg">attribute influences whether or </phrase><phrase diff="add">not</phrase><phrase diff="del">expressions:
+
+
+ Are </phrase><phrase diff="chg">certain </phrase>assertions <phrase diff="chg">are </phrase><phrase diff="add">part of</phrase><phrase diff="del">for </phrase>the
+ <phrase diff="add">compatability </phrase><phrase diff="chg">assessment between two </phrase><phrase diff="add">alternatives.
+
+
+ </phrase><phrase diff="del">Do </phrase><phrase diff="chg">See [tbd] for details </phrase><phrase diff="add">on</phrase><phrase diff="del">behaviors?
+
+
+ If </phrase>the <phrase diff="add">use
+ </phrase><phrase diff="del">answers are yes to both </phrase>of <phrase diff="add">the</phrase><phrase diff="del">these questions then leveraging nested </phrase><phrase diff="add">ignorable</phrase><phrase diff="del">policy
+ expressions </phrase><phrase diff="add">attribute.
+ </phrase></p><div3 id="doc-ignorable-assertions"><head><phrase diff="add">Assertions</phrase><phrase diff="del">is </phrase><phrase diff="chg">and Ignorable </phrase><phrase diff="add">Behavior</phrase></head><p role="practice" id="DefineIgnorable"><quote><phrase diff="add">Assertions</phrase><phrase diff="del">consider. </phrase><phrase diff="chg">Document Ignorable </phrase><phrase diff="add">Behavior</phrase></quote><phrase diff="del">mind </phrase><phrase diff="add">>
+ </phrase><quote><phrase diff="del">that </phrase><phrase diff="chg">An assertion description should use </phrase><phrase diff="del">in
+ </phrase>the <phrase diff="add">wsp:Ignorable</phrase><phrase diff="del">policy intersection algorithm. If a requester uses policy intersection </phrase><phrase diff="add">attribute
+ </phrase>to <phrase diff="add">indicate</phrase><phrase diff="del">select a
+ compatible policy alternative </phrase><phrase diff="chg">that </phrase>the <phrase diff="add">behavior</phrase><phrase diff="del">assertions in a nested policy expression play a
+ first class </phrase><phrase diff="chg">indicated by </phrase>the <phrase diff="add">QName</phrase><phrase diff="del">outcome. There is one caveat to watch out for: policy assertions
+ with deeply nested policy can greatly increase </phrase><phrase diff="chg">may be ignored by </phrase>policy <phrase diff="add">intersection.
+ </phrase></quote>
+ </p></div3><div3 id="XML-ignorable-assertions"><head><phrase diff="add">XML</phrase><phrase diff="del">and </phrase><phrase diff="chg">Outline </phrase><phrase diff="add">for</phrase><phrase diff="del">be
+ avoided </phrase><phrase diff="chg">Ignorable </phrase></head><p role="practice" id="ignorableAssertions"><phrase diff="del">they </phrase><quote><phrase diff="add">Ignorable</phrase><phrase diff="del">are </phrase><phrase diff="chg">Attribute </phrase><phrase diff="add">in</phrase><phrase diff="del">needed.
+ Best </phrase><phrase diff="add">XML</phrase></quote><phrase diff="del">practice: </phrase><phrase diff="add">>
+ </phrase><quote><phrase diff="del">If </phrase><phrase diff="chg">An </phrase>assertion
+ <phrase diff="del">authors want to delegate the processing </phrase><phrase diff="add">XML</phrase><phrase diff="del">to the framework,
+ utilizing </phrase><phrase diff="chg">outline </phrase>should <phrase diff="add">allow</phrase><phrase diff="del">be considered. Otherwise, domain
specific comparison algorithms may need to be devised and be
- delegated to the specific domain handlers that are not visible
- to the WS-Policy framework.</quote>
- </p></div3></div2><div2 id="optional-policy-assertion"><head>Designating Optional Behaviors</head><div3><head>Optional behavior in Compact authoring</head><p>Optional behaviors represent behaviors <phrase diff="chg">that </phrase>may be engaged by a consumer. When using the
+ delegated </phrase><phrase diff="chg">for </phrase>the <phrase diff="add">use</phrase><phrase diff="del">specific domain handlers </phrase><phrase diff="chg">of the wsp:Ignorable attribute
+ </phrase>to <phrase diff="chg">indicate ignorable </phrase><phrase diff="add">behavior.
+ </phrase></quote>
+ </p></div3></div2><p diff="del">framework.
+
+
+
+ </p><div2 id="optional-policy-assertion"><head>Designating Optional Behaviors</head><div3><head>Optional behavior in Compact authoring</head><p>Optional behaviors represent behaviors <phrase diff="chg">that </phrase>may be engaged by a consumer. When using the
compact authoring form for assertions, <phrase diff="add">such </phrase>behaviors are marked by
using <code>wsp:Optional</code> attribute <phrase diff="add">with</phrase><phrase diff="del">that has </phrase>a <phrase diff="add">value of
</phrase><phrase diff="del">value,
@@ -652,7 +811,7 @@
scenario, the choice of engaging the runtime behavior is upon
the consumer <phrase diff="add">by selecting</phrase><phrase diff="del">although </phrase>the <phrase diff="chg">appropriate policy </phrase><phrase diff="add">alternative.
The</phrase><phrase diff="del">capable </phrase><phrase diff="chg">provider may </phrase><phrase diff="add">influence</phrase><phrase diff="del">the
- runtime </phrase><phrase diff="chg">what is possible by choosing </phrase><phrase diff="add">whether or not</phrase><phrase diff="del">reference </phrase>to
+ runtime </phrase><phrase diff="chg">what is possible by choosing </phrase><phrase diff="add">whether or</phrase><phrase diff="del">reference </phrase><phrase diff="add">not </phrase>to
<phrase diff="add">include policy</phrase><phrase diff="del">such
assertions, </phrase><phrase diff="chg">alternatives in a policy expression, by </phrase><phrase diff="add">using
the</phrase><phrase diff="del">assertions </phrase><phrase diff="chg">wsp:Optional attribute. </phrase><phrase diff="add">An</phrase><phrase diff="del">section.
@@ -686,7 +845,7 @@
<phrase diff="del">would </phrase><phrase diff="chg">describes policy subjects and assertion attachment </phrase><phrase diff="add">should</phrase><phrase diff="del">self
describing. </phrase><phrase diff="add">indicate
that</phrase><phrase diff="del">For </phrase><phrase diff="chg">wsp:Optional can be used </phrase>to <phrase diff="add">indicate</phrase><phrase diff="del">a web service
- </phrase>that <phrase diff="chg">the behavior </phrase><phrase diff="add">is optional</phrase><phrase diff="del">must </phrase><phrase diff="chg">for </phrase>the <phrase diff="chg">policy </phrase><phrase diff="add">subject.</phrase></p><p role="practice" id="bp-assertion-description-explicitly-allow-optional" diff="add">
+ </phrase>that <phrase diff="add">the behavior</phrase><phrase diff="del">asserts </phrase><phrase diff="chg">is optional for </phrase>the <phrase diff="chg">policy </phrase><phrase diff="add">subject.</phrase></p><p role="practice" id="bp-assertion-description-explicitly-allow-optional" diff="add">
<quote><phrase diff="add">Assertion</phrase><phrase diff="del">format </phrase><phrase diff="chg">description </phrase><phrase diff="add">should</phrase><phrase diff="del">the
message </phrase><phrase diff="chg">explicitly indicate that wsp:Optional is </phrase><phrase diff="add">allowed.</phrase></quote>
<quote><phrase diff="add">An</phrase><phrase diff="del">message </phrase><phrase diff="chg">assertion </phrase><phrase diff="add">description</phrase><phrase diff="del">to
@@ -708,7 +867,8 @@
always be engaged by a consumer must not be marked as
"optional" with a value "true" since <phrase diff="add">this</phrase><phrase diff="del">presence of two
alternatives due to normalization </phrase><phrase diff="chg">would allow </phrase><phrase diff="add">the
- </phrase>consumer to <phrase diff="chg">select </phrase>the <phrase diff="add">policy </phrase>alternative that does not contain the assertion,
+ </phrase>consumer to
+ <phrase diff="del">choose </phrase><phrase diff="add">select </phrase>the <phrase diff="add">policy </phrase>alternative that does not contain the assertion,
and thus <phrase diff="del">making the behavior </phrase>not <phrase diff="add">engaging</phrase><phrase diff="del">being engaged in an interaction.
@@ -779,46 +939,46 @@
<quote><phrase diff="add">Consider
- </phrase><phrase diff="del">Best </phrase><phrase diff="chg">entire </phrase><phrase diff="add">message exchange pattern when specifying Assertions that may be</phrase><phrase diff="del">Optional </phrase><phrase diff="add">optional</phrase></quote>
+ </phrase><phrase diff="del">Best </phrase><phrase diff="chg">entire </phrase><phrase diff="add">message exchange pattern when specifying Assertions that</phrase><phrase diff="del">Optional </phrase><phrase diff="add">may be optional</phrase></quote>
<quote>Assertion Authors should <phrase diff="chg">associate </phrase><phrase diff="add">optional assertions with the appropriate endpoint and use the smallest
possible granularity to limit the degree to which optionality applies.</phrase></quote>
</p><p>
<phrase diff="add">Behaviors must be engaged
- with respect</phrase><phrase diff="del">state
- how </phrase><phrase diff="add">to messages that are targeted to the provider
- so that the provider can determine that </phrase>the <phrase diff="add">optional
+ with respect to messages that are targeted to the provider
+ so that the provider can</phrase><phrase diff="del">state
+ how </phrase><phrase diff="add">determine that </phrase>the <phrase diff="add">optional
</phrase>behavior <phrase diff="add">is engaged. In other words, the need for self
describing messages [</phrase><specref ref="self-describing"/><phrase diff="add">] should
not be forgotten.
An explicit, out of band mechanism might be necessary to enable a
client to indicate </phrase>that
<phrase diff="add">the optional behavior </phrase>is <phrase diff="add">engaged.
- (Such an</phrase><phrase diff="del">enabled </phrase><phrase diff="add">out of band mechanism is outside the scope</phrase><phrase diff="del">by </phrase><phrase diff="add">of WS-Policy
+ (Such an</phrase><phrase diff="del">enabled </phrase><phrase diff="add">out of band mechanism is outside the scope of WS-Policy
Framework).
</phrase></p><p role="practice" id="bp-indicate-optional-assertion-use">
<quote><phrase diff="add">Indicate use of an Optional Assertion</phrase></quote>
- <quote><phrase diff="add">When a given behavior may be optional, it must be possible for both message participants to determine that </phrase>the assertion <phrase diff="add">is selected by both parties,
- either out of band or as reflected by the message content.</phrase></quote>
+ <quote><phrase diff="add">When a given behavior may be optional, it must be possible for both message participants to</phrase><phrase diff="del">by </phrase><phrase diff="add">determine that </phrase>the assertion <phrase diff="add">is selected by both parties,
+ either out of band or as</phrase><phrase diff="del">would </phrase><phrase diff="add">reflected by the message content.</phrase></quote>
</p><div4><head><phrase diff="add">Example</phrase></head><p>
<phrase diff="add">The </phrase><bibref ref="WS-Policy-Primer"/> <phrase diff="add">document contains an example that outlines the
use of
- </phrase><bibref ref="MTOM"/> <phrase diff="add">as an optional</phrase><phrase diff="del">would </phrase><phrase diff="add">behavior that can </phrase>be engaged <phrase diff="add">by a consumer.
+ </phrase><bibref ref="MTOM"/> <phrase diff="add">as an optional behavior that can </phrase>be engaged <phrase diff="add">by a consumer.
Related to this
behavior is an assertion that identifies the use of MIME Multipart/Related
- serialization [</phrase><bibref ref="MTOMPolicy"/><phrase diff="add">]. Policy-aware clients that recognize and engage this</phrase><phrase diff="del">when </phrase><phrase diff="add">policy
+ serialization [</phrase><bibref ref="MTOMPolicy"/><phrase diff="add">]. Policy-aware clients that recognize and engage this policy
assertion will use Optimized MIME Serialization for messages.
</phrase></p><p>
- <phrase diff="add">The semantics of the MTOM assertion declare that the behavior must be reflected in
- messages by requiring that </phrase>they <phrase diff="chg">use an obvious </phrase><phrase diff="add">wire format (MIME Multipart/Related
+ <phrase diff="add">The semantics of the</phrase><phrase diff="del">when </phrase><phrase diff="add">MTOM assertion declare that the behavior must be reflected in
+ messages by requiring that </phrase>they <phrase diff="add">use an</phrase><phrase diff="del">are </phrase><phrase diff="chg">obvious wire </phrase><phrase diff="add">format (MIME Multipart/Related
serialization). Thus, this optional behavior is self describing. For example, an
inbound message to a web service that requires MTOM must adhere to Optimized MIME
- Serialization. By examining the message, the provider can determine</phrase><phrase diff="del">assertion, </phrase>whether <phrase diff="add">the</phrase><phrase diff="del">by
+ Serialization. By examining the message, the provider</phrase><phrase diff="del">assertion, </phrase><phrase diff="add">can determine </phrase>whether <phrase diff="add">the</phrase><phrase diff="del">by
specific </phrase><phrase diff="add">policy
- alternate</phrase><phrase diff="del">headers </phrase><phrase diff="chg">that contains the </phrase><phrase diff="add">MTOM assertion is being obeyed (
+ alternate</phrase><phrase diff="del">headers </phrase><phrase diff="chg">that contains the MTOM </phrase><phrase diff="add">assertion is being obeyed (
</phrase><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-indicate-optional-assertion-use" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Good Practice: Indicate use of an Optional Assertion</phrase></loc><phrase diff="add">).
</phrase></p><p>
<phrase diff="add">Note that if a MTOM assertion were only bound to an inbound message endpoint,
- then it would not be clear whether the outbound message from</phrase><phrase diff="del">means. </phrase><phrase diff="add">the provider</phrase><phrase diff="del">See </phrase><phrase diff="add">would
+ then it would not be clear</phrase><phrase diff="del">See </phrase><phrase diff="add">whether the outbound message from the provider would
</phrase>also <phrase diff="add">utilize the behavior. Thus this assertion should be associated at the granularity
of an entire message exchange. The semantics of the assertion should specify this
to avoid inappropriate assumptions by implementations. This is important for an
@@ -826,40 +986,62 @@
exchange when optionally used in part of that exchange
(</phrase><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="#bp-entire-mep-for-optional" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Good Practice: Consider entire message exchange pattern when specifying Assertions that may be optional</phrase></loc><phrase diff="add">).
</phrase><phrase diff="del">.
- </phrase></p></div4></div3></div2><div2 id="levels-of-abstraction"><head>Levels of Abstraction in WSDL </head><p>A behavior identified by a policy assertion applies to the
+ </phrase></p></div4></div3></div2><div2 id="levels-of-abstraction"><head><phrase diff="chg">Considerations </phrase><phrase diff="add">for Policy</phrase><phrase diff="del">of </phrase><phrase diff="chg">Attachment </phrase>in WSDL </head><p>A behavior identified by a policy assertion applies to the
associated policy subject. If a policy assertion is to be used
- within WSDL, Assertion Authors must specify a WSDL
- policy subject. The policy subject is determined with respect
- to a behavior as follows:
+ within WSDL, <phrase diff="chg">assertion authors </phrase>must specify a WSDL
+ policy subject.
+ </p><p diff="add"> The <phrase diff="add">specific WSDL </phrase>policy subject is determined with respect
+ to
+ a behavior as follows:
</p><ulist><item><p>If the behavior applies to any message exchange
using any of the endpoints offered by a service then the
subject is the service policy subject. </p></item><item><p>If the behavior applies to any message exchange
made using an endpoint then the subject is the endpoint policy subject. </p></item><item><p>If the behavior applies to any message exchange
defined by an operation then the subject is the operation policy subject. </p></item><item><p>If the behavior applies to an input message then
- the subject is the message policy subject - similarly for output and fault message policy subjects.</p></item></ulist><p>Assertion Authors that wish to utilize WSDL policy subjects need to understand how the assertions will be
- processed in intersection and merging and the implications of
- the processing for considering a specific attachment point and
- policy subject. This topic is considered in detail in <bibref ref="WS-Policy-Primer"/>
- </p><p>The current set of subjects as mapped to the WSDL 1.1
- elements, can also constrain the assertion constructs. For Example, In WS-RM,
- the Assertion Authors chose to support certain capabilities at
- the endpoint level. This resulted in the finer granularity of
- the assertion to apply at the message policy subject, but the
+ the subject is the message policy subject - similarly for output and fault message policy subjects.</p></item></ulist><p role="practice" id="bp-WSDL-policy-subject" diff="add">
+ <quote>
+ Assertion <phrase diff="add">Description</phrase><phrase diff="del">Authors that wish to utilize </phrase><phrase diff="chg">Should Specify a Policy </phrase><phrase diff="add">Subject</phrase></quote>
+ <quote><phrase diff="add">Assertion</phrase><phrase diff="del">to </phrase><phrase diff="chg">authors should associate </phrase>assertions <phrase diff="add">with</phrase><phrase diff="del">will be
+ processed in intersection and merging and </phrase>the <phrase diff="chg">appropriate </phrase><phrase diff="add">policy</phrase><phrase diff="del">of
+ the </phrase><phrase diff="add">subject.
+ For</phrase><phrase diff="del">processing </phrase><phrase diff="chg">instance, if </phrase>a <phrase diff="del">specific attachment point and
+ </phrase>policy <phrase diff="add">assertion</phrase><phrase diff="del">subject. This topic </phrase>is <phrase diff="del">considered in detail in
+
+ The current set of subjects as mapped </phrase>to <phrase diff="add">be</phrase><phrase diff="del">the WSDL 1.1
+ elements, </phrase><phrase diff="chg">used with WSDL, </phrase>the assertion <phrase diff="add">description
+ should</phrase><phrase diff="del">constructs. For Example, In WS-RM,
+ the Assertion Authors </phrase><phrase diff="chg">specify a WSDL policy subject </phrase><phrase diff="add">–</phrase><phrase diff="del">at
+ the </phrase><phrase diff="chg">such as service, endpoint, operation and </phrase><phrase diff="add">message.
+ </phrase></quote>
+ </p><p diff="add"><phrase diff="add">Assertion</phrase><phrase diff="del">finer </phrase><phrase diff="chg">authors </phrase><phrase diff="add">that</phrase><phrase diff="del">of
+ the </phrase><phrase diff="chg">wish </phrase>to <phrase diff="add">utilize</phrase><phrase diff="del">apply at the </phrase><phrase diff="chg">WSDL </phrase>policy <phrase diff="add">subjects</phrase><phrase diff="del">subject, but the
assertion semantics also indicates that the if
- a sender chose to engage RM
- semantics (although not specified via attachment in WSDL at incoming
- messages), the providers will honor the engagement of RM.
+ a sender </phrase><phrase diff="chg">need </phrase>to
+ <phrase diff="add">understand </phrase><phrase diff="del">engage RM
+ semantics (although not specified via attachment in WSDL at </phrase><phrase diff="add">how</phrase><phrase diff="del">incoming
+ messages), </phrase>the <phrase diff="chg">assertions </phrase>will <phrase diff="add">be
+ processed</phrase><phrase diff="del">honor the engagement of RM.
This is illustrative of how the
- assertion author can specify additional constraints and
- assumptions for attachment and engagement of behavior.
- </p><p>If the capability is not really suitable and may imply
- different semantics with respect to attachment points, the
- Assertion Authors should consider the following</p><ulist><item><p> Decompose the semantics with several assertions </p></item><item><p> Rewrite a single assertion targeting a specific subject. </p></item></ulist><p> For a given WSDL policy subject, there may be several
+ assertion author can </phrase><phrase diff="chg">in an intersection </phrase>and
+ <phrase diff="del">assumptions for </phrase><phrase diff="chg">merging, </phrase>and <phrase diff="chg">the implications </phrase><phrase diff="add">of</phrase><phrase diff="del">behavior.
+
+ If </phrase>the <phrase diff="add">processing</phrase><phrase diff="del">capability is not really suitable and may imply
+ different </phrase><phrase diff="chg">for considering a specific </phrase>attachment <phrase diff="add">point</phrase><phrase diff="del">points, the
+ Assertion Authors should consider the </phrase><phrase diff="add">and</phrase><phrase diff="del">following
+ </phrase><phrase diff="add">policy
+
+ </phrase><phrase diff="del">Decompose the semantics with several assertions
+
+
+ </phrase><phrase diff="chg">subject. This topic is considered in detail in </phrase><bibref ref="WS-Policy-Primer"/>
+
+
+ </p><p> For a given WSDL policy subject, there may be several
attachment points. For example, there are three attachment
points for the endpoint policy subject: the port, binding and
- portType element. Assertion Authors should identify the
+ portType element. Assertion <phrase diff="chg">authors </phrase>should identify the
relevant attachment point when defining a new assertion. To
- determine the relevant attachment points, Assertion Authors should
+ determine the relevant attachment points, <phrase diff="chg">assertion authors </phrase>should
consider the scope of the attachment point. For example, an
assertion should only be allowed in the portType element if
the assertion reasonably applies to any endpoint that ever
@@ -868,34 +1050,101 @@
</p><p> In using WSDL attachment, it should be noted that the
service policy subject is a collection of endpoint policy
subjects. The endpoint policy subject is a collection of
- operation policy subjects and etc. As a result, the WSDL
+ operation policy subjects and <phrase diff="chg">so </phrase><phrase diff="add">on. </phrase>As a result, the WSDL
policy subjects compose naturally. It is quite tempting to
associate the identified behavior to a broader policy subject
than to a fine granular policy subject. For instance, it is
convenient to attach a supporting token assertion (defined by
the Web Services Security Policy specification) to an endpoint
- policy subject instead of a message policy subject. Similarly,
- for authoring convenience, an assertion author may allow the
+ policy subject instead of a message policy subject. <phrase diff="add">However such
+ policy attachments to policy subjects of broader scope and granularity
+ should be done only after careful evaluation.
+ </phrase></p><p role="practice" id="bp-WSDL-policy-subject-Granularity" diff="add">
+ <quote><phrase diff="add">Choose a Granular Policy Subject</phrase></quote>
+ <quote><phrase diff="add">Assertion authors should choose the most granular policy subject
+ that the behavior represented by a policy assertion applies to.
+ </phrase></quote>
+ </p><p diff="add"><phrase diff="del">Similarly,
+ </phrase><phrase diff="chg">For </phrase>authoring convenience, an assertion author may allow the
association of an assertion to multiple policy subjects. If an
assertion is allowed to be associated with multiple policy
- subjects then <emph>the assertion author has the burden to
- describe the semantics of multiple instances of the same
- assertion attached to multiple policy subjects at the same
- time in order to avoid conflicting behavior. </emph>
- </p><p>One approach is to specify a policy subject, choose the
- most granular policy subject that the behavior applies to and
- specify a preferred attachment point in WSDL. However, this
- approach only works if the policy subject is a true WSDL
+ subjects <phrase diff="add">as is possible with WSDL, </phrase>then the assertion author has
+ the burden to describe the semantics of multiple instances of the same assertion attached to <phrase diff="chg">different </phrase>policy subjects at the same
+ time in order to avoid conflicting behavior.
+ </p><p role="practice" id="bp-WSDL-multiple-policy-subjects" diff="add">
+ <quote><phrase diff="add">Define Semantics of Attachment to Multiple Policy Subjects</phrase></quote>
+ <quote><phrase diff="add">If an assertion is allowed to be associated with multiple policy
+ subjects, the assertion description should describe the semantics of multiple
+ instances of the same assertion attached to multiple policy subjects
+ at the same time.
+ </phrase></quote>
+ </p><p diff="add"><phrase diff="add">If the capability is not really suitable and may imply
+ different semantics with respect to attachment points, the
+ assertion authors should consider the following:</phrase></p><ulist diff="add"><item><p><phrase diff="del">One </phrase><phrase diff="add">Decompose the semantics with several assertions.</phrase></p></item><item><p> <phrase diff="add">Rewrite a single assertion targeting a specific subject. </phrase></p></item></ulist><p diff="add">
+ <ednote><edtext>
+ <phrase diff="add">The following paragraph is likely to change,
+ as there is an issue 4074, open against this paragraph.
+ </phrase></edtext></ednote>
+ </p><p diff="add"><phrase diff="add">The current set of subjects as mapped to the WSDL 1.1
+ elements, can also constrain the assertion constructs.
+ For Example, in WS-RM, the assertion authors chose to support
+ certain capabilities at the endpoint level. This resulted in
+ the finer granularity of the assertion to apply at the message
+ policy subject, but the assertion semantics also indicates that
+ the if a sender chose to engage RM</phrase><phrase diff="del">approach </phrase><phrase diff="add">semantics (although not specified
+ via attachment in WSDL at incoming messages), the providers will honor
+ the engagement of RM. So, the WS-RM Policy </phrase>is <phrase diff="add">a capability that
+ governs a target endpoints capability </phrase>to <phrase diff="add">accept sequences that
+ is beyond single message exchanges. This is illustrative of how the
+ assertion author can </phrase>specify <phrase diff="add">additional constraints and assumptions
+ for attachment and engagement of behavior. Such additional constraints
+ must be clearly specified by the assertion authors.
+ </phrase></p><p diff="add"><phrase diff="add">Since many attachment points are available in WSDL, it would be
+ necessary for an assertion author to recommend a preferred attachment
+ point. One approach would be to identify different attachment points in
+ </phrase>a policy subject, choose the most granular policy subject that the
+ behavior applies to and specify <phrase diff="add">that as </phrase>a preferred attachment <phrase diff="add">point.
+ </phrase><phrase diff="del">point in WSDL. </phrase>However, this approach only works if the policy subject is a true WSDL
construct other than some other protocol concept that is
- layered over WSDL message exchanges. For example, the WS-RM
- Policy is a capability that governs a target endpoints
- capability to accept sequences that is beyond single message
- exchanges. Therefore, its semantics encompasses the cases when
+ layered over WSDL message exchanges. For example, <phrase diff="add">as described previously
+ </phrase>the WS-RM Policy is a capability that governs a target <phrase diff="chg">endpoint's
+ </phrase>capability to accept <phrase diff="add">message </phrase>sequences that <phrase diff="chg">are </phrase>beyond single message
+ <phrase diff="chg">exchange. </phrase>Therefore, its semantics <phrase diff="chg">encompass </phrase>the cases when
message level policy subjects may be used as attachment but
- considers when sequences are present. In addition, when the
- policy assertions do not target wire-level behaviors but
+ <phrase diff="add">also </phrase>considers <phrase diff="add">the case </phrase>when sequences are present. In addition,
+ when the policy assertions do not target wire-level behaviors but
rather abstract requirements, this technique does not apply.
- </p></div2><div2 id="interrelated-domains"><head>Interrelated domains</head><p>Assertion authors need to be clear about how assertions defined in
+ </p><p role="practice" id="bp-WSDL-preferred-attachment-point" diff="add">
+ <quote><phrase diff="add">Specify Preferred Attachment Point for an Assertion</phrase></quote>
+ <quote><phrase diff="add">If an assertion can be attached at multiple points within a policy
+ subject, an assertion author should specify a preferred attachment
+ point for the chosen policy subject.
+ </phrase></quote>
+ </p><p diff="add"><phrase diff="add">Assertion authors that utilize WSDL policy subjects need to
+ understand how the assertions will be processed in merging and
+ the specify implications of ending up with multiple assertions of
+ the same kind in an alternative, in the merged policy. For example,
+ consider the SignedParts assertion defined in WS-SecurityPolicy 1.2.
+ The definition of SignedParts assertion explicitly permits multiple
+ SignedParts assertions to be present within a policy alternative,
+ and declares it to be equivalent to a single SignedParts assertion
+ containing the union of all specified message parts. So, if a SignedParts
+ assertion is specified in a WSDL binding at the input message level
+ and subsequently an additional SignedParts assertion is specified
+ at the WSDL endpoint policy subject level, then the effective policy
+ at the endpoint could have more than one SignedParts assertion in the
+ same alternative. However, the clear semantics defined by the SignedParts
+ assertion enable processing of the multiple occurrences properly.
+ </phrase></p><p role="practice" id="bp-WSDL-policy-multiple-instance-semantics" diff="add">
+ <quote><phrase diff="add">Describe Semantics of Multiple Assertions of Same Kind</phrase></quote>
+ <quote><phrase diff="add">A policy alternative can contain multiple instances of the
+ same policy assertion. An assertion description should specify the
+ semantics of multiple instances of a policy assertion in the same
+ policy alternative and the semantics of parameters and nested policy
+ (if any) when there are multiple instances of a policy assertion in
+ the same policy alternative.
+ </phrase></quote>
+ </p></div2><div2 id="interrelated-domains"><head>Interrelated domains</head><ednote diff="add"><edtext><phrase diff="add">To be re-structured to use the format in the Architecture of the WWW doc.</phrase></edtext></ednote><p>Assertion authors need to be clear about how assertions defined in
their domain may fit with assertions for interrelated domains. A
classic example of such an interrelated domain is security, because
security tends to
@@ -906,7 +1155,11 @@
Assertions [<bibref ref="WS-RM-Policy"/>]. </p><p>Assertion authors should not duplicate existing
assertions and should also make sure that when adding assertions those new assertions are consistent
with pre-existing assertions of any
- interrelated domain. </p></div2></div1><div1 id="versioning-policy-assertions"><head>Versioning Policy Assertions</head><p>Assertion Authors need to consider not just the expression of the current set of requirements but
+ interrelated domain. </p><p role="practice" id="bp-specify-composition" diff="add">
+ <quote><phrase diff="add">Specify Composition with Related Assertions</phrase></quote>
+ <quote><phrase diff="add">An assertion description should clearly specify how the assertion may compose
+ with other related assertions, if any.</phrase></quote>
+ </p></div2></div1><div1 id="versioning-policy-assertions"><head>Versioning Policy Assertions</head><p>Assertion Authors need to consider not just the expression of the current set of requirements but
how they anticipate new assertions being added to the set. There are three aspects to versioning policy assetions:</p><ulist><item><p> Assertion Extensibility </p></item><item><p> Policy Language Extensibility </p><p>Over time, the Policy WG or third parties can version or extend the Policy Language with new
or modified constructs. These constructs may be compatible or incompatible with previous versions.
</p><p> Assertion Authors should review the WS-Policy Primer <bibref ref="WS-Policy-Primer"/>
@@ -931,7 +1184,10 @@
vs. 1.1 and WS-Addressing August 2004 version vs. WS-Addressing W3C Recommendation
[<bibref ref="WS-Addressing"/>]. These equivalent behaviors
are mutually exclusive for an interaction. Such equivalent
- behaviors can be modeled as independent assertions. </p><p role="practice" id="bp-independent-assertions" diff="add"><quote><phrase diff="add">Independent Assertions</phrase></quote><quote><phrase diff="add">An assertion author should use independent assertions for modeling multiple versions of a behavior.</phrase></quote></p><p diff="add">The
+ behaviors can be modeled as independent assertions. </p><p role="practice" id="bp-independent-assertions" diff="add">
+ <quote><phrase diff="add">Use Independent Assertions for Multiple Versions of a Behavior</phrase></quote>
+ <quote><phrase diff="add">An assertion author should use independent assertions for modeling multiple
+ versions of a behavior.</phrase></quote></p><p diff="add">The
policy expression in the example below requires the use of
WSS: SOAP Message Security 1.0. </p><example><head>Message-level Security and WSS: SOAP Message Security 1.0</head><eg xml:space="preserve"><Policy>
<sp:Wss10>…</sp:Wss10>
@@ -1323,25 +1579,23 @@
The people who have contributed to <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://lists.w3.org/Archives/Public/public-ws-policy/" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace">discussions
on public-ws-policy@w3.org</loc> are also gratefully
acknowledged.
- </p></inform-div1><inform-div1 id="change-description"><head>Changes in this Version of
- the Document</head><p>A list of substantive changes since the Working Draft dated <phrase diff="chg">30 March,
+ </p></inform-div1><inform-div1 id="change-description"><head>Changes in this Version of the Document</head><p>A list of substantive changes since the Working Draft dated <phrase diff="chg">30 March,
2007 </phrase>is below:</p><ulist><item><p diff="del">Rewrote section and added two new best practices:
- An assertion description should specify a policy subject.
- </p><p><phrase diff="add">Editorial</phrase><phrase diff="del">If the policy subjects change over time, the assertion description
- should also be </phrase><phrase diff="chg">changes </phrase>to <phrase diff="add">align</phrase><phrase diff="del">reflect this change.
-
-
- Rewrote section and added a new best practice:
- the semantics of an assertion should be independent of the form (compact or normal form)
- of policy expressions that contain the assertion.
- Rewrote section .
- Rewrote section and added a new best practice:
- the semantics a policy assertion should not depend on the attachment mechanism used.
- Dropped section
- 4.6 </phrase><phrase diff="add">with</phrase><phrase diff="del">Typing
- Assertions.
- Clarified </phrase>the <phrase diff="add">OASIS</phrase><phrase diff="del">semantics of an empty nested policy expression </phrase><phrase diff="chg">WS-SecurityPolicy </phrase><phrase diff="add">specification.</phrase><phrase diff="del">.</phrase></p></item></ulist></inform-div1><inform-div1 id="change-log"><head>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</head><table id="ws-policy-primer-changelog-table" border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><!-- template
+ </p><p><phrase diff="add">Reformatted</phrase><phrase diff="del">An assertion description should specify a policy subject.
+ If </phrase>the <phrase diff="add">document</phrase><phrase diff="del">policy subjects change </phrase><phrase diff="chg">to follow </phrase>the <phrase diff="add">model</phrase><phrase diff="del">assertion description
+ should also be versioned </phrase><phrase diff="chg">of </phrase><phrase diff="add">the
+ </phrase><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/webarch/#uri-benefits" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace" diff="add"><phrase diff="add">WWW</phrase><phrase diff="del">reflect </phrase><phrase diff="chg">Architecture </phrase><phrase diff="add">Document.</phrase></loc><phrase diff="del">change.
+ </phrase></p></item><item><p><phrase diff="add">Created</phrase><phrase diff="del">Rewrote section and added </phrase>a <phrase diff="add">consolidated</phrase><phrase diff="del">new best practice:
+ the </phrase><phrase diff="chg">list </phrase>of <phrase diff="add">good</phrase><phrase diff="del">an assertion should be </phrase><phrase diff="chg">practices at </phrase>the <phrase diff="add">beginning</phrase><phrase diff="del">form (compact or normal form)
+ </phrase>of <phrase diff="del">policy expressions that contain </phrase>the <phrase diff="add">document
+ (</phrase><specref ref="best-practices-list" diff="add"/><phrase diff="add">).
+ </phrase><phrase diff="del">assertion.</phrase></p><p diff="del">Rewrote section .</p></item><item><p><phrase diff="add">Incorporated</phrase><phrase diff="del">Rewrote section and added a new best practice:
+ </phrase>the <phrase diff="add">good</phrase><phrase diff="del">semantics a policy assertion should not depend on the </phrase><phrase diff="chg">practices </phrase><phrase diff="add">from
+ </phrase><loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace" diff="add"><phrase diff="add">IBM/Microsoft</phrase><phrase diff="del">mechanism </phrase><phrase diff="add">Contibution.</phrase></loc>
+ <phrase diff="del">used.</phrase></p><p diff="del">Dropped section
+ 4.6 Typing
+ Assertions.</p></item><item><p><phrase diff="add">Made</phrase><phrase diff="del">Clarified the </phrase><phrase diff="chg">editorial changes to align with the OASIS WS-SecurityPolicy </phrase><phrase diff="add">specification.</phrase><phrase diff="del">.</phrase></p></item></ulist></inform-div1><inform-div1 id="change-log"><head>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</head><table id="ws-policy-primer-changelog-table" border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><!-- template
<tr>
<td>200505</td>
<td></td>
@@ -1455,4 +1709,60 @@
as noted in <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0069.html" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">message 69</phrase></loc>.
Also replaced TBD in section 2 with descriptive text."
</td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070501</td><td rowspan="1" colspan="1" diff="add">ASV</td><td rowspan="1" colspan="1" diff="add">Reset Section <specref ref="change-description"/>.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070507</td><td rowspan="1" colspan="1" diff="add">PY</td><td rowspan="1" colspan="1" diff="add">Updated 5.6 WSDL guidelines section, to follow the new format and added G15, G16, G17 and G18.
+ Accounts for parts of resolution for
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">issue 3989</phrase></loc>
+ corresponding to editors' action items
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">232</phrase></loc>,
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">253</phrase></loc>, and
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">256</phrase></loc>.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070507</td><td rowspan="1" colspan="1" diff="add">TIB</td><td rowspan="1" colspan="1" diff="add">Updated 5.1 Assertions and their Target Use for
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">issue 3989</phrase></loc>
+ and editors' action item
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/227" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">227</phrase></loc>.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070508</td><td rowspan="1" colspan="1" diff="add">MH</td><td rowspan="1" colspan="1" diff="add">Updated Section 5 for adding guidelines G9, G10 on ignorable, and G5 , G6 (general)
+ to address editors' action items
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/251" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">251</phrase></loc>.
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/256" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">256</phrase></loc>.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070511</td><td rowspan="1" colspan="1" diff="add">PY</td><td rowspan="1" colspan="1" diff="add">Updated 5.6 WSDL guidelines section to add G19 identified in AI 256 (now G24).
+ Accounts for parts of resolution for
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">issue 3989</phrase></loc>
+ corresponding to editors' action item
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">256</phrase></loc>
+ - now complete.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070513</td><td rowspan="1" colspan="1" diff="add">ASV</td><td rowspan="1" colspan="1" diff="add">Updated Section 5.4.1 to use the new format re issue
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">issue 3989</phrase></loc>.
+ Editors' action
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/230" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">230</phrase></loc>.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070514</td><td rowspan="1" colspan="1" diff="add">ASV</td><td rowspan="1" colspan="1" diff="add">Updated Section 5.4.2 to use the new format re issue
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">issue 3989</phrase></loc>.
+ Editors' action
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/230" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">230</phrase></loc>.
+ Collapsed Section 5.4.2 and 5.4.3.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070514</td><td rowspan="1" colspan="1" diff="add">ASV</td><td rowspan="1" colspan="1" diff="add">Added G11 and G13 to Section 5.4.1 and 5.4.2 re issue
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">issue 3989</phrase></loc>.
+ Editors' action
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/252" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">252</phrase></loc> and
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/255" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">255</phrase></loc>.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070516</td><td rowspan="1" colspan="1" diff="add">PY</td><td rowspan="1" colspan="1" diff="add">Editorial change to section 5.7 to place best practices after the associated
+ explanatory text and to fix grammar.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070518</td><td rowspan="1" colspan="1" diff="add">PY</td><td rowspan="1" colspan="1" diff="add">Ensured Good Practices G1, G3 and G20 of
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">original IBM/MS Contribution</phrase></loc>
+ are reflected.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070518</td><td rowspan="1" colspan="1" diff="add">PY</td><td rowspan="1" colspan="1" diff="add">Updated Appendix E, Changes in this Version of the Document
+ (<specref ref="change-description"/>).
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070520</td><td rowspan="1" colspan="1" diff="add">ASV</td><td rowspan="1" colspan="1" diff="add">Added Good Practice <specref ref="bp-specify-composition"/> (from
+ the <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">IBM
+ and MS Contribution</phrase></loc> to
+ <specref ref="interrelated-domains"/>. Added an ed note that
+ Section <specref ref="interrelated-domains"/> needs to be re-structured.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070520</td><td rowspan="1" colspan="1" diff="add">ASV</td><td rowspan="1" colspan="1" diff="add">Added Good Practice <specref ref="bp-not-necessary-to-understand-a-message"/> (from
+ the <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf" xlink:type="simple" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">IBM
+ and MS Contribution</phrase></loc> to
+ <specref ref="self-describing"/>.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070520</td><td rowspan="1" colspan="1" diff="add">ASV</td><td rowspan="1" colspan="1" diff="add">Added an ed note that
+ Section <specref ref="Ignorable"/> looks incomplete.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070520</td><td rowspan="1" colspan="1" diff="add">ASV</td><td rowspan="1" colspan="1" diff="add">Fixed typos.
+ </td></tr><tr diff="add"><td rowspan="1" colspan="1" diff="add">20070520</td><td rowspan="1" colspan="1" diff="add">ASV</td><td rowspan="1" colspan="1" diff="add">Added an ed note in Section <specref ref="assertion-target"/> that
+ there is an open issue against Good Practice G2.
</td></tr></tbody></table></inform-div1></back></spec>
\ No newline at end of file
Index: ws-policy-guidelines-diff20070330.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines-diff20070330.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-guidelines-diff20070330.html 1 May 2007 23:30:36 -0000 1.2
+++ ws-policy-guidelines-diff20070330.html 21 May 2007 01:54:33 -0000 1.3
@@ -94,7 +94,7 @@
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1. <a href="#introduction">Introduction</a><br>
2. <a href="#best-practices-list">List of Good Practice Statements</a><br>
3. <a href="#Assertions">What is an Assertion? </a><br>
-4. <a href="#d2e266">Who is involved in authoring Assertions? </a><br>
+4. <a href="#d2e271">Who is involved in authoring Assertions? </a><br>
4.1 <a href="#roles"> Roles and Responsibilities </a><br>
4.1.1 <a href="#domain-owners"> Assertion Authors</a><br>
4.1.2 <a href="#consumers">Consumers</a><br>
@@ -110,13 +110,16 @@
5.4 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br>
5.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br>
[...1062 lines suppressed...]
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf"><span class="diff-add"><span>original IBM/MS Contribution</span></span></a>
+ are reflected.
+ </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20070518</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">PY</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Updated Appendix E, Changes in this Version of the Document
+ (<a href="#change-description"><b>E. Changes in this Version of the Document</b></a>).
+ </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20070520</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">ASV</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Added Good Practice <b><a href="#bp-specify-composition">???</a></b> (from
+ the <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf"><span class="diff-add"><span>IBM
+ and MS Contribution</span></span></a> to
+ <a href="#interrelated-domains"><b>5.8 Interrelated domains</b></a>. Added an ed note that
+ Section <a href="#interrelated-domains"><b>5.8 Interrelated domains</b></a> needs to be re-structured.
+ </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20070520</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">ASV</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Added Good Practice <b><a href="#bp-not-necessary-to-understand-a-message">???</a></b> (from
+ the <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf"><span class="diff-add"><span>IBM
+ and MS Contribution</span></span></a> to
+ <a href="#self-describing"><b>5.3.3 Self Describing Messages </b></a>.
+ </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20070520</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">ASV</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Added an ed note that
+ Section <a href="#Ignorable"><b>5.5 DesignatingConsiderations for choosing parameters Ignorable Behavior</b></a> looks incomplete.
+ </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20070520</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">ASV</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Fixed typos.
+ </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20070520</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">ASV</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Added an ed note in Section <a href="#assertion-target"><b>5.1 Assertions and Their Target Use</b></a> that
+ there is an open issue against Good Practice G2.
</td></div></tr></div></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Monday, 21 May 2007 01:54:41 UTC