- From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 23 Mar 2007 00:44:10 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv26652
Modified Files:
ws-policy-framework-tr20070228.xml
ws-policy-attachment-tr20070228.xml
ws-policy-primer-tr20061221.xml
ws-policy-guidelines-tr20061221.xml
Log Message:
Reset the baseline for diff generation ...
Index: ws-policy-attachment-tr20070228.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-attachment-tr20070228.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-attachment-tr20070228.xml 22 Mar 2007 07:11:39 -0000 1.2
+++ ws-policy-attachment-tr20070228.xml 23 Mar 2007 00:44:07 -0000 1.3
@@ -293,7 +293,8 @@
<p>
All information items defined by this specification
are identified by the XML namespace URI [<bibref ref="XML-NS"/>] &nsuri;. A <xspecref href="&schema;">normative XML
- Schema</xspecref> [<bibref ref="XMLSchemaPart1"/>, <bibref ref="XMLSchemaPart2"/>] document can be obtained by
+ Schema</xspecref> [<bibref ref="XMLSchemaPart1"/>, <bibref ref="XMLSchemaPart2"/>] document can be
+ obtained indirectly by
dereferencing the namespace document at the WS-Policy 1.5 namespace URI.</p>
<p>
In this document reference is made to the <att>wsu:Id</att>
@@ -394,64 +395,64 @@
<example id="Table2">
<head>Example RM Policy Expression.</head>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:rmp="http://docs.oasis-open.org/ws-rx/wsrmp/200602"
- xmlns:wsp="&nsuri;"
- xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
- wsu:Id="RmPolicy" >
-(02) <rmp:RMAssertion>
-(03) <rmp:InactivityTimeout Milliseconds="600000" />
-(04) <rmp:BaseRetransmissionInterval Milliseconds="3000" />
-(05) <rmp:ExponentialBackoff />
-(06) <rmp:AcknowledgementInterval Milliseconds="200" />
-(07) </rmp:RMAssertion>
+ xmlns:rmp="http://docs.oasis-open.org/ws-rx/wsrmp/200602"
+ xmlns:wsp="&nsuri;"
+ xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
+ wsu:Id="RmPolicy" >
+(02) <rmp:RMAssertion>
+(03) <rmp:InactivityTimeout Milliseconds="600000" />
+(04) <rmp:BaseRetransmissionInterval Milliseconds="3000" />
+(05) <rmp:ExponentialBackoff />
+(06) <rmp:AcknowledgementInterval Milliseconds="200" />
+(07) </rmp:RMAssertion>
(08) </wsp:Policy></eg>
</example>
<example id="Table3">
<head>Example X509 Security Policy Expression.</head>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;"
- xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
- wsu:Id="X509EndpointPolicy" >
-(02) <sp:AsymmetricBinding>
-(03) <wsp:Policy>
-(04) <sp:RecipientToken>
-(05) <wsp:Policy>
-(06) <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never">
-(07) <wsp:Policy>
-(08) <sp:WssX509V3Token10 />
-(09) </wsp:Policy>
-(10) </sp:X509Token>
-(11) </wsp:Policy>
-(12) </sp:RecipientToken>
-(13) <sp:InitiatorToken>
-(14) <wsp:Policy>
-(15) <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient" >
-(16) <wsp:Policy>
-(17) <sp:WssX509V3Token10 />
-(18) </wsp:Policy>
-(19) </sp:X509Token>
-(20) </wsp:Policy>
-(21) </sp:InitiatorToken>
-(22) <sp:AlgorithmSuite>
-(23) <wsp:Policy>
-(24) <sp:Basic256Rsa15 />
-(25) </wsp:Policy>
-(26) </sp:AlgorithmSuite>
-(27) <sp:Layout>
-(28) <wsp:Policy>
-(29) <sp:Lax />
-(30) </wsp:Policy>
-(31) </sp:Layout>
-(32) <sp:IncludeTimestamp />
-(33) <sp:OnlySignEntireHeadersAndBody />
-(34) </wsp:Policy>
-(35) </sp:AsymmetricBinding>
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;"
+ xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
+ wsu:Id="X509EndpointPolicy" >
+(02) <sp:AsymmetricBinding>
+(03) <wsp:Policy>
+(04) <sp:RecipientToken>
+(05) <wsp:Policy>
+(06) <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never">
+(07) <wsp:Policy>
+(08) <sp:WssX509V3Token10 />
+(09) </wsp:Policy>
+(10) </sp:X509Token>
+(11) </wsp:Policy>
+(12) </sp:RecipientToken>
+(13) <sp:InitiatorToken>
+(14) <wsp:Policy>
+(15) <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient" >
+(16) <wsp:Policy>
+(17) <sp:WssX509V3Token10 />
+(18) </wsp:Policy>
+(19) </sp:X509Token>
+(20) </wsp:Policy>
+(21) </sp:InitiatorToken>
+(22) <sp:AlgorithmSuite>
+(23) <wsp:Policy>
+(24) <sp:Basic256Rsa15 />
+(25) </wsp:Policy>
+(26) </sp:AlgorithmSuite>
+(27) <sp:Layout>
+(28) <wsp:Policy>
+(29) <sp:Lax />
+(30) </wsp:Policy>
+(31) </sp:Layout>
+(32) <sp:IncludeTimestamp />
+(33) <sp:OnlySignEntireHeadersAndBody />
+(34) </wsp:Policy>
+(35) </sp:AsymmetricBinding>
(36) </wsp:Policy></eg>
</example>
<p>The document containing both of these policy expressions is
assumed to be located at
- <code>http://www.example.com/policies</code>. Per Section
+ <code>http://www.example.com/policies</code>. Per Section
<xspecref href="&w3c-designation-framework;/#Policy_Identification">3.2
Policy Identification</xspecref> of &framework.title; [<bibref ref="WS-Policy"/>], the IRIs used for these <termref def="policy_expression">policy expressions</termref>
in the remainder of this document are
@@ -551,8 +552,8 @@
<specref ref="Example"/>.</p>
<p>If the <termref def="policy">policies</termref> referenced by the following XML element</p>
<eg xml:space="preserve" role="needs-numbering"><MyElement wsp:PolicyURIs="
- http://www.example.com/policies#RmPolicy
- http://www.example.com/policies#X509EndpointPolicy" /></eg>
+ http://www.example.com/policies#RmPolicy
+ http://www.example.com/policies#X509EndpointPolicy" /></eg>
<p>have been processed and <termref def="merge">merged</termref>,
it would result in an <termref def="element_policy">element policy</termref>
whose XML 1.0 representation is listed in <specref ref="Table4"/>:</p>
@@ -592,12 +593,12 @@
Policy References</xspecref> of &framework.title; [<bibref ref="WS-Policy"/>]), and the semantics for
this are the same as for the use of the global attribute. For example,
an alternative way of attaching the policies in the above example,
-using child elements, would be as follows: </p>
+using child elements, would be as follows: </p>
<eg xml:space="preserve" role="needs-numbering"><MyElement>
- <wsp:PolicyReference
- URI="http://www.example.com/policies#RmPolicy" />
- <wsp:PolicyReference
- URI="http://www.example.com/policies#X509EndpointPolicy" />
+ <wsp:PolicyReference
+ URI="http://www.example.com/policies#RmPolicy" />
+ <wsp:PolicyReference
+ URI="http://www.example.com/policies#X509EndpointPolicy" />
<MyElement/></eg>
</div2>
<div2 id="ExternalPolicyAttachment">
@@ -626,13 +627,13 @@
to the <el>wsp:PolicyAttachment</el> element using it.</p>
<p>The following is the pseudo-schema for the <el>wsp:PolicyAttachment</el> element:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:PolicyAttachment … >
- <wsp:AppliesTo>
- <x:DomainExpression/> +
- </wsp:AppliesTo>
- ( <wsp:Policy>…</wsp:Policy> |
- <wsp:PolicyReference>…</wsp:PolicyReference> ) +
- <wsse:Security>…</wsse:Security> ?
- …
+ <wsp:AppliesTo>
+ <x:DomainExpression/> +
+ </wsp:AppliesTo>
+ ( <wsp:Policy>…</wsp:Policy> |
+ <wsp:PolicyReference>…</wsp:PolicyReference> ) +
+ <wsse:Security>…</wsse:Security> ?
+ …
</wsp:PolicyAttachment></eg>
<p>The following describes the attributes and elements listed in the pseudo-schema outlined above:</p>
<glist>
@@ -727,13 +728,13 @@
EndpointReference domain expression for a deployed endpoint as defined
in Web Services Addressing [<bibref ref="WS-Addressing"/>]:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:PolicyAttachment>
- <wsp:AppliesTo>
- <wsa:EndpointReference>
- <wsa:Address>http://www.example.com/acct</wsa:Address>
- </wsa:EndpointReference>
- </wsp:AppliesTo>
- <wsp:PolicyReference
- URI="http://www.example.com/policies#RmPolicy" />
+ <wsp:AppliesTo>
+ <wsa:EndpointReference>
+ <wsa:Address>http://www.example.com/acct</wsa:Address>
+ </wsa:EndpointReference>
+ </wsp:AppliesTo>
+ <wsp:PolicyReference
+ URI="http://www.example.com/policies#RmPolicy" />
</wsp:PolicyAttachment></eg>
<p>In this example, the <termref def="policy_expression">policy expression</termref> at
<code>http://www.example.com/policies#RmPolicy</code> applies to all
@@ -1101,7 +1102,7 @@
assertions should be attached to this type of element.</p>
<p>Since <el>wsdl11:input</el>, <el>wsdl11:output</el>, and
<el>wsdl11:fault</el> elements in a
- <el>wsdl11:portType/wsdl11:operation</el> may be used by more than
+ <el>wsdl11:portType/wsdl11:operation</el> may be used by more than
one binding, it is <rfc2119>RECOMMENDED</rfc2119> that only policies
containing abstract (i.e., binding independent) assertions should be
attached to these types of elements.</p>
@@ -1123,61 +1124,61 @@
<example id="Table5">
<head>Example Policy Attached to WSDL.</head>
<eg xml:space="preserve">(01) <wsdl11:definitions name="StockQuote"
- targetNamespace="http://www.example.com/stock/binding"
- xmlns:tns="http://www.example.com/stock/binding"
- xmlns:fab="http://www.example.com/stock"
- xmlns:rmp="http://docs.oasis-open.org/ws-rx/wsrmp/200602"
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
- xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"
- xmlns:wsp="&nsuri;"
- xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" >
-(02) <wsp:Policy wsu:Id="RmPolicy" >
-(03) <rmp:RMAssertion>
-(04) <rmp:InactivityTimeout Milliseconds="600000" />
-(05) <rmp:BaseRetransmissionInterval Milliseconds="3000" />
-(06) <rmp:ExponentialBackoff />
-(07) <rmp:AcknowledgementInterval Milliseconds="200" />
-(08) </rmp:RMAssertion>
-(09) </wsp:Policy>
-(10) <wsp:Policy wsu:Id="X509EndpointPolicy" >
-(11) <sp:AsymmetricBinding>
-(12) <wsp:Policy>
- <!-- Details omitted for readability -->
-(13) <sp:IncludeTimestamp />
-(14) <sp:OnlySignEntireHeadersAndBody />
-(15) </wsp:Policy>
-(16) </sp:AsymmetricBinding>
-(17) </wsp:Policy>
-(18) <wsp:Policy wsu:Id="SecureMessagePolicy" >
-(19) <sp:SignedParts>
-(20) <sp:Body />
-(21) </sp:SignedParts>
-(22) <sp:EncryptedParts>
-(23) <sp:Body />
-(24) </sp:EncryptedParts>
-(25) </wsp:Policy>
-(26) <wsdl11:import namespace="http://www.example.com/stock"
- location="http://www.example.com/stock/stock.wsdl" />
-(27) <wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
-(28) <wsoap12:binding style="document"
-(29) transport="http://schemas.xmlsoap.org/soap/http" />
-(30) <wsp:PolicyReference URI="#RmPolicy" wsdl11:required="true" />
-(31) <wsp:PolicyReference URI="#X509EndpointPolicy" wsdl11:required="true" />
-(32) <wsdl11:operation name="GetLastTradePrice" >
-(33) <wsoap12:operation soapAction="http://www.example.com/stock/Quote/GetLastTradePriceRequest" />
-(34) <wsdl11:input>
-(35) <wsoap12:body use="literal" />
-(36) <wsp:PolicyReference URI="#SecureMessagePolicy"
- wsdl11:required="true" />
-(37) </wsdl11:input>
-(38) <wsdl11:output>
-(39) <wsoap12:body use="literal" />
-(40) <wsp:PolicyReference URI="#SecureMessagePolicy"
-(41) wsdl11:required="true" />
-(42) </wsdl11:output>
-(43) </wsdl11:operation>
-(44) </wsdl11:binding>
+ targetNamespace="http://www.example.com/stock/binding"
+ xmlns:tns="http://www.example.com/stock/binding"
+ xmlns:fab="http://www.example.com/stock"
+ xmlns:rmp="http://docs.oasis-open.org/ws-rx/wsrmp/200602"
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
+ xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"
+ xmlns:wsp="&nsuri;"
+ xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" >
+(02) <wsp:Policy wsu:Id="RmPolicy" >
+(03) <rmp:RMAssertion>
+(04) <rmp:InactivityTimeout Milliseconds="600000" />
+(05) <rmp:BaseRetransmissionInterval Milliseconds="3000" />
+(06) <rmp:ExponentialBackoff />
+(07) <rmp:AcknowledgementInterval Milliseconds="200" />
+(08) </rmp:RMAssertion>
+(09) </wsp:Policy>
+(10) <wsp:Policy wsu:Id="X509EndpointPolicy" >
+(11) <sp:AsymmetricBinding>
+(12) <wsp:Policy>
+ <!-- Details omitted for readability -->
+(13) <sp:IncludeTimestamp />
+(14) <sp:OnlySignEntireHeadersAndBody />
+(15) </wsp:Policy>
+(16) </sp:AsymmetricBinding>
+(17) </wsp:Policy>
+(18) <wsp:Policy wsu:Id="SecureMessagePolicy" >
+(19) <sp:SignedParts>
+(20) <sp:Body />
+(21) </sp:SignedParts>
+(22) <sp:EncryptedParts>
+(23) <sp:Body />
+(24) </sp:EncryptedParts>
+(25) </wsp:Policy>
+(26) <wsdl11:import namespace="http://www.example.com/stock"
+ location="http://www.example.com/stock/stock.wsdl" />
+(27) <wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
+(28) <wsoap12:binding style="document"
+(29) transport="http://schemas.xmlsoap.org/soap/http" />
+(30) <wsp:PolicyReference URI="#RmPolicy" wsdl11:required="true" />
+(31) <wsp:PolicyReference URI="#X509EndpointPolicy" wsdl11:required="true" />
+(32) <wsdl11:operation name="GetLastTradePrice" >
+(33) <wsoap12:operation soapAction="http://www.example.com/stock/Quote/GetLastTradePriceRequest" />
+(34) <wsdl11:input>
+(35) <wsoap12:body use="literal" />
+(36) <wsp:PolicyReference URI="#SecureMessagePolicy"
+ wsdl11:required="true" />
+(37) </wsdl11:input>
+(38) <wsdl11:output>
+(39) <wsoap12:body use="literal" />
+(40) <wsp:PolicyReference URI="#SecureMessagePolicy"
+(41) wsdl11:required="true" />
+(42) </wsdl11:output>
+(43) </wsdl11:operation>
+(44) </wsdl11:binding>
(45) </wsdl11:definitions></eg>
</example>
<p>For endpoints bound to <code>StockQuoteSoapBinding</code>, the <termref def="effective_policy">effective policy</termref>
@@ -1188,16 +1189,16 @@
<example id="Table6">
<head>Example Message Security Policy Expression.</head>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;"
- xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
- wsu:Id="SecureMessagePolicy" >
-(02) <sp:SignedParts>
-(03) <sp:Body />
-(04) </sp:SignedParts>
-(05) <sp:EncryptedParts>
-(06) <sp:Body />
-(07) </sp:EncryptedParts>
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;"
+ xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
+ wsu:Id="SecureMessagePolicy" >
+(02) <sp:SignedParts>
+(03) <sp:Body />
+(04) </sp:SignedParts>
+(05) <sp:EncryptedParts>
+(06) <sp:Body />
+(07) </sp:EncryptedParts>
(08) </wsp:Policy></eg>
</example>
</div3>
@@ -1243,32 +1244,32 @@
<eg xml:space="preserve">(01) <wsdl20:description>
(02) …
(03) <wsp:Policy wsu:Id="common">
-(04) <mtom:OptimizedMimeSerialization wsp:Optional="true"/>
-(05) <wsap:UsingAddressing />
-(06) </wsp:Policy>
+(04) <mtom:OptimizedMimeSerialization wsp:Optional="true"/>
+(05) <wsap:UsingAddressing />
+(06) </wsp:Policy>
-(07) <wsp:Policy wsu:Id="secure">
-(08) <wsp:ExactlyOne>
-(09) <sp:TransportBinding>…</sp:TransportBinding>
-(10) <sp:AsymmetricBinding>…</sp:AsymmetricBinding >
-(11) </wsp:ExactlyOne>
-(12) </wsp:Policy>
+(07) <wsp:Policy wsu:Id="secure">
+(08) <wsp:ExactlyOne>
+(09) <sp:TransportBinding>…</sp:TransportBinding>
+(10) <sp:AsymmetricBinding>…</sp:AsymmetricBinding >
+(11) </wsp:ExactlyOne>
+(12) </wsp:Policy>
-(13) <wsdl20:binding name="SecureBinding"
-(14) interface="tns:RealTimeDataInterface" >
-(15) <wsp:PolicyReference URI="#secure" />
-(16) <wsdl20:operation name="GetRealQuote" >…</wsdl20:operation>
-(17) …
-(18) </wsdl20:binding>
+(13) <wsdl20:binding name="SecureBinding"
+(14) interface="tns:RealTimeDataInterface" >
+(15) <wsp:PolicyReference URI="#secure" />
+(16) <wsdl20:operation name="GetRealQuote" >…</wsdl20:operation>
+(17) …
+(18) </wsdl20:binding>
-(19) <wsdl20:service name="RealTimeDataService"
-(20) interface="tns:RealTimeDataInterface" >
-(21) <wsdl20:endpoint name="RealTimeDataPort"
-(22) binding="tns:SecureBinding">
-(23) <wsp:PolicyReference URI="#common" />
-(24) …
-(25) </wsdl20:endpoint>
-(26) </wsdl20:service>
+(19) <wsdl20:service name="RealTimeDataService"
+(20) interface="tns:RealTimeDataInterface" >
+(21) <wsdl20:endpoint name="RealTimeDataPort"
+(22) binding="tns:SecureBinding">
+(23) <wsp:PolicyReference URI="#common" />
+(24) …
+(25) </wsdl20:endpoint>
+(26) </wsdl20:service>
(27) …
(28) </wsdl20:description></eg>
</example>
@@ -1298,18 +1299,18 @@
<example id="table-wsdl20-effective-policy-example">
<head>Effective Policy for the RealTimeDataPort endpoint</head>
<eg xml:space="preserve">(01) <wsp:Policy>
-(02) <wsp:All>
-(03) <wsp:Policy>
-(04) <mtom:OptimizedMimeSerialization wsp:Optional="true"/>
-(05) <wsap:UsingAddressing />
-(06) </wsp:Policy>
-(07) <wsp:Policy>
-(08) <wsp:ExactlyOne>
-(09) <sp:TransportBinding>…</sp:TransportBinding>
-(10) <sp:AsymmetricBinding>…</sp:AsymmetricBinding >
-(11) </wsp:ExactlyOne>
-(12) </wsp:Policy>
-(13) </wsp:All>
+(02) <wsp:All>
+(03) <wsp:Policy>
+(04) <mtom:OptimizedMimeSerialization wsp:Optional="true"/>
+(05) <wsap:UsingAddressing />
+(06) </wsp:Policy>
+(07) <wsp:Policy>
+(08) <wsp:ExactlyOne>
+(09) <sp:TransportBinding>…</sp:TransportBinding>
+(10) <sp:AsymmetricBinding>…</sp:AsymmetricBinding >
+(11) </wsp:ExactlyOne>
+(12) </wsp:Policy>
+(13) </wsp:All>
(14) </wsp:Policy></eg>
</example>
</div2>
@@ -2102,17 +2103,17 @@
<el>businessService</el>, and a tModel using the entity's <el>categoryBag</el>. For
example, associating the <termref def="policy_expression">policy expression</termref> that is identified by the
IRI <code>http://www.example.com/myservice/policy</code> with a <el>businessService</el> is
-done as follows: </p>
+done as follows: </p>
<eg xml:space="preserve" role="needs-numbering"><businessService serviceKey="…" >
- <name>…</name>
- <description>…</description>
- <bindingTemplates>…</bindingTemplates>
- <categoryBag>
- <keyedReference
- keyName="Policy Expression for example's Web services"
- keyValue="http://www.example.com/myservice/policy"
- tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" />
- </categoryBag>
+ <name>…</name>
+ <description>…</description>
+ <bindingTemplates>…</bindingTemplates>
+ <categoryBag>
+ <keyedReference
+ keyName="Policy Expression for example's Web services"
+ keyValue="http://www.example.com/myservice/policy"
+ tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" />
+ </categoryBag>
</businessService></eg>
<p>The <att>tModelKey</att> of the <el>keyedReference</el>
<rfc2119>MUST</rfc2119> match
@@ -2124,19 +2125,19 @@
expression</termref> with a <el>bindingTemplate</el>, since bindingTemplates do not
contain a <el>categoryBag</el> in UDDI Version 2. Therefore, the
<el>bindingTemplate</el>'s <el>tModelInstanceInfo</el> and <el>instanceParms</el>
-<rfc2119>MUST</rfc2119> be used as follows: </p>
+<rfc2119>MUST</rfc2119> be used as follows: </p>
<eg xml:space="preserve" role="needs-numbering"><bindingTemplate bindingKey="…" >
- <accessPoint>…</accessPoint>
- <tModelInstanceDetails>
- <tModelInstanceInfo
- tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" >
- <instanceDetails>
- <instanceParms>
- http://www.example.com/myservice/policy
- </instanceParms>
- </instanceDetails>
- </tModelInstanceInfo>
- </tModelInstanceDetails>
+ <accessPoint>…</accessPoint>
+ <tModelInstanceDetails>
+ <tModelInstanceInfo
+ tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" >
+ <instanceDetails>
+ <instanceParms>
+ http://www.example.com/myservice/policy
+ </instanceParms>
+ </instanceDetails>
+ </tModelInstanceInfo>
+ </tModelInstanceDetails>
</bindingTemplate></eg>
<p>The <att>tModelKey</att> of the <el>tModelInstanceInfo</el>
<rfc2119>MUST</rfc2119>
@@ -2157,24 +2158,24 @@
identified by the IRI
<code>http://www.example.com/myservice/policy</code>.</p>
<eg xml:space="preserve" role="needs-numbering"><tModel tModelKey="uuid:04cfa…">
- <name>…</name>
- <description xml:lang="EN">
- Policy Expression for example's Web services
- </description>
- <overviewDoc>
- <description xml:lang="EN">Web Services Policy Expression</description>
- <overviewURL>http://www.example.com/myservice/policy</overviewURL>
- </overviewDoc>
- <categoryBag>
- <keyedReference
- keyName="Reusable policy Expression"
- keyValue="policy"
- tModelKey="uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" />
- <keyedReference
- keyName="Policy Expression for example's Web services"
- keyValue="http://www.example.com/myservice/policy"
- tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" />
- </categoryBag>
+ <name>…</name>
+ <description xml:lang="EN">
+ Policy Expression for example's Web services
+ </description>
+ <overviewDoc>
+ <description xml:lang="EN">Web Services Policy Expression</description>
+ <overviewURL>http://www.example.com/myservice/policy</overviewURL>
+ </overviewDoc>
+ <categoryBag>
+ <keyedReference
+ keyName="Reusable policy Expression"
+ keyValue="policy"
+ tModelKey="uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" />
+ <keyedReference
+ keyName="Policy Expression for example's Web services"
+ keyValue="http://www.example.com/myservice/policy"
+ tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" />
+ </categoryBag>
</tModel></eg>
<p>The first <el>keyedReference</el> specifies that the tModel represents a
<termref def="policy_expression">policy expression</termref> — rather than only being associated with one
@@ -2216,17 +2217,17 @@
<el>businessService</el>, and a tModel using the entity's <el>categoryBag</el>. For
example, associating the <termref def="policy_expression">policy expression</termref> tModel with the <att>tModelKey</att>
<code>"uuid:04cfa…"</code> from above with a <el>businessService</el> is done as
-follows: </p>
+follows: </p>
<eg xml:space="preserve" role="needs-numbering"><businessService serviceKey="…" >
- <name>…</name>
- <description>…</description>
- <bindingTemplates>…</bindingTemplates>
- <categoryBag>
- <keyedReference
- keyName="Policy Expression for example's Web services"
- keyValue="uuid:04cfa…"
- tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" />
- </categoryBag>
+ <name>…</name>
+ <description>…</description>
+ <bindingTemplates>…</bindingTemplates>
+ <categoryBag>
+ <keyedReference
+ keyName="Policy Expression for example's Web services"
+ keyValue="uuid:04cfa…"
+ tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" />
+ </categoryBag>
</businessService></eg>
<p>The <att>tModelKey</att> of the <el>keyedReference</el>
<rfc2119>MUST</rfc2119> match
@@ -2237,17 +2238,17 @@
expression</termref> with a <el>bindingTemplate</el>, since bindingTemplates do not
contain a <el>categoryBag</el> in UDDI Version 2. Therefore, the
<el>bindingTemplate</el>'s <el>tModelInstanceInfo</el> and <el>instanceParms</el>
-<rfc2119>MUST</rfc2119> be used as follows: </p>
+<rfc2119>MUST</rfc2119> be used as follows: </p>
<eg xml:space="preserve" role="needs-numbering"><bindingTemplate bindingKey="…" >
- <accessPoint>…</accessPoint>
- <tModelInstanceDetails>
- <tModelInstanceInfo
- tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" >
- <instanceDetails>
- <instanceParms>uuid:04cfa…</instanceParms>
- </instanceDetails>
- </tModelInstanceInfo>
- </tModelInstanceDetails>
+ <accessPoint>…</accessPoint>
+ <tModelInstanceDetails>
+ <tModelInstanceInfo
+ tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" >
+ <instanceDetails>
+ <instanceParms>uuid:04cfa…</instanceParms>
+ </instanceDetails>
+ </tModelInstanceInfo>
+ </tModelInstanceDetails>
</bindingTemplate></eg>
<p>The tModelKey of the <el>tModelInstanceInfo</el>
<rfc2119>MUST</rfc2119> match the fixed <att>tModelKey</att> from the
@@ -2277,17 +2278,17 @@
<el>bindingTemplate</el>'s <el>categoryBag</el>, analogous to the mechanism described
for other UDDI entities. For example, the example <el>bindingTemplate</el> from
section <specref ref="CalculatingEffectivePolicyElementPolicyUDDI"/> would be
-changed as follows: </p>
+changed as follows: </p>
<eg xml:space="preserve" role="needs-numbering"><bindingTemplate bindingKey="…" >
- <accessPoint>…</accessPoint>
- <tModelInstanceDetails>…</tModelInstanceDetails>
- <categoryBag>
- <keyedReference
- keyName="Policy Expression for example's Web services"
- keyValue="http://www.example.com/myservice/policy"
- tModelKey="uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"
- />
- </categoryBag>
+ <accessPoint>…</accessPoint>
+ <tModelInstanceDetails>…</tModelInstanceDetails>
+ <categoryBag>
+ <keyedReference
+ keyName="Policy Expression for example's Web services"
+ keyValue="http://www.example.com/myservice/policy"
+ tModelKey="uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"
+ />
+ </categoryBag>
</bindingTemplate></eg>
<p>Third, inquiries for reusable <termref def="policy_expression">policy expression</termref> tModels
described in Section <specref ref="RegisteringReusablePolicyExpressions"/> and UDDI
@@ -2295,18 +2296,18 @@
by the wildcard mechanism for keyValues in keyedReferences. For
example, searching for all <termref def="policy_expression">policy expression</termref> tModels whose IRI starts
with <code>http://www.example.com/</code>, the following <code>find_tModel</code> API call can
-be used: </p>
+be used: </p>
<eg xml:space="preserve" role="needs-numbering"><find_tModel
xmlns="urn:uddi-org:api_v3" >
- <categoryBag>
- <keyedReference
- keyValue="http://www.example.com/"
- tModelKey="uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"
- />
- </categoryBag>
- <findQualifiers>
- <findQualifier>approximateMatch</findQualifier>
- </findQualifiers>
+ <categoryBag>
+ <keyedReference
+ keyValue="http://www.example.com/"
+ tModelKey="uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"
+ />
+ </categoryBag>
+ <findQualifiers>
+ <findQualifier>approximateMatch</findQualifier>
+ </findQualifiers>
</find_tModel></eg>
<p>Fourth, all UDDI entities may be digitally signed using XML digital
signatures [<bibref ref="XML-Signature"/>]. Publishers who want to
@@ -2332,7 +2333,7 @@
<head>Conformance</head>
<div2>
<head>External Policy Attachment Conformance</head>
-<p>An element information item whose namespace name is "&nsuri;" and whose local part is PolicyAttachment conforms to this specification if it is valid according to the XML Schema [<bibref ref="XMLSchemaPart1"/>] for that element as defined by this specification (<loc href="&schema;.xsd">&schema;.xsd</loc>) and additionally adheres to all the constraints contained in Section <specref ref="ExternalPolicyAttachment"/> of this specification. Such a conformant element information item constitutes an external policy attachment. </p>
+<p>An element information item whose namespace name is "&nsuri;" and whose local part is PolicyAttachment conforms to this specification if it is valid according to the XML Schema [<bibref ref="XMLSchemaPart1"/>] for that element as defined by this specification (<loc href="&schema;">&schema;</loc>) and additionally adheres to all the constraints contained in Section <specref ref="ExternalPolicyAttachment"/> of this specification. Such a conformant element information item constitutes an external policy attachment. </p>
</div2>
<div2>
<head>WSDL 1.1 Attachment Conformance</head>
@@ -2592,7 +2593,7 @@
<bibl id="WSDL11BindingforSOAP12" key="WSDL 1.1 Binding for SOAP 1.2" href="http://www.w3.org/Submission/2006/SUBM-wsdl11soap12-20060405/">
<titleref>WSDL 1.1 Binding for SOAP 1.2</titleref>,
D. Angelov, et al, Authors. World Wide Web Consortium, 5 April
- 2006. Available at
+ 2006. Available at
http://www.w3.org/Submission/2006/SUBM-wsdl11soap12-20060405/.
</bibl>
<bibl id="XML-Signature" key="XML-Signature" href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/">
@@ -2682,16 +2683,16 @@
<div3 id="ModelStructure1">
<head>tModel Structure</head>
<eg xml:space="preserve" role="needs-numbering"><tModel tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" >
- <name>http://schemas.xmlsoap.org/ws/2003/03/remotepolicyreference</name>
- <description xml:lang="EN">Category system used for UDDI entities to point to an external
+ <name>http://schemas.xmlsoap.org/ws/2003/03/remotepolicyreference</name>
+ <description xml:lang="EN">Category system used for UDDI entities to point to an external
Web Services Policy Attachment policy expression that describes their characteristics.
See &attachment.title; specification for further details.</description>
- <categoryBag>
- <keyedReference
- keyName="uddi-org:types:categorization"
- keyValue="categorization"
- tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" />
- </categoryBag>
+ <categoryBag>
+ <keyedReference
+ keyName="uddi-org:types:categorization"
+ keyValue="categorization"
+ tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" />
+ </categoryBag>
</tModel></eg>
</div3>
</div2>
@@ -2747,15 +2748,15 @@
<div3 id="ModelStructure2">
<head>tModel Structure</head>
<eg xml:space="preserve" role="needs-numbering"><tModel tModelKey="uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" >
- <name>http://schemas.xmlsoap.org/ws/2003/03/policytypes</name>
- <description xml:lang="EN">Web Services Policy Types category system used for UDDI tModels
+ <name>http://schemas.xmlsoap.org/ws/2003/03/policytypes</name>
+ <description xml:lang="EN">Web Services Policy Types category system used for UDDI tModels
to characterize them as Web Services Policy – based policy expressions.</description>
- <categoryBag>
- <keyedReference
- keyName="uddi-org:types:categorization"
- keyValue="categorization"
- tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" />
- </categoryBag>
+ <categoryBag>
+ <keyedReference
+ keyName="uddi-org:types:categorization"
+ keyValue="categorization"
+ tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" />
+ </categoryBag>
</tModel></eg>
</div3>
</div2>
@@ -2814,25 +2815,25 @@
<div3 id="ModelStructure3">
<head>tModel Structure</head>
<eg xml:space="preserve" role="needs-numbering"><tModel tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" >
- <name>http://schemas.xmlsoap.org/ws/2003/03/localpolicyreference</name>
- <description xml:lang="en">Category system used for UDDI entities to point to a
+ <name>http://schemas.xmlsoap.org/ws/2003/03/localpolicyreference</name>
+ <description xml:lang="en">Category system used for UDDI entities to point to a
Web Services Policy policy expression tModel that describes their characteristics.
See &attachment.title; specification for further details.</description>
- <categoryBag>
- <keyedReference
- keyName="uddi-org:types:categorization"
- keyValue="categorization"
- tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62aB4" />
- <keyedReference
- keyName="uddi-org:types:checked"
- keyValue="checked"
- tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62aB4" />
- <keyedReference
- keyName="uddi-org:entityKeyValues"
- keyValue="tModelKey"
- tModelKey="uuid:916b87bf-0756-3919-8eae-97dfa325e5a4" />
+ <categoryBag>
+ <keyedReference
+ keyName="uddi-org:types:categorization"
+ keyValue="categorization"
+ tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62aB4" />
+ <keyedReference
+ keyName="uddi-org:types:checked"
+ keyValue="checked"
+ tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62aB4" />
+ <keyedReference
+ keyName="uddi-org:entityKeyValues"
+ keyValue="tModelKey"
+ tModelKey="uuid:916b87bf-0756-3919-8eae-97dfa325e5a4" />
</categoryBag>
-</tModel> </eg>
+</tModel> </eg>
</div3>
</div2>
</div1>
@@ -3273,6 +3274,14 @@
<loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4306">4306</loc>.
Editors' action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/158">158</loc>.
</td>
+ </tr>
+ <tr>
+ <td>20070222</td>
+ <td>ASV</td>
+ <td>Applied a <loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0157.html">missed item</loc>
+ (re issue <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4207">4207</loc>) to
+ <specref ref="XMLNamespaces"/>.
+ </td>
</tr>
</tbody>
</table>
Index: ws-policy-guidelines-tr20061221.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines-tr20061221.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- ws-policy-guidelines-tr20061221.xml 8 Jan 2007 22:55:34 -0000 1.1
+++ ws-policy-guidelines-tr20061221.xml 23 Mar 2007 00:44:07 -0000 1.2
@@ -11,7 +11,7 @@
<?xml-stylesheet type='text/xsl' href='xmlspec-policy.xsl'?>
<spec w3c-doctype="wd" role="&document.role;">
<header>
- <title>&guidelines.title;</title>
+ <title>&guideline.title;</title>
<w3c-designation>&w3c-designation-guidelines;</w3c-designation>
<w3c-doctype>&document.status;</w3c-doctype>
<pubdate>
@@ -62,7 +62,7 @@
</authlist>
<abstract>
<p>
- <emph>&guidelines.title;</emph> is intended to provide guidance for assertion
+ <emph>&guideline.title;</emph> is intended to provide guidance for assertion
authors that will work with the &framework.title; [<bibref
ref="WS-Policy"/>] and &attachment.title; [<bibref
ref="WS-PolicyAttachment"/>] specifications to create domain
@@ -92,14 +92,13 @@
consistent combinations of behaviors from a variety of domains.
A policy assertion is a machine readable metadata expression that
identifies behaviors required for Web services interactions.
- <emph>&guidelines.title;</emph>
- is a resource primarily for assertion authors and provides
+ <emph>&guideline.title;</emph>
+ is a resource primarily for Assertion Authors and provides
guidelines on the use of &framework.title; and
&attachment.title; specifications to create and use domain specific
assertions to enable interoperability.
</p>
- <p>WS-Policy Assertions are XML expressions
- that communicate the requirements and capabilities of a web
+ <p>WS-Policy Assertions communicate the requirements and capabilities of a web
service by adhering to the specification, WS-Policy Framework. To enable interoperability of web
services different sets of WS-Policy Assertions need to be
defined by different communities based upon domain-specific requirements of
@@ -118,7 +117,7 @@
</p>
</item>
<item>
- <p>WS-Policy assertion authors who need to know the features
+ <p>Assertion Authors who need to know the features
of the language and understand the requirements for
describing policy assertions.
</p>
@@ -133,7 +132,7 @@
</item>
<item>
<p>Providers of policy expressions who need to understand
- how to use the assertions authored by policy assertion authors
+ how to use the assertions authored by Assertion Authors
</p>
</item>
</ulist>
@@ -230,8 +229,8 @@
</item>
</ulist>
- <p>There are already many examples in the industry that adhere to this practice, such as <bibref ref="WS-RM-Policy"/>
- and <bibref ref="WS-SecurityPolicy"/>. Some common characteristics from these documents may be considered as <emph>best practices</emph> for new assertion authors:
+ <p>There are already many examples in the industry that adhere to the above practices, such as <bibref ref="WS-RM-Policy"/>
+ and <bibref ref="WS-SecurityPolicy"/>. Some common characteristics from these documents may be considered as <emph>best practices</emph> for new Assertion Authors:
</p>
<ulist>
<item>
@@ -252,7 +251,7 @@
specification will be well informed and able to adequately specify assertions for their domain.
</p>
<p>It is expected that consumers of the metadata specified by
- the assertion authors will also benefit from understanding these
+ the Assertion Authors will also benefit from understanding these
practices as it will help them utilize the assertions in the
context of the WS-Policy framework. A result of following the
best practices will be an assertion specification that describes
@@ -267,7 +266,7 @@
express their own domain knowledge, it is necessary to provide basic
functionality that all domains could exploit and then allow
points of extension where authors of the various WS-Policy
- expressions for a particular domain can provide additional semantics.
+ assertions for a particular domain can provide additional semantics.
</p>
<p>Some policy assertions specify traditional
requirements and capabilities that will ultimately manifest on
@@ -283,14 +282,14 @@
</p>
<div3 id="domain-owners">
- <head> WS-Policy Authors</head>
- <p> WS-Policy Domain owners or WS-Policy authors are defined
+ <head> Assertion Authors</head>
+ <p>Assertion Authors are defined
by the WS-Policy Framework to be a community that chooses to
exploit the WS-Policy Framework by creating their own
specification to define a set of assertions that express the
capabilities and constraints of that target domain. The
WS-Policy Framework is based on a declarative model, meaning
- that it is incumbent on the WS-Policy authors to define both the semantics of
+ that it is incumbent on the Assertion Authors to define both the semantics of
the assertions as well as the scope of their target domain in their specification. The set
of metadata for any particular domain will vary in the granularity of assertion
specification required. It is the intent of
@@ -299,11 +298,11 @@
consumers and providers can utilize the framework consistently across domains.
</p>
<p>When using the WS-Policy Framework, any
- domain author defining new WS-Policy assertions
+ Assertion Authors defining new WS-Policy assertions
must adhere to the MUST's and SHOULD's in the specification
and should review the conformance section of the specification.
</p>
- <p>WS-Policy Domain authors must also specify how to associate
+ <p>Assertion Authors must also specify how to associate
the assertions they have defined with the policy subjects
identified by the WS-PolicyAttachment specification.
</p>
@@ -360,16 +359,17 @@
</div3>
<div3 id="providers">
<head>Providers</head>
- <p>A provider of WS-Policy Assertions can be any web service implementation that can
- specify its on-the-wire message behavior as an XML
- expression that conforms to the WS-PolicyFramework and
- WS-Policy Attachment specifications. The
- WS-PolicyAttachment specification has defined a set of
+ <p>A provider who expresses capabilities and requirements of a Web service
+ as policies can be any web service implementation that can
+ specify its on-the-wire message behavior as a policy
+ expression that conforms to the Web Services Policy 1.5 - Framework [<bibref ref="WS-Policy"/>]
+ and Web Services Policy 1.5 - Attachment [<bibref ref="WS-PolicyAttachment"/>] specifications.
+ The Web Services Policy 1.5 - Attachment specification has defined a set of
subjects and an extensible mechanism for attaching policies
to web services subjects. When a web service provider
chooses to make its capabilities and constraints available,
- it may also need to conform to requirements of other policy
- specifications it utilizes ( i.e., WS-SecurityPolicy).
+ the provider may also need to conform to requirements of other policy
+ assertion specifications it utilizes ( i.e., WS-SecurityPolicy).
</p>
<p>When deploying services with policies it is useful for providers to anticipate how
to evolve their services capabilities over time. If
@@ -384,10 +384,10 @@
</div1>
<div1 id="general-guidelines">
- <head>General Guidelines for WS-Policy Assertion Authors</head>
- <p> As authors begin the task of inventing XML dialects to represent policy assertions they can take
+ <head>General Guidelines for Assertion Authors</head>
+ <p> As Assertion Authors begin the task of inventing XML dialects to represent policy assertions they can take
advantage of WS-Policy building on XML principles and XML Schema validation in their design. WS-Policy
- relies on the QName of a policy assertion being an XML element but allows authors to optionally
+ relies on the QName of a policy assertion being an XML element but allows Assertuib 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>
@@ -414,12 +414,12 @@
<div2 id="assertion-target">
<head>Assertions and Their Target Use</head>
- <p>WS-Policy authors need to have some definition of what the goal is for the assertions
- they author. WS-Policy authors should also understand the
+ <p>Assertion Authors need to have some definition of what the goal is for the assertions
+ they author. Assertion Authors should also understand the
functionality the WS-Policy framework provides and apply the
knowledge of framework processing when defining the set of assertions.
</p>
- <p>Assertions can be simple or they can be complex. WS-Policy authors may choose to specify one or two
+ <p>Assertions can be simple or they can be complex. Assertion Authors may choose to specify one or two
assertions or they may choose to specify many assertion
elements that require parameters or other nested
assertions. There are advantages to simplifying the set of
@@ -451,7 +451,7 @@
attachment in multiple WSDL files or Endpoint
References in which the same set of policies are expected to be applied.
</p>
- <p>Best practice: WS-Policy authors should include the following
+ <p>Best practice: Assertion Authors should include the following
items in the dialect specification:
</p>
<ulist>
@@ -581,13 +581,13 @@
</p>
<div3 id="minimal-approach">
<head>Minimal approach</head>
- <p>New policy authors are encouraged to try to not overload assertions. A single assertion indicates a single
+ <p>New Assertion Authors are encouraged to try to not overload assertions. A single assertion indicates a single
behavior. Sets of assertions can by grouped by an operator "all". This indicates that there is a relationship between
the assertions and they now constitute a policy alternative.
</p>
<p>If grouping is utilized, choices between alternatives can be indicated by
an "exactly one" operator. This basic set of operators allows
- authors a wide range of options for expressing the possible combinations of assertions within their domain.
+ Assertion Authors a wide range of options for expressing the possible combinations of assertions within their domain.
</p>
<p>It requires a good deal of effort to evaluate the
capabilities of a domain and capture them in a way that
@@ -596,8 +596,8 @@
domains is recommended to ensure that consumers and providers
are able to use the new domain assertions.
</p>
- <p>New 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. Domain authors are encouraged to look at <bibref
+ <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>How big should an assertion be? How many assertion parameters should the assertion
@@ -611,10 +611,10 @@
</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
+ <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
+ 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>
@@ -646,18 +646,18 @@
endpoint, or those that are required in a particular message; the
latter are the intended uses of the WS-Policy framework.
</p>
- <p>As a result, the assertion authors should take into account that the following important concepts
+ <p>As a result, the Assertion Authors should take into account that the following important concepts
when designing assertions and documenting the semantics of the
assertion types.
</p>
<p>Firstly, an assertion type indicates a <emph>runtime</emph> behavior.
</p>
- <p>Secondly, authors need to indicate how the runtime behavior represented in the assertion type can be inferred or indicated
+ <p>Secondly, Assertion Authors need to indicate how the runtime behavior represented in the assertion type can be inferred or indicated
from a message at runtime. If there is a need for the behavior
to be represented in a persistent way or if there is a need for
additional data or metadata that is present in a message to be
persisted, it should be incorporated into the assertion design or
- in the message itself. In essence, the assertion authors should
+ in the message itself. In essence, the Assertion Authors should
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.
@@ -688,7 +688,7 @@
will determine whether a particular set of assertions
correctly characterize a domain. A new community should avoid
duplicating assertions that have already been defined as this
- will create ambiguity not clarification. New WS-Policy authors
+ will create ambiguity not clarification. New Assertion Authors
should focus on creating assertions for those specific
constraints and capabilities that do not overlap with other
domains but that communicate new functionality.
@@ -717,8 +717,7 @@
<div3 id="parameterized-assertions">
<head>Assertions with Parameters</head>
- <p>The framework allows WS-Policy
- domain authors to define parameters, for example, to
+ <p>The framework allows Assertion Authors to define parameters, for example, to
qualify an assertion. For some domains it will be appropriate
to specify these parameters instead of nesting assertion elements.
</p>
@@ -759,7 +758,7 @@
</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 authors have defined the
+ <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
messages. Just indicating the use of transport-level security
@@ -832,7 +831,7 @@
parameters in its algorithm</emph>.
</p>
- <p>Domain authors should recognize that the framework can
+ <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
@@ -861,7 +860,7 @@
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>Best practice: If the domain
+ <p>Best practice: If the assertion
authors want to delegate the processing to the framework,
utilizing nesting should be considered. Otherwise, domain
specific comparison algorithms will need to be devised and be
@@ -910,7 +909,7 @@
the provider can determine whether the policy alternate that
contains the MTOM assertion is being selected.</p>
- <p>Assertion authors should be aware that optional behaviors,
+ <p>Assertion Authors should be aware that optional behaviors,
like utilizing optional support for Optimized MIME
Serialization require some care considering the scoping of the assertion that is applicable. </p>
<ulist>
@@ -936,14 +935,14 @@
</item>
<item>
<p> The target scope of an optional assertion is an important factor for
- assertion authors to consider as it determines the
+ Assertion Authors to consider as it determines the
<emph>granularity</emph> where the behavior is optionally
engaged. For example, if the assertion is targeted for an
endpoint policy subject, it is expected to govern all the
messages that are indicated by the specific endpoint when
optional behavior is <emph> engaged </emph>. Since the
behavior would be applicable to policy subject that is
- designated, it is important for the policy assertion authors
+ designated, it is important for the Assertion Authors
to choose the appropriate level of granularity for optional
behaviors, to consider whether a specific message or all messages, etc. are targeted.
</p>
@@ -962,7 +961,7 @@
if a request-response interaction only specified MTOM
optimization for an inbound message, it would not be clear
whether the outbound message from the provider could also
- utilize the behavior. Therefore, the assertion authors are
+ utilize the behavior. Therefore, the Assertion Authors are
encouraged to consider how the attachment on a message
policy subject on a response message should be treated
when optional behaviors are specified for message
@@ -972,8 +971,8 @@
(i.e. if the incoming message utilized the optimization,
the response will be returned utilizing the MTOM
serialization). Similarly, if engagement of a behavior is
- only specified for an outbound message, the policy
- assertion authors should consider describing the
+ only specified for an outbound message, the
+ Assertion Authors should consider describing the
semantics if the incoming messages also utilized the
behavior. This is especially important if the assertion is
applicable to more than one specific policy subject. One
@@ -984,7 +983,7 @@
</p>
</item>
</ulist>
- <p>Best Practice: Optional assertion authors should explicitly state
+ <p>Best Practice: Optional Assertion Authors should explicitly state
how the behavior that is enabled by the assertion would be
engaged when they are designing their assertion, whether by
specific headers or some other means. See also <specref ref="self-describing"/>.
@@ -994,7 +993,7 @@
<div2 id="typing-assertions">
<head>Typing Assertions</head>
<p>Since a <emph>QName</emph> is the central mechanism for
- identifying a policy assertion, assertion authors should be
+ identifying a policy assertion, Assertion Authors should be
aware of the possible evolution of their assertions and how
this would impact the semantics of the assertion overtime. A namespace
associated with the assertion may be used to indicate a
@@ -1017,7 +1016,7 @@
</p>
<p>Thus our example encryption assertion would have a
subject of "message", and could only be attached to
- messages, where the assertion is valid. However, authors
+ messages, where the assertion is valid. However, Assertion Authors
need to be aware that <emph>policy attachment subjects are
not limited to the subjects defined in WSDL</emph>. The
external attachment model in WS-PolicyAttachment allows for
@@ -1055,7 +1054,7 @@
<head>Levels of Abstraction 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, policy assertion authors must specify a WSDL
+ within WSDL, Assertion Authors must specify a WSDL
policy subject. The policy subject is determined with respect
to a behavior as follows:
</p>
@@ -1078,14 +1077,14 @@
the subject is the message policy subject - similarly for output and fault message policy subjects.</p>
</item>
</ulist>
- <p>WS-Policy authors that wish to utilize WSDL policy subjects need to understand how the assertions will be
+ <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 domain authors chose to support certain capabilities at
+ 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
@@ -1098,7 +1097,7 @@
</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>
+ Assertion Authors should consider the following</p>
<ulist>
<item>
<p> Decompose the semantics with several assertions </p>
@@ -1110,9 +1109,9 @@
<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. Policy assertion authors should identify the
+ portType element. Assertion Authors should identify the
relevant attachment point when defining a new assertion. To
- determine the relevant attachment points, authors should
+ determine the relevant attachment points, Assertion Authors 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
@@ -1155,7 +1154,7 @@
</div1>
<div1 id="lifecycle">
<head>Lifecycle of Assertions</head>
- <p>WS-Policy authors need to consider not just the expression of the current set of requirements but
+ <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 that govern an assertions lifecycle:</p>
<ulist>
<item>
@@ -1166,7 +1165,7 @@
<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> Policy authors should review the WS-Policy Primer <bibref ref="WS-Policy-Primer"/>
+ <p> Assertion Authors should review the WS-Policy Primer <bibref ref="WS-Policy-Primer"/>
and the specifications <bibref ref="WS-Policy"/> <bibref ref="WS-PolicyAttachment"/>
for details on extensibility.
</p>
@@ -1190,7 +1189,7 @@
<p>The <bibref ref="WS-Policy-Primer"/> illustrates how
providers can utilize the identification mechanism defined in the Policy specification
to expose a complex policy expression as a reusable building block for
- other policy expressions by reference. Domain assertion
+ other policy expressions by reference. Assertion
authors, especially those defining complex assertions that
include nesting or complex types should consider specifying or recommending
naming conventions in order to promote reuse. Reuse through
@@ -1232,7 +1231,7 @@
<div1 id="inter-policy">
<head>Inter-domain Policy and Composition Issues</head>
- <p>Domain authors must be aware of the interactions between their
+ <p>Assertion Authors must be aware of the interactions between their
domain and other domains. For example, security assertions interact
with other protocol assertions in a composition. Although
modeling protocol assertions may appear to be an independent behavior,
@@ -1241,7 +1240,7 @@
example utilization of WS-Security Policy with other
protocols affects transport bindings and would result in nested
policy assertions when additional protocols are composed with
- <bibref ref="WS-Security2004"/>. Thus, domain authors should
+ <bibref ref="WS-Security2004"/>. Thus, Assertion Authors should
be aware of the compositional semantics with other related
domains. The protocol assertions that require composition
with WS-Security should be particularly aware of the nesting
@@ -1406,10 +1405,10 @@
second profile that included two security options. The details of
the Bindings, requires a more detailed exploration of some of the
other features of the WS-Policy Framework. </p>
- <p>When WS-Policy authors create sets of Policy assertions, like
+ <p>When Assertion Authors create sets of Policy assertions, like
WS-Security Policy they need to consider expressing the semantics
of their domain in a way that policy consumers, like Company A,
- can utilize them. In this case, the WS-SecurityPolicy authors
+ can utilize them. In this case, the WS-SecurityPolicy Assertion Authors
factored out common elements of security mechanisms and utilized a
feature of WS-Policy called "nested" assertions. In the case of
an <code>sp:TransportBinding</code> assertion, just indicating the use of
@@ -1521,7 +1520,7 @@
</wsdl:binding></eg>
</example>
<p>In some cases, companies may chose to implement their own
- assertions. When companies chose to become policy authors they need
+ assertions. When companies chose to become Assertion Authors they need
to consider not only the definition of the behavior that the
assertion represents but they need to consider how new assertions
will be intersected and merged with other assertions in the
@@ -1764,7 +1763,7 @@
</ulist>
</inform-div1>
<inform-div1 id="change-log">
- <head>&guidelines.title; Change Log</head>
+ <head>&guideline.title; Change Log</head>
<table id="ws-policy-primer-changelog-table" border="1">
<tbody>
<tr>
@@ -1857,6 +1856,30 @@
<td>Formatted examples in <specref ref="compact-full"/> and <specref ref="scenario"/>.
</td>
</tr>
+ <tr>
+ <td>20061219</td>
+ <td>TIB</td>
+ <td>Editorial revision: most parts of editorial action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/96">96</loc>.
+ Remaining editorials to be reviewed.
+ </td>
+ </tr>
+ <tr>
+ <td>20061220</td>
+ <td>TIB</td>
+ <td>Editorial revision: completed missing parts of editorial action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/96">96</loc>
+ after editorial reviews by co-editors.
+ </td>
+ </tr>
+ <tr>
+ <td>20061226</td>
+ <td>MH</td>
+ <td>Editorial revision: reconciled terms related to "Assertion Authors"
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/106">106</loc>
+ and bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=3983
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Index: ws-policy-framework-tr20070228.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-framework-tr20070228.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-framework-tr20070228.xml 22 Mar 2007 07:11:39 -0000 1.2
+++ ws-policy-framework-tr20070228.xml 23 Mar 2007 00:44:07 -0000 1.3
@@ -129,20 +129,20 @@
<eg xml:space="preserve">
(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
(02) <wsp:ExactlyOne>
(03) <wsp:All>
-(04) <sp:SignedParts/>
+(04) <sp:SignedParts/>
(05) <sp:Body/>
-(06) </sp:SignedParts/>
-(07) </wsp:All>
+(06) </sp:SignedParts/>
+(07) </wsp:All>
(08) <wsp:All>
-(09) <sp:EncryptedParts/>
+(09) <sp:EncryptedParts/>
(10) <sp:Body/>
-(11) </sp:EncryptedParts/>
-(12) </wsp:All>
-(13) </wsp:ExactlyOne>
+(11) </sp:EncryptedParts/>
+(12) </wsp:All>
+(13) </wsp:ExactlyOne>
(14) </wsp:Policy></eg>
</example>
<p>Lines (03-06) represent one
@@ -565,10 +565,10 @@
the normal form of a policy expression is as follows:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:Policy … >
- <wsp:ExactlyOne>
- ( <wsp:All> ( <<emph>Assertion</emph> …> … </<emph>Assertion</emph>> )* </wsp:All> )*
- </wsp:ExactlyOne>
-</wsp:Policy> </eg>
+ <wsp:ExactlyOne>
+ ( <wsp:All> ( <<emph>Assertion</emph> …> … </<emph>Assertion</emph>> )* </wsp:All> )*
+ </wsp:ExactlyOne>
+</wsp:Policy> </eg>
<p>The following describes the Element Information Items defined in the schema outline above:</p>
<glist><gitem>
<label><el>/wsp:Policy</el></label>
@@ -619,20 +619,20 @@
<p>For example, the following is the normal form of a policy expression.</p>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
-(02) <wsp:ExactlyOne>
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+(02) <wsp:ExactlyOne>
(03) <wsp:All>
-(04) <sp:SignedParts/>
+(04) <sp:SignedParts/>
(05) <sp:Body/>
-(06) </sp:SignedParts/>
-(07) </wsp:All>
+(06) </sp:SignedParts/>
+(07) </wsp:All>
(08) <wsp:All>
-(09) <sp:EncryptedParts/>
+(09) <sp:EncryptedParts/>
(10) <sp:Body/>
-(11) </sp:EncryptedParts/>
-(12) </wsp:All>
-(13) </wsp:ExactlyOne>
+(11) </sp:EncryptedParts/>
+(12) </wsp:All>
+(13) </wsp:ExactlyOne>
(14) </wsp:Policy></eg>
<p>Lines (03-07) and Lines (08-11) express the two alternatives in the
@@ -647,9 +647,9 @@
for attributes to associate an IRI is as follows:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:Policy ( Name="<emph>xs:anyURI</emph>" )?
- ( wsu:Id="<emph>xs:ID</emph>" | xml:id="<emph>xs:ID</emph>" )?
- … >
- …
+ ( wsu:Id="<emph>xs:ID</emph>" | xml:id="<emph>xs:ID</emph>" )?
+ … >
+ …
</wsp:Policy></eg>
<p>The following describes the Attribute Information Items listed and defined in the schema outline above:</p>
<glist><gitem>
@@ -688,16 +688,16 @@
<code>"http://www.example.com/policies/P1"</code>:</p>
<eg xml:space="preserve">(01) <wsp:Policy
- Name="http://www.example.com/policies/P1"
- xmlns:wsp="&nsuri;" >
-(02) <!-- Details omitted for readability -->
+ Name="http://www.example.com/policies/P1"
+ xmlns:wsp="&nsuri;" >
+(02) <!-- Details omitted for readability -->
(03) </wsp:Policy></eg>
<p>The following example illustrates how to associate a policy expression with the IRI-reference <code>"#P1"</code>:</p>
<eg xml:space="preserve">(01) <wsp:Policy
- wsu:Id="P1"
- xmlns:wsp="&nsuri;"
- xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" >
-(02) <!-- Details omitted for readability -->
+ wsu:Id="P1"
+ xmlns:wsp="&nsuri;"
+ xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" >
+(02) <!-- Details omitted for readability -->
(03) </wsp:Policy></eg>
</div2>
<div2 id="Compact_Policy_Expression">
@@ -733,12 +733,12 @@
<label><att>/Assertion/@wsp:Optional</att></label>
<def><p>If the actual value (See XML Schema Part 1 [<bibref ref="XMLSchemaPart1"/>]) is true, the expression of the assertion is semantically equivalent to the following:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:ExactlyOne>
- <wsp:All> <<emph>Assertion</emph> …> … </<emph>Assertion</emph>> </wsp:All>
- <wsp:All />
+ <wsp:All> <<emph>Assertion</emph> …> … </<emph>Assertion</emph>> </wsp:All>
+ <wsp:All />
</wsp:ExactlyOne></eg>
<p>If the actual value (See XML Schema Part 1 [<bibref ref="XMLSchemaPart1"/>]) is false, the expression of the assertion is semantically equivalent to the following:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:ExactlyOne>
- <wsp:All> <<emph>Assertion</emph> …> … </<emph>Assertion</emph>> </wsp:All>
+ <wsp:All> <<emph>Assertion</emph> …> … </<emph>Assertion</emph>> </wsp:All>
</wsp:ExactlyOne></eg>
<p>Omitting this attribute is semantically equivalent to including it
@@ -750,20 +750,20 @@
</glist>
<p>For example, the following compact policy expression:</p>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
-(02) <sp:IncludeTimestamp wsp:Optional="true" />
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+(02) <sp:IncludeTimestamp wsp:Optional="true" />
(03) </wsp:Policy></eg>
<p>is equivalent to the following normal form policy expression:</p>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
-(02) <wsp:ExactlyOne>
-(03) <wsp:All>
-(04) <sp:IncludeTimestamp />
-(05) </wsp:All>
-(06) <wsp:All />
-(07) </wsp:ExactlyOne>
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+(02) <wsp:ExactlyOne>
+(03) <wsp:All>
+(04) <sp:IncludeTimestamp />
+(05) </wsp:All>
+(06) <wsp:All />
+(07) </wsp:ExactlyOne>
(08) </wsp:Policy></eg>
<p>The <att>@wsp:Optional</att> attribute in Line (02) of the first
@@ -783,9 +783,9 @@
outline for a <termref def="nested_policy_expression">nested policy expression</termref> is:</p>
<eg xml:space="preserve" role="needs-numbering"><<emph>Assertion</emph> …>
- …
- ( <wsp:Policy …> … </wsp:Policy> )?
- …
+ …
+ ( <wsp:Policy …> … </wsp:Policy> )?
+ …
</<emph>Assertion</emph>></eg>
<p>The following describes additional processing constraints on the outline listed above:</p>
<glist><gitem>
@@ -812,9 +812,9 @@
role="infoset-property">children</emph> as in:
<eg>
(01)<wsp:Policy>
-(02) <Lorem>
-(03) <Ipsum>
-(04) <wsp:Policy>
+(02) <Lorem>
+(03) <Ipsum>
+(04) <wsp:Policy>
(05) …
(06) </wsp:Policy>
(07) </Ipsum>
@@ -840,26 +840,26 @@
<p>For example, consider the following policy expression with
nested policy expressions in a compact form:</p>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
-(02) <sp:TransportBinding>
-(03) <wsp:Policy>
-(04) <sp:AlgorithmSuite>
-(05) <wsp:Policy>
-(06) <wsp:ExactlyOne>
-(07) <sp:Basic256Rsa15 />
-(08) <sp:TripleDesRsa15 />
-(09) </wsp:ExactlyOne>
-(10) </wsp:Policy>
-(11) </sp:AlgorithmSuite>
-(12) <sp:TransportToken>
-(13) <wsp:Policy>
-(14) <sp:HttpsToken RequireClientCertificate="false" />
-(15) </wsp:Policy>
-(16) </sp:TransportToken>
- <!-- Details omitted for readability -->
-(17) </wsp:Policy>
-(18) </sp:TransportBinding>
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+(02) <sp:TransportBinding>
+(03) <wsp:Policy>
+(04) <sp:AlgorithmSuite>
+(05) <wsp:Policy>
+(06) <wsp:ExactlyOne>
+(07) <sp:Basic256Rsa15 />
+(08) <sp:TripleDesRsa15 />
+(09) </wsp:ExactlyOne>
+(10) </wsp:Policy>
+(11) </sp:AlgorithmSuite>
+(12) <sp:TransportToken>
+(13) <wsp:Policy>
+(14) <sp:HttpsToken RequireClientCertificate="false" />
+(15) </wsp:Policy>
+(16) </sp:TransportToken>
+ <!-- Details omitted for readability -->
+(17) </wsp:Policy>
+(18) </sp:TransportBinding>
(19) </wsp:Policy></eg>
<p>Lines (02-18) in this policy expression contain a single transport
binding security policy assertion; within its nested policy expression
@@ -872,44 +872,44 @@
assertion.</p>
<p>The example above is equivalent to the following:</p>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
-(02) <wsp:ExactlyOne>
-(03) <wsp:All>
-(04) <sp:TransportBinding>
-(05) <wsp:Policy>
-(06) <sp:AlgorithmSuite>
-(07) <wsp:Policy>
-(08) <sp:Basic256Rsa15 />
-(09) </wsp:Policy>
-(10) </sp:AlgorithmSuite>
-(11) <sp:TransportToken>
-(12) <wsp:Policy>
-(13) <sp:HttpsToken RequireClientCertificate="false" />
-(14) </wsp:Policy>
-(15) </sp:TransportToken>
- <!-- Details omitted for readability -->
-(16) </wsp:Policy>
-(17) </sp:TransportBinding>
-(18) </wsp:All>
-(19) <wsp:All>
-(20) <sp:TransportBinding>
-(21) <wsp:Policy>
-(22) <sp:AlgorithmSuite>
-(23) <wsp:Policy>
-(24) <sp:TripleDesRsa15 />
-(25) </wsp:Policy>
-(26) </sp:AlgorithmSuite>
-(27) <sp:TransportToken>
-(28) <wsp:Policy>
-(29) <sp:HttpsToken RequireClientCertificate="false" />
-(30) </wsp:Policy>
-(31) </sp:TransportToken>
- <!-- Details omitted for readability -->
-(32) </wsp:Policy>
-(33) </sp:TransportBinding>
-(34) </wsp:All>
-(35) </wsp:ExactlyOne>
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+(02) <wsp:ExactlyOne>
+(03) <wsp:All>
+(04) <sp:TransportBinding>
+(05) <wsp:Policy>
+(06) <sp:AlgorithmSuite>
+(07) <wsp:Policy>
+(08) <sp:Basic256Rsa15 />
+(09) </wsp:Policy>
+(10) </sp:AlgorithmSuite>
+(11) <sp:TransportToken>
+(12) <wsp:Policy>
+(13) <sp:HttpsToken RequireClientCertificate="false" />
+(14) </wsp:Policy>
+(15) </sp:TransportToken>
+ <!-- Details omitted for readability -->
+(16) </wsp:Policy>
+(17) </sp:TransportBinding>
+(18) </wsp:All>
+(19) <wsp:All>
+(20) <sp:TransportBinding>
+(21) <wsp:Policy>
+(22) <sp:AlgorithmSuite>
+(23) <wsp:Policy>
+(24) <sp:TripleDesRsa15 />
+(25) </wsp:Policy>
+(26) </sp:AlgorithmSuite>
+(27) <sp:TransportToken>
+(28) <wsp:Policy>
+(29) <sp:HttpsToken RequireClientCertificate="false" />
+(30) </wsp:Policy>
+(31) </sp:TransportToken>
+ <!-- Details omitted for readability -->
+(32) </wsp:Policy>
+(33) </sp:TransportBinding>
+(34) </wsp:All>
+(35) </wsp:ExactlyOne>
(36) </wsp:Policy></eg>
<p>In the listing above, the transport binding and its nested policy
expression have been duplicated once for each of the nested
@@ -1073,86 +1073,86 @@
<eg xml:space="preserve" role="needs-numbering"><wsp:All> <emph><!-- assertion 2 --> <!-- assertion 1 --> </emph></wsp:All></eg>
<p>and:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:ExactlyOne>
- <emph><!-- assertion 1 --> <!-- assertion 2 --></emph>
+ <emph><!-- assertion 1 --> <!-- assertion 2 --></emph>
</wsp:ExactlyOne></eg>
<p>is equivalent to:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:ExactlyOne>
- <emph><!-- assertion 2 --> <!-- assertion 1 --></emph>
+ <emph><!-- assertion 2 --> <!-- assertion 1 --></emph>
</wsp:ExactlyOne></eg></def>
</gitem>
<gitem>
<label>Associative</label>
<def><p><el>wsp:All</el> and <el>wsp:ExactlyOne</el> are associative. For example,</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:All>
- <emph><!-- assertion 1 --></emph>
-<emph> </emph><wsp:All> <emph><!-- assertion 2 --> </emph></wsp:All>
+ <emph><!-- assertion 1 --></emph>
+<emph> </emph><wsp:All> <emph><!-- assertion 2 --> </emph></wsp:All>
</wsp:All></eg>
<p>is equivalent to:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:All> <emph><!-- assertion 1 --> <!-- assertion 2 --> </emph></wsp:All></eg>
<p>and:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:ExactlyOne>
- <emph><!-- assertion 1 --></emph>
-<emph> </emph><wsp:ExactlyOne> <emph><!-- assertion 2 --> </emph></wsp:ExactlyOne>
+ <emph><!-- assertion 1 --></emph>
+<emph> </emph><wsp:ExactlyOne> <emph><!-- assertion 2 --> </emph></wsp:ExactlyOne>
</wsp:ExactlyOne></eg>
<p>is equivalent to:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:ExactlyOne>
- <emph><!-- assertion 1 --> <!-- assertion 2 --></emph>
+ <emph><!-- assertion 1 --> <!-- assertion 2 --></emph>
</wsp:ExactlyOne></eg></def>
</gitem>
<gitem>
<label>Idempotent</label>
<def><p><el>wsp:All</el> and <el>wsp:ExactlyOne</el> are idempotent. For example,</p>
<eg xml:space="preserve" role="needs-numbering" ><wsp:All>
- <wsp:All> <emph><!-- assertion 1 --> <!-- assertion 2 --> </emph></wsp:All>
+ <wsp:All> <emph><!-- assertion 1 --> <!-- assertion 2 --> </emph></wsp:All>
</wsp:All></eg>
<p>is equivalent to:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:All> <emph><!-- assertion 1 --> <!-- assertion 2 --> </emph></wsp:All></eg>
<p>and:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:ExactlyOne>
- <wsp:ExactlyOne>
- <emph><!-- assertion 1 --> <!-- assertion 2 --></emph>
-<emph> </emph></wsp:ExactlyOne>
+ <wsp:ExactlyOne>
+ <emph><!-- assertion 1 --> <!-- assertion 2 --></emph>
+<emph> </emph></wsp:ExactlyOne>
</wsp:ExactlyOne></eg>
<p>is equivalent to:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:ExactlyOne>
- <emph><!-- assertion 1 --> <!-- assertion 2 --></emph>
+ <emph><!-- assertion 1 --> <!-- assertion 2 --></emph>
</wsp:ExactlyOne></eg></def>
</gitem>
<gitem>
<label>Distributive</label>
<def><p><el>wsp:All</el> distributes over <el>wsp:ExactlyOne</el>. For example,</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:All>
- <wsp:ExactlyOne>
-<emph> <!-- assertion 1 --></emph>
-<emph> <!-- assertion 2 --></emph>
- </wsp:ExactlyOne>
+ <wsp:ExactlyOne>
+<emph> <!-- assertion 1 --></emph>
+<emph> <!-- assertion 2 --></emph>
+ </wsp:ExactlyOne>
</wsp:All></eg>
<p>is equivalent to:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:ExactlyOne>
- <wsp:All>
-<emph> <!-- assertion 1 --></emph>
- </wsp:All>
- <wsp:All>
-<emph> <!-- assertion 2 --></emph>
- </wsp:All>
+ <wsp:All>
+<emph> <!-- assertion 1 --></emph>
+ </wsp:All>
+ <wsp:All>
+<emph> <!-- assertion 2 --></emph>
+ </wsp:All>
</wsp:ExactlyOne></eg>
<p>Similarly by repeatedly distributing wsp:All over wsp:ExactlyOne,</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:All>
- <wsp:ExactlyOne>
-<emph> <!-- assertion 1 --></emph>
-<emph> <!-- assertion 2 --></emph>
- </wsp:ExactlyOne>
- <wsp:ExactlyOne>
-<emph> <!-- assertion 3 --></emph>
-<emph> <!-- assertion 4 --></emph>
- </wsp:ExactlyOne>
+ <wsp:ExactlyOne>
+<emph> <!-- assertion 1 --></emph>
+<emph> <!-- assertion 2 --></emph>
+ </wsp:ExactlyOne>
+ <wsp:ExactlyOne>
+<emph> <!-- assertion 3 --></emph>
+<emph> <!-- assertion 4 --></emph>
+ </wsp:ExactlyOne>
</wsp:All></eg>
<p>is equivalent to:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:ExactlyOne>
- <wsp:All><emph><!-- assertion 1 --><!-- assertion 3 --></emph></wsp:All>
- <wsp:All><emph><!-- assertion 1 --><!-- assertion 4 --></emph></wsp:All>
- <wsp:All><emph><!-- assertion 2 --><!-- assertion 3 --></emph></wsp:All>
- <wsp:All><emph><!-- assertion 2 --><!-- assertion 4 --></emph></wsp:All>
+ <wsp:All><emph><!-- assertion 1 --><!-- assertion 3 --></emph></wsp:All>
+ <wsp:All><emph><!-- assertion 1 --><!-- assertion 4 --></emph></wsp:All>
+ <wsp:All><emph><!-- assertion 2 --><!-- assertion 3 --></emph></wsp:All>
+ <wsp:All><emph><!-- assertion 2 --><!-- assertion 4 --></emph></wsp:All>
</wsp:ExactlyOne></eg>
<p>Distributing <el>wsp:All</el> over an empty <el>wsp:ExactlyOne</el> is equivalent to no alternatives. For example,</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:All>
@@ -1162,23 +1162,23 @@
<eg xml:space="preserve" role="needs-numbering"><wsp:ExactlyOne /></eg>
<p>and:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:All>
- <wsp:ExactlyOne>
-<emph> <!-- assertion 1 --></emph>
-<emph> <!-- assertion 2 --></emph>
- </wsp:ExactlyOne>
- <wsp:ExactlyOne />
+ <wsp:ExactlyOne>
+<emph> <!-- assertion 1 --></emph>
+<emph> <!-- assertion 2 --></emph>
+ </wsp:ExactlyOne>
+ <wsp:ExactlyOne />
</wsp:All></eg>
<p>is equivalent to:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:ExactlyOne /></eg>
<p>For example, given the following compact policy expression:</p>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
-(02) <sp:RequireDerivedKeys wsp:Optional="true" />
-(03) <wsp:ExactlyOne>
-(04) <sp:WssUsernameToken10 />
-(05) <sp:WssUsernameToken11 />
-(06) </wsp:ExactlyOne>
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+(02) <sp:RequireDerivedKeys wsp:Optional="true" />
+(03) <wsp:ExactlyOne>
+(04) <sp:WssUsernameToken10 />
+(05) <sp:WssUsernameToken11 />
+(06) </wsp:ExactlyOne>
(07) </wsp:Policy></eg>
</def>
</gitem>
@@ -1191,44 +1191,44 @@
in Lines (04-05) yields:</p>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
-(02) <wsp:ExactlyOne>
-(03) <wsp:All> <!-- @wsp:Optional alternative with assertion -->
-(04) <sp:RequireDerivedKeys />
-(05) </wsp:All>
-(06) <wsp:All /> <!-- @wsp:Optional alternative without -->
-(07) </wsp:ExactlyOne>
-(08) <wsp:ExactlyOne>
-(09) <wsp:All>
-(10) <sp:WssUsernameToken10 />
-(11) </wsp:All>
-(12) <wsp:All>
-(13) <sp:WssUsernameToken11 />
-(14) </wsp:All>
-(15) </wsp:ExactlyOne>
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+(02) <wsp:ExactlyOne>
+(03) <wsp:All> <!-- @wsp:Optional alternative with assertion -->
+(04) <sp:RequireDerivedKeys />
+(05) </wsp:All>
+(06) <wsp:All /> <!-- @wsp:Optional alternative without -->
+(07) </wsp:ExactlyOne>
+(08) <wsp:ExactlyOne>
+(09) <wsp:All>
+(10) <sp:WssUsernameToken10 />
+(11) </wsp:All>
+(12) <wsp:All>
+(13) <sp:WssUsernameToken11 />
+(14) </wsp:All>
+(15) </wsp:ExactlyOne>
(16) </wsp:Policy></eg>
<p>Note that the assertion listed in Line (02) in the first listing expands into the two alternatives in Lines (03-06) in the second listing.</p>
<p>Finally, noting that <el>wsp:Policy</el> is equivalent to <el>wsp:All</el>, and distributing <el>wsp:All</el> over <el>wsp:ExactlyOne</el> yields the following normal form policy expression:</p>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
-(02) <wsp:ExactlyOne>
-(03) <wsp:All>
-(04) <sp:RequireDerivedKeys />
-(05) <sp:WssUsernameToken10 />
-(06) </wsp:All>
-(07) <wsp:All>
-(08) <sp:RequireDerivedKeys />
-(09) <sp:WssUsernameToken11 />
-(10) </wsp:All>
-(11) <wsp:All>
-(12) <sp:WssUsernameToken10 />
-(13) </wsp:All>
-(14) <wsp:All>
-(15) <sp:WssUsernameToken11 />
-(16) </wsp:All>
-(17) </wsp:ExactlyOne>
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+(02) <wsp:ExactlyOne>
+(03) <wsp:All>
+(04) <sp:RequireDerivedKeys />
+(05) <sp:WssUsernameToken10 />
+(06) </wsp:All>
+(07) <wsp:All>
+(08) <sp:RequireDerivedKeys />
+(09) <sp:WssUsernameToken11 />
+(10) </wsp:All>
+(11) <wsp:All>
+(12) <sp:WssUsernameToken10 />
+(13) </wsp:All>
+(14) <wsp:All>
+(15) <sp:WssUsernameToken11 />
+(16) </wsp:All>
+(17) </wsp:ExactlyOne>
(18) </wsp:Policy></eg>
<p>Note that the two alternatives listed in Lines (03-06) in the second listing are combined with the two alternatives listed in Lines (09-14) in the second listing to create four alternatives in the normalized policy, Lines (03-06), (07-10), (11-13), and (14-16).</p>
</div3>
@@ -1237,9 +1237,9 @@
<p>The <el>wsp:PolicyReference</el> element is used to reference <termref def="policy_expression">policy expressions</termref>. The semantics of the <el>wsp:PolicyReference</el> element are determined by the context in which it is used (for an example, see <specref ref="Policy_Inclusion"/>).</p>
<p>The schema outline for the <el>wsp:PolicyReference</el> element is as follows:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:PolicyReference
- URI="<emph>xs:anyURI</emph>"
- ( Digest="<emph>xs:base64Binary</emph>" ( DigestAlgorithm="<emph>xs:anyURI</emph>" )? )?
- … >
+ URI="<emph>xs:anyURI</emph>"
+ ( Digest="<emph>xs:base64Binary</emph>" ( DigestAlgorithm="<emph>xs:anyURI</emph>" )? )?
+ … >
…
</wsp:PolicyReference></eg>
<p>The following describes the Attribute and Element Information Items defined in the schema outline above:</p>
@@ -1255,7 +1255,7 @@
For an external policy expression, there is no requirement that the IRI
be resolvable; retrieval mechanisms are beyond the scope of this specification.
After retrieval, there is no requirement to check that the retrieved policy
-expression is associated (Section <specref ref="Policy_Identification"/>) with this IRI.
+expression is associated (Section <specref ref="Policy_Identification"/>) with this IRI.
The IRI included in the retrieved policy expression, if any, <rfc2119>MAY</rfc2119> be
different than the IRI used to retrieve the policy expression. </p></def>
</gitem>
@@ -1315,27 +1315,27 @@
<p>In the example below two policies include and extend a common policy. In the first example there is a single policy document containing two policy assertions. The expression is given an identifier but not a fully qualified location. The second and third expressions reference the first expression by URI indicating the referenced expression is within the document. </p>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;"
- xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
- wsu:Id="Protection" >
-(02) <sp:EncryptSignature wsp:Optional="true" />
-(03) <sp:ProtectTokens wsp:Optional="true" />
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;"
+ xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
+ wsu:Id="Protection" >
+(02) <sp:EncryptSignature wsp:Optional="true" />
+(03) <sp:ProtectTokens wsp:Optional="true" />
(04) </wsp:Policy>
</eg>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
-(02) <wsp:PolicyReference URI="#Protection" />
-(03) <sp:OnlySignEntireHeadersAndBody />
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+(02) <wsp:PolicyReference URI="#Protection" />
+(03) <sp:OnlySignEntireHeadersAndBody />
(04) </wsp:Policy>
</eg>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
-(02) <sp:IncludeTimestamp />
-(03) <wsp:PolicyReference URI="#Protection" />
-(04) <sp:OnlySignEntireHeadersAndBody />
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+(02) <sp:IncludeTimestamp />
+(03) <wsp:PolicyReference URI="#Protection" />
+(04) <sp:OnlySignEntireHeadersAndBody />
(05) </wsp:Policy></eg>
<p>There are times when it is desirable to "re-use" a portion of a policy expression. Generally, this can be accomplished by placing the common assertions in a separate policy expression and referencing it. </p>
</div3>
@@ -1451,72 +1451,72 @@
behavior indicated by multiple assertions of the same <termref def='policy_assertion_type'>policy assertion type</termref>.</p>
<p>As an example of intersection, consider two input policies in normal form:</p>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
- <!-- Policy P1 -->
-(02) <wsp:ExactlyOne>
-(03) <wsp:All> <!-- Alternative A1 -->
-(04) <sp:SignedElements>
-(05) <sp:XPath>/S:Envelope/S:Body</sp:XPath>
-(06) </sp:SignedElements>
-(07) <sp:EncryptedElements>
-(08) <sp:XPath>/S:Envelope/S:Body</sp:XPath>
-(09) </sp:EncryptedElements>
-(10) </wsp:All>
-(11) <wsp:All> <!-- Alternative A2 -->
-(12) <sp:SignedParts>
-(13) <sp:Body />
-(14) <sp:Header
- Namespace="http://www.w3.org/2005/08/addressing" />
-(15) </sp:SignedParts>
-(16) <sp:EncryptedParts>
-(17) <sp:Body />
-(18) </sp:EncryptedParts>
-(19) </wsp:All>
-(20) </wsp:ExactlyOne>
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+ <!-- Policy P1 -->
+(02) <wsp:ExactlyOne>
+(03) <wsp:All> <!-- Alternative A1 -->
+(04) <sp:SignedElements>
+(05) <sp:XPath>/S:Envelope/S:Body</sp:XPath>
+(06) </sp:SignedElements>
+(07) <sp:EncryptedElements>
+(08) <sp:XPath>/S:Envelope/S:Body</sp:XPath>
+(09) </sp:EncryptedElements>
+(10) </wsp:All>
+(11) <wsp:All> <!-- Alternative A2 -->
+(12) <sp:SignedParts>
+(13) <sp:Body />
+(14) <sp:Header
+ Namespace="http://www.w3.org/2005/08/addressing" />
+(15) </sp:SignedParts>
+(16) <sp:EncryptedParts>
+(17) <sp:Body />
+(18) </sp:EncryptedParts>
+(19) </wsp:All>
+(20) </wsp:ExactlyOne>
(21) </wsp:Policy></eg>
<p>The listing above contains two policy alternatives. The first alternative, (Lines 03-10) contains two policy assertions. One indicates which elements should be signed (Lines 04-06); its type is <el>sp:SignedElements</el> (Line 04), and its parameters include an XPath expression for the content to be signed (Line 05). The other assertion (Lines 07-09) has a similar structure: type (Line 07) and parameters (Line 08).</p>
<p>The second alternative (Lines 11-19) also contains two assertions, each with type (Line 12 and Line 16) and parameters (Lines 13-14 and Line 17).</p>
<p>As this example illustrates, compatibility between two policy assertions is based on assertion type and delegates parameter processing to domain-specific processing.</p>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
- <!-- Policy P2 -->
-(02) <wsp:ExactlyOne>
-(03) <wsp:All> <!-- Alternative A3 -->
-(04) <sp:SignedParts />
-(05) <sp:EncryptedParts>
-(06) <sp:Body />
-(07) </sp:EncryptedParts>
-(08) </wsp:All>
-(09) <wsp:All> <!-- Alternative A4 -->
-(10) <sp:SignedElements>
-(11) <sp:XPath>/S:Envelope/S:Body</sp:XPath>
-(12) </sp:SignedElements>
-(13) </wsp:All>
-(14) </wsp:ExactlyOne>
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+ <!-- Policy P2 -->
+(02) <wsp:ExactlyOne>
+(03) <wsp:All> <!-- Alternative A3 -->
+(04) <sp:SignedParts />
+(05) <sp:EncryptedParts>
+(06) <sp:Body />
+(07) </sp:EncryptedParts>
+(08) </wsp:All>
+(09) <wsp:All> <!-- Alternative A4 -->
+(10) <sp:SignedElements>
+(11) <sp:XPath>/S:Envelope/S:Body</sp:XPath>
+(12) </sp:SignedElements>
+(13) </wsp:All>
+(14) </wsp:ExactlyOne>
(15) </wsp:Policy></eg>
<p>Because there is only one alternative (A2) in policy P1 with the same vocabulary — the assertions have the same type — as another alternative (A3) in policy P2, the intersection is a policy with a single alternative that contains all of the assertions in A2 and in A3.</p>
<eg xml:space="preserve">(01) <wsp:Policy
- xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
- xmlns:wsp="&nsuri;" >
- <!-- Intersection of P1 and P2 -->
-(02) <wsp:ExactlyOne>
-(03) <wsp:All>
-(04) <sp:SignedParts >
-(05) <sp:Body />
-(06) <sp:Header
- Namespace="http://www.w3.org/2005/08/addressing" />
-(07) </sp:SignedParts>
-(08) <sp:EncryptedParts>
-(09) <sp:Body />
-(10) </sp:EncryptedParts>
-(11) <sp:SignedParts />
-(12) <sp:EncryptedParts>
-(13) <sp:Body />
-(14) </sp:EncryptedParts>
-(15) </wsp:All>
-(16) </wsp:ExactlyOne>
+ xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
+ xmlns:wsp="&nsuri;" >
+ <!-- Intersection of P1 and P2 -->
+(02) <wsp:ExactlyOne>
+(03) <wsp:All>
+(04) <sp:SignedParts >
+(05) <sp:Body />
+(06) <sp:Header
+ Namespace="http://www.w3.org/2005/08/addressing" />
+(07) </sp:SignedParts>
+(08) <sp:EncryptedParts>
+(09) <sp:Body />
+(10) </sp:EncryptedParts>
+(11) <sp:SignedParts />
+(12) <sp:EncryptedParts>
+(13) <sp:Body />
+(14) </sp:EncryptedParts>
+(15) </wsp:All>
+(16) </wsp:ExactlyOne>
(17) </wsp:Policy></eg>
<p>Note that there are > 1 assertions of the type
Received on Friday, 23 March 2007 00:44:14 UTC