- From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 28 Sep 2006 19:45:49 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv30249
Modified Files:
ws-policy-primer.html ws-policy-primer.xml
Log Message:
Completed making remaining changes to address issues reported by Paul Cotton. Fixing up the Acknowledgements is pending
Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -d -r1.13 -r1.14
--- ws-policy-primer.html 26 Sep 2006 07:31:51 -0000 1.13
+++ ws-policy-primer.html 28 Sep 2006 19:45:46 -0000 1.14
@@ -113,7 +113,7 @@
policy assertions, outlines guidelines for designing policy assertions and enumerates the
minimum requirements for describing policy assertions in specifications.</p>
<p>This is a non-normative document and does not provide a definitive specification of the Web
- Services Policy language. <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all the that are used in
+ Services Policy language. <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all the namespaces that are used in
this document. (XML elements without a namespace prefix are from the Web Services Policy XML
Namespace.)</p>
</div>
@@ -151,7 +151,7 @@
must be delivered reliably, whether a message must flow a transaction, etc. Exposing this
class of metadata about the capabilities and requirements of a Web service enables tools
to generate code modules for engaging these behaviors. Tools can use this metadata to
- check the compatibility of requestors and providers. Web Services Policy can be used to
+ check the compatibility of requesters and providers. Web Services Policy can be used to
represent the capabilities and requirements of a Web service. </p>
<p>Web Services Policy is a machine-readable language for representing the capabilities and
requirements of a Web service. These are called ‘policies’. Web Services Policy offers
@@ -177,10 +177,10 @@
</soap:Envelope></pre></div>
</div>
<p>This message uses message addressing headers. The <code>wsa:To</code>
- and<code>wsa:Action</code> header blocks identify the destination and the semantics
+ and <code>wsa:Action</code> header blocks identify the destination and the semantics
implied by this message respectively. (The prefix <code>wsa</code> is used here to denote
the Web Services Addressing XML Namespace. <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all the
- and prefixes that are used in this document.)</p>
+ namespaces and prefixes that are used in this document.)</p>
<p>Let us look at a fictitious scenario used in this document to illustrate the features of
the policy language. Tony is a Web service developer. He is building a client application
that retrieves real time stock quote information from Contoso, Ltd. Contoso supplies real
@@ -220,7 +220,7 @@
<code>wsap</code> is used here to denote the Web Services Addressing – WSDL Binding XML
Namespace.) This assertion identifies the use of Web Services Addressing information
headers. A policy-aware client can recognize this policy assertion, engage addressing
- automatically, and use headers such as<code>wsa:To</code> and <code>wsa:Action</code> in
+ automatically, and use headers such as <code>wsa:To</code> and <code>wsa:Action</code> in
SOAP Envelopes.</p>
<p>It is important to understand the association between the SOAP message and policy
expression in the above example. As you can see by careful examination of the message,
@@ -298,37 +298,32 @@
<ul>
<li>
<p>
- <a href="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/">Web Services
- Security Policy</a>
+ Web Services Security Policy [<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]
</p>
</li>
<li>
<p>
- <a href="http://schemas.xmlsoap.org/ws/2005/02/rm/policy/">Web Services Reliable
- Messaging Policy</a>
+ Web Services Reliable Messaging Policy [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>]
</p>
</li>
<li>
<p>
- <a href="http://schemas.xmlsoap.org/ws/2004/10/wsat/">Web Services Atomic
- Transaction</a>
+ Web Services Atomic Transaction [<cite><a href="#WS-Atomic">Web Services Atomic Transaction</a></cite>]
</p>
</li>
<li>
<p>
- <a href="http://schemas.xmlsoap.org/ws/2004/10/wsba/">Web Services Business Activity
- Framework</a>
+ Web Services Business Activity Framework [<cite><a href="#WS-BA">Web Services Business Activity Framework</a></cite>]
</p>
</li>
<li>
<p>
- <a href="http://schemas.xmlsoap.org/ws/2006/02/devprof/">Devices Profile for Web
- Services</a>
+ Devices Profile for Web Services [<cite><a href="#WS-Device">Devices Profile for Web Services</a></cite>]
</p>
</li>
<li>
<p>
- <a href="http://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934-d47f91b66228/infocard-techref-beta2-published.pdf">A Technical Reference for Windows CardSpace</a>
+ A Technical Reference for Windows CardSpace [<cite><a href="#WS-WinCard">A Technical Reference for Windows CardSpace</a></cite>]
</p>
</li>
<li>
@@ -342,10 +337,10 @@
<p>Policy assertions can be combined in different ways to express consistent combinations of
behaviors (capabilities and requirements). There are three policy operators for combining
policy assertions: <code>Policy</code>, <code>All</code> and <code>ExactlyOne</code>
- (the<code>Policy</code> operator is a synonym for<code>All).</code></p>
+ (the <code>Policy</code> operator is a synonym for <code>All).</code></p>
<p>Let us consider the <code>All</code> operator first. The policy expression in the example
below requires the use of addressing and transport-level security. There are two policy
- assertions. These assertions are combined using the<code>All</code> operator. Combining
+ assertions. These assertions are combined using the <code>All</code> operator. Combining
policy assertions using the <code>Policy</code> or <code>All</code> operator means that
all the behaviors represented by these assertions are required.</p>
<div class="exampleOuter">
@@ -369,7 +364,7 @@
assertion identifies the use of message-level security – such as <em>WS-Security
1.0</em> - for protecting messages. Policy-aware clients can recognize this policy
assertion, engage message-level security for protecting messages and use headers such
- as<code>wss:Security</code> in SOAP Envelopes.</p>
+ as <code>wss:Security</code> in SOAP Envelopes.</p>
<p>To allow the use of either transport- or message-level security, Contoso uses the
<code>ExactlyOne</code> policy operator. Policy assertions combined using the
<code>ExactlyOne</code> operator requires exactly one of the behaviors represented by
@@ -384,7 +379,7 @@
</div>
<p>Contoso requires the use of addressing and requires the use of either transport- or
message-level security for protecting messages. They represent this combination using
- the<code>All</code> and <code>ExactlyOne</code> operators. Policy operators can be mixed
+ the <code>All</code> and <code>ExactlyOne</code> operators. Policy operators can be mixed
to represent different combinations of behaviors (capabilities and requirements). The
policy expression in the example below requires the use of addressing and one of
transport- or message-level security for protecting messages.</p>
@@ -399,7 +394,7 @@
</All></pre></div>
</div>
<p>Using this policy expression, Contoso gives the choice of mechanisms for protecting
- messages to clients (or requestors).</p>
+ messages to clients (or requesters).</p>
</div>
<div class="div2">
@@ -413,6 +408,7 @@
the <code>mtom:OptimizedMimeSerialization</code> policy assertion (see the example below).</p>
<div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><i><span>Example 2-9. </span>Optimized MIME Serialization Policy Assertion</i></p>
+
<div class="exampleInner"><pre><mtom:OptimizedMimeSerialization /></pre></div>
</div>
<p>The <code>mtom:OptimizedMimeSerialization</code> element is a policy assertion. (The
@@ -474,7 +470,7 @@
<p>In the example below, the child <code>Policy</code> element is a nested policy expression
and further qualifies the behavior of the <code>sp:TransportBinding</code> policy
assertion. The <code>sp:TransportToken</code> is a nested policy assertion of
- the<code>sp:TransportBinding</code> policy assertion. The<code>sp:TransportToken</code>
+ the <code>sp:TransportBinding</code> policy assertion. The <code>sp:TransportToken</code>
assertion requires the use of a specific transport token and further qualifies the
behavior of the <code>sp:TransportBinding</code> policy assertion (which already requires
the use of transport-level security for protecting messages).</p>
@@ -497,7 +493,7 @@
</sp:TransportBinding></pre></div>
</div>
<p>The <code>sp:AlgorithmSuite</code> is a nested policy assertion of
- the<code>sp:TransportBinding</code> policy assertion. The<code>sp:AlgorithmSuite</code>
+ the <code>sp:TransportBinding</code> policy assertion. The <code>sp:AlgorithmSuite</code>
assertion requires the use of the algorithm suite identified by its nested policy
assertion (<code>sp:Basic256Rsa15</code>
<em>in the example above</em>) and further qualifies the behavior of the
@@ -513,7 +509,7 @@
<h3><a name="Referencing_Policy_Expressions"></a>2.8 Referencing Policy Expressions</h3>
<p>Contoso has numerous Web service offerings that provide different kinds of real-time
quotes and book information on securities such as
- <code>GetRealQuote</code>,<code>GetRealQuotes</code> and
+ <code>GetRealQuote</code>, <code>GetRealQuotes</code> and
<code>GetExtendedRealQuote</code>. To accommodate the diversity of Contoso’s customers,
Contoso supports multiple WSDL bindings for these Web services. Contoso provides
consistent ways to interact with their services and wants to represent these capabilities
@@ -540,7 +536,7 @@
<code>http://real.contoso.com/policy.xml#common. (</code>The absolute IRI is formed by
combining the document IRI, <code>#</code> and the value of the <code>wsu:Id</code>
attribute.)</p>
- <p>For re-use, a<code>PolicyReference</code> element can be used to reference a policy
+ <p>For re-use, a <code>PolicyReference</code> element can be used to reference a policy
expression as a standalone policy or within another policy expression. The example below
is a policy expression that re-uses the common policy expression above.</p>
<div class="exampleOuter">
@@ -594,13 +590,13 @@
descriptions.</p>
<p>In the example below, the <code>SecureBinding</code> WSDL binding description defines a
binding for an interface that provides real-time quotes and book information on
- securities. (The prefixes<code>wsdl</code> and <code>tns</code> are used here to denote
+ securities. (The prefixes <code>wsdl</code> and <code>tns</code> are used here to denote
the Web Services Description language XML namespace and target namespace of this WSDL
document.) To require the use of security for these offerings, Contoso attaches the secure
policy expression in the previous section to this binding description. The WSDL
<code>binding</code> element is a common policy attachment point. The secure policy
expression attached to the <code>SecureBinding</code> WSDL binding description applies to
- any message exchange associated with any<code>port</code> that supports this binding
+ any message exchange associated with any <code>port</code> that supports this binding
description. This includes all the message exchanges described by operations in the
<code>RealTimeDataInterface</code>.</p>
<div class="exampleOuter">
@@ -615,7 +611,7 @@
provides other kinds of data through Web services such as quotes delayed by 20 minutes and
security symbols through Web services (for example <code>GetDelayedQuote</code>,
<code>GetDelayedQuotes,</code>
- <code>GetSymbol</code> and<code>GetSymbols</code>). Contoso does not require the use of
+ <code>GetSymbol</code> and <code>GetSymbols</code>). Contoso does not require the use of
security for these services, but requires the use of addressing and allows the use of
optimization.</p>
<div class="exampleOuter">
@@ -704,8 +700,8 @@
Policy. A policy expression consists of a <code>Policy</code> wrapper element and a
variety of child and descendent elements. Child and descendent elements from the policy
language are <code>Policy, All</code>, <code>ExactlyOne</code>
- and<code>PolicyReference</code>. Other child elements of<code>Policy</code>,
- <code>All</code> and<code>ExactlyOne</code> are policy assertions. (The<code>Policy</code>
+ and <code>PolicyReference</code>. Other child elements of<code>Policy</code>,
+ <code>All</code> and <code>ExactlyOne</code> are policy assertions. (The <code>Policy</code>
element plays two roles: wrapper element and operator.) Policy assertions can contain a
nested policy expression. Policy assertions can also be marked optional to represent
behaviors that may be engaged (capabilities) for an interaction. The optional marker is
@@ -726,8 +722,8 @@
</Policy></pre></div>
</div>
<p>The <code>Policy</code> element is the wrapper element. The <code>All</code>
- and<code>ExactlyOne</code> elements are the policy operators. All other child elements
- of the<code>All</code> and <code>ExactlyOne</code> elements are policy assertions from
+ and <code>ExactlyOne</code> elements are the policy operators. All other child elements
+ of the <code>All</code> and <code>ExactlyOne</code> elements are policy assertions from
domains such as messaging, addressing, security, reliability and transactions.</p>
</div>
<div class="div2">
@@ -761,7 +757,7 @@
<p>The normal form consists of a <code>Policy</code> wrapper element and has one child
<code>ExactlyOne</code> element. This <code>ExactlyOne</code> element has zero or more
<code>All</code> child elements. Each of these <code>All</code> elements has zero or
- more policy assertions. The<code>PolicyReference</code> element and
+ more policy assertions. The <code>PolicyReference</code> element and
<code>wsp:Optional</code> attribute are not used in the normal form. And, a nested policy
expression in the normal form has at most one policy alternative.</p>
<p>The normal form represents a policy as a collection of policy alternatives and a policy
@@ -787,7 +783,7 @@
<p>Let us re-consider Contoso’s policy expression (see the example below). Contoso requires
the use of addressing and either transport- or message-level security and allows the use
of optimization. This policy expression is in the compact form and has four policy
- alternatives for requestors:</p>
+ alternatives for requesters:</p>
<ol>
<li>
<p>Requires the use of addressing and transport-level security</p>
@@ -948,7 +944,7 @@
</li>
<li>
<p>The <code>Policy</code> wrapper element and policy alternatives which correspond to
- the<code>Policy/ExactlyOne</code> element map to a policy.</p>
+ the <code>Policy/ExactlyOne</code> element map to a policy.</p>
</li>
</ul>
<p>The diagram below describes this mapping from the normal form of a policy expression to
@@ -958,7 +954,7 @@
<div class="div2">
<h3><a name="compatible-policies"></a>3.4 Compatible Policies</h3>
- <p>A provider, like Contoso, and a requestor, like Tony’s policy-aware client, may represent
+ <p>A provider, like Contoso, and a requester, like Tony’s policy-aware client, may represent
their capabilities and requirements for an interaction as policies and want to limit their
message exchanges to mutually compatible policies. Web Services Policy defines an
intersection mechanism for selecting compatible policy alternatives when there are two or
@@ -1032,8 +1028,8 @@
<p>In <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>, we looked into how Contoso attached
their policy expressions to the WSDL <code>binding</code> element. In addition to the WSDL
<code>binding</code> element, a policy expression can be attached to other WSDL elements
- such as <code>service</code>,<code>port</code>, <code>operation</code>
- and<code>message</code>. These elements are the WSDL policy attachment points in a WSDL
+ such as <code>service</code>, <code>port</code>, <code>operation</code>
+ and <code>message</code>. These elements are the WSDL policy attachment points in a WSDL
document.</p>
<p>The WSDL attachment points are partitioned (as illustrated below) into four policy
subjects: message, operation, endpoint and service. When attached, capabilities and
@@ -1043,7 +1039,7 @@
<p>The WSDL <code>service</code> element represents the service policy subject. Policy
expressions associated with a service policy subject apply to any message exchange using
any of the endpoints offered by that service.</p>
- <p>The WSDL <code>port</code>,<code>binding</code> and <code>portType</code> elements
+ <p>The WSDL <code>port</code>, <code>binding</code> and <code>portType</code> elements
collectively represent the endpoint policy subject. Policy expressions associated with an
endpoint policy subject apply to any message exchange made using that endpoint.</p>
<p>The WSDL <code>binding/operation</code> and <code>portType/operation</code> elements
@@ -1105,7 +1101,7 @@
<p>Multiple policy expressions may be attached to WSDL constructs. Let us consider how
Contoso could have used multiple policy expressions in a WSDL document. In the example
below, there are two policy expressions <code>#common2</code> and <code>#secure2</code>
- attached to the <code>SecureBinding</code> WSDL binding and<code>RealTimeDataPort</code>
+ attached to the <code>SecureBinding</code> WSDL binding and <code>RealTimeDataPort</code>
WSDL port descriptions.</p>
<div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><i><span>Example 3-9. </span>Multiple Policy Expressions Attached to Endpoint Policy Subject </i></p>
@@ -1144,10 +1140,10 @@
<p>The effective policy is the combination of two or more policy expressions attached to the
same policy subject. The combination of two policy expressions, also known as the merged
policy expression, is a new policy expression that combines these two policy expressions
- using the<code>All</code> policy operator.</p>
+ using the <code>All</code> policy operator.</p>
<p>The policy expression below is the combination of the two policy expressions attached to
the <code>SecureBinding</code> WSDL binding and <code>RealTimeDataPort</code> WSDL port
- descriptions. The<code>#common2</code> policy expression has two policy alternatives. The
+ descriptions. The <code>#common2</code> policy expression has two policy alternatives. The
<code>#secure2</code> policy expression has two policy alternatives<code>.</code> The
combination of these two policies is equivalent to Contoso’s secure policy in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a> and has four policy alternatives. In other
words, the combination of two policies is the cross product of alternatives in these two
@@ -1179,14 +1175,14 @@
<h3><a name="extensibility-and-versioning"></a>3.7 Extensibility and Versioning</h3>
<p>Web Services Policy language is an extensible language by design. The
- <code>Policy</code>,<code>ExactlyOne</code>, <code>All</code>
- and<code>PolicyReference</code> elements are extensible. The <code>Policy</code>,
+ <code>Policy</code>, <code>ExactlyOne</code>, <code>All</code>
+ and <code>PolicyReference</code> elements are extensible. The <code>Policy</code>,
<code>ExactlyOne</code> and <code>All</code> elements allow child element and attribute
extensibility. The <code>PolicyReference</code> element allows attribute extensibility.
Extensions must not use the policy language XML namespace name. A consuming processor
processes known attributes and elements, ignores unknown attributes and treats unknown
elements as policy assertions.</p>
- <p>Web Services Policy language enables simple versioning practices that allow requestors to
+ <p>Web Services Policy language enables simple versioning practices that allow requesters to
continue the use of any older policy alternatives in a backward compatible manner. This
allows service providers, like Contoso, to deploy new behaviors using additional policy
assertions without breaking compatibility with clients that rely on any older policy
@@ -1206,7 +1202,7 @@
</div>
<p>Over time, Contoso adds support for advanced behaviors: requiring the use of addressing
and message-level security for protecting messages. They added this advanced support
- without breaking compatibility with requestors that rely on addressing and transport-level
+ without breaking compatibility with requesters that rely on addressing and transport-level
security. The example below is Contoso’s version 2 policy expression. In this version,
Contoso’s adds a new policy alternative that requires the use of addressing and
message-level security. The clients that rely on addressing and transport-level security
@@ -1238,10 +1234,10 @@
same class of versioning best practices built into WSDL constructs such as service, port
and binding.</p>
<p>Let us look at tooling for unknown policy assertions. As service providers, like Contoso,
- incrementally deploy advanced behaviors, some requestors may not recognize these new
- policy assertions. As discussed before, these requestors may continue to interact using
+ incrementally deploy advanced behaviors, some requesters may not recognize these new
+ policy assertions. As discussed before, these requesters may continue to interact using
old policy alternatives. New policy assertions will emerge to represent new behaviors and
- slowly become part of everyday interoperable interaction between requestors and providers.
+ slowly become part of everyday interoperable interaction between requesters and providers.
Today, most tools use a practical tolerant strategy to process new or unrecognized policy
assertions. These tools consume such unrecognized assertions and designate these for user
intervention. As you would recognize, there is nothing new in this practice. This is
@@ -1314,16 +1310,16 @@
identified by this policy assertion.</p>
<p>The <code>sp:IssuedToken</code> policy assertion has three parameters:
<code>@sp:IncludeToken</code>, <code>sp:Issuer</code>
- and<code>sp:RequestSecurityTokenTemplate</code>.</p>
+ and <code>sp:RequestSecurityTokenTemplate</code>.</p>
<p>The <code>sp:IncludeToken</code> attribute is a parameter that contains information on
whether a security token should be included in messages or an external reference to the
- key of this security token should be used. The<code>sp:Issuer</code> parameter is an
+ key of this security token should be used. The <code>sp:Issuer</code> parameter is an
endpoint reference to a security token issuer. The
<code>sp:RequestSecurityTokenTemplate</code> parameter contains the necessary information
to request a security token from the specified issuer. Parameters are the opaque payload
of a Policy Assertion, carry useful information for engaging the behavior described by an
assertion and are preserved through policy processing such as normalize, merge and
- intersection. Requestors may use policy intersection to select a compatible policy
+ intersection. requesters may use policy intersection to select a compatible policy
alternative for an interaction. Assertion parameters do not affect the outcome of policy
intersection.</p>
<p>For the <code>sp:Issuer</code> policy assertion parameter, the assertion author uses the
@@ -1337,7 +1333,7 @@
<code>sp:IssuedToken</code> policy assertion. The
<code>sp:RequireInternalReference</code> assertion requires the use of an internal
reference for referencing the issued token. A nested policy assertion further qualifies a
- dependent behavior of its parent policy assertion. As mentioned earlier, requestors may
+ dependent behavior of its parent policy assertion. As mentioned earlier, requesters may
use policy intersection to select a compatible policy alternative for an interaction.
Nested policy assertions affect the outcome of policy intersection.</p>
<p>The <code>sp:IssuedToken</code> security policy assertion identifies a visible domain
@@ -1378,7 +1374,7 @@
<div class="div3">
<h4><a name="opt-in-behavior"></a>4.3.1 Opt-in behavior</h4>
- <p>An opt-in behavior refers to a requirement that providers and requestors must
+ <p>An opt-in behavior refers to a requirement that providers and requesters must
deliberately choose to engage for a successful web service interaction. Examples of such
behaviors are the use of optimization, message-level security, reliable messaging and
atomic transaction. Policy assertions are not necessary to interoperate on widespread
@@ -1394,7 +1390,7 @@
relevant to an interoperable interaction. Non-shared behaviors do not add any value for
tooling or interoperability. An example of a non-shared behavior is the use of logging
or auditing by the provider.</p>
- <p>Requestors may use the policy intersection to select a compatible policy alternative
+ <p>requesters may use the policy intersection to select a compatible policy alternative
for a Web service interaction. If an assertion only describes one participant’s behavior
then this assertion will not be present in the other participants’ policy and the policy
intersection will unnecessarily produce false negatives.</p>
@@ -1407,7 +1403,7 @@
service interoperability is the capability of disparate systems to exchange data using
common data formats and protocols such as messaging, security, reliability and
transaction. Such data formats and protocols manifest on the wire. Providers and
- requestors only rely on these wire messages that conform to such formats and protocols
+ requesters only rely on these wire messages that conform to such formats and protocols
for interoperability. If an assertion describes a behavior that does not manifest on the
wire then the assertion is not relevant to an interoperable interaction.</p>
<p>For example, say an assertion describes the privacy notice information of a provider
@@ -1417,6 +1413,7 @@
<p>If an assertion has no wire- or message-level visible behavior, then the interacting
participants may require some sort of additional non-repudiation mechanism to indicate
compliance with the assertion. Introducing an additional non-repudiation mechanism adds
+
unnecessary complexity to processing a policy assertion.</p>
</div>
</div>
@@ -1463,7 +1460,7 @@
<h4><a name="optional-behaviors"></a>4.4.1 Optional Behaviors</h4>
<p>A policy assertion identifies a domain specific behavior that is a requirement relevant
to a Web Service interaction. Policy assertions can be marked optional using
- the<code>wsp:Optional</code> attribute marker to represent behaviors that may be
+ the <code>wsp:Optional</code> attribute marker to represent behaviors that may be
engaged (capabilities) for an interaction. It is important to note that behavior (policy
assertion) and optional representation (<code>wsp:Optional</code> attribute) are
distinct ideas of the Web Services Policy language. Conflating these distinct ideas
@@ -1480,7 +1477,7 @@
<p>Policy assertion parameters are the opaque payload of an assertion. Parameters carry
additional useful information for engaging the behavior described by an assertion and
are preserved through policy processing such as normalize, merge and policy
- intersection. Requestors may use policy intersection to select a compatible policy
+ intersection. requesters may use policy intersection to select a compatible policy
alternative for an interaction. Assertion parameters do not affect the outcome of policy
intersection.</p>
<p>In the example below, <code>sp:Body</code> and <code>sp:Header</code> elements are the
@@ -1513,7 +1510,7 @@
<p>Do these assertions represent dependent behaviors?</p>
<p>If the answers are yes to both of these questions then leveraging nested policy
expressions is a good idea. Keep in mind that a nested policy expression participates in
- the policy intersection algorithm. If a requestor uses policy intersection to select a
+ 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
@@ -1625,7 +1622,11 @@
</div>
<div class="div3">
<h4><a name="versioning-policy-language"></a>4.4.8 Versioning Policy Language</h4>
- <p>EdNote: The WG is contemplating moving some or all of this material into a non-normative appendix of the framework or attachment document. User feedback is solicited</p>
+ <p>
+ <table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
+ The WG is contemplating moving some or all of this material into a non-normative appendix of the framework or attachment document. User feedback is solicited
+ </td></tr></table>
+ </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. Some of the possible new constructs that have been mentioned previously are: new operators, operator cardinality, policy identification, compact syntax, Policy Inclusion, security, referencing, attachment points, alternative
priority, effective dating, negotiation. </p>
<p>WS-Policy provides extensibility points on 6 elements with a combination of attribute and/or element extensibility.
@@ -1693,8 +1694,8 @@
</wsp:ExactlyOne>
</wsp:Policy></pre></div>
</div>
-<p>Because the wsp16:Choice alternative isn't understand in either normalized form, it will not be chosen as one of the alternatives and will effectively be ignored. Policy intersection may be more difficult with such compatible extensions. For example, the previous will "look"
-like it has a wsp16:Choice typed assertion. To determine intersection with a Policy that does not have the wsp16:Choice type assertion, domain specific processing would have to be done. However, there is an alternative that does not have the wsp16:Choice, so intersection would yield the expecteded result.
+<p>Because the wsp16:Choice alternative isn't understood in either normalized form, it will not be chosen as one of the alternatives and will effectively be ignored. Policy intersection may be more difficult with such compatible extensions. For example, the previous will "look"
+like it has a wsp16:Choice typed assertion. To determine intersection with a Policy that does not have the wsp16:Choice type assertion, domain specific processing would have to be done. However, there is an alternative that does not have the wsp16:Choice, so intersection would yield the expected result.
</p>
<p>Note: it is possible to add new names to the existing namespace, such as: </p>
<div class="exampleOuter"><p class="exampleHead" style="text-align: left"><i><span>Example 4-8. </span>Policy containing 1.5 and 1.6 Policies all in the 1.5 namespace</i></p>
@@ -1763,7 +1764,7 @@
<p>Policy attachment provides WSDL 1.1 and UDDI attachment points. It appears that exchange of Policy will be in the context of WSDL or UDDI.
WRT WSDL, the policy model is an extension of the WSDL definition. As such, it is likely that future versions of Policy will be exchanged as multiple Policy expressions within a WSDL. One alternative is that there would be a separate WSDL for each version of Policy. The problem of how to specify and query for compound documents is very difficult, so it is more likely that each version of Policy will be exchanged within a WSDL. </p>
-<p>We show an example of a new version of policy that allows Qname reference to Policies in the PolicyReference:</p>
+<p>We show an example of a new version of policy that allows QName reference to Policies in the PolicyReference:</p>
<div class="exampleOuter"><p class="exampleHead" style="text-align: left"><i><span>Example 4-12. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p>
<div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
@@ -1789,7 +1790,7 @@
...</pre></div>
</div>
-<p>The PolicyReference is attribute extensible. One example of an addition is a list of backup URIs for the policyReference:</p>
+<p>The PolicyReference element is attribute extensible. One example of an addition is a list of backup URIs for the PolicyReference:</p>
<div class="exampleOuter"><p class="exampleHead" style="text-align: left"><i><span>Example 4-13. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p>
<div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
@@ -1808,7 +1809,7 @@
<wsdl11:operation name="GetLastTradePrice" > ....
...</pre></div>
</div>
-<p>The policy framework specification says that any unknown attributes are ignored. Policy 1.5 processor will not understand the wsp16:alternateURI attribute, it will be ignored. A Policy 1.6 processor will understand the alternate URIs so it won't be ignored.</p>
+<p>The policy framework specification says that any unknown attributes are ignored. A Policy 1.5 processor will not understand the wsp16:alternateURI attribute, it will be ignored. A Policy 1.6 processor will understand the alternate URIs so it won't be ignored.</p>
<p>PolicyAttachment and AppliesTo also have extensibility points. We choose not to illustrate these at this time.</p>
</div>
@@ -2010,11 +2011,29 @@
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. The <a href="http://www.w3.org/TR/ws-addr-core/">latest version of Web Services Addressing 1.0
- Core</a> is available at http://www.w3.org/TR/ws-addr-core. </dd>
<dt class="label"><a name="WS-AddressingPolicy"></a>[WS-Addressing Policy] </dt><dd>
- <cite><a href="http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/">Web Services Addressing 1.0 - WSDL Binding</a></cite>, M. Gudgin, M. Hadley, T.
+ <cite><a href="http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/">Web Services Addressing - WSDL Binding</a></cite>, M. Gudgin, M. Hadley, T.
Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, 29 May 2006. This version of
the Web Services Addressing 1.0 - WSDL Binding is
http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/. The <a href="http://www.w3.org/TR/ws-addr-wsdl">latest version of Web Services Addressing 1.0 -
WSDL Binding</a> is available at http://www.w3.org/TR/ws-addr-wsdl. </dd>
+ <dt class="label"><a name="WS-Atomic"></a>[Web Services Atomic Transaction] </dt><dd>
+ <cite><a href="http://schemas.xmlsoap.org/ws/2004/10/wsat/">Web Services Atomic Transaction</a></cite>, L. P. Cabrera, et al, Authors.
+ Arjuna Technologies, Inc., BEA Systems, Inc., Hitachi Software, Inc., IONA Technologies, Inc.,
+ International Business Machines Corporation, and Microsoft Corporation,
+ February 2005. Available at http://schemas.xmlsoap.org/ws/2004/10/wsat/.</dd>
+ <dt class="label"><a name="WS-BA"></a>[Web Services Business Activity Framework] </dt><dd>
+ <cite><a href="http://schemas.xmlsoap.org/ws/2004/10/wsba/">Web Services Business Activity Framework</a></cite>, L. P. Cabrera, et al, Authors.
+ Arjuna Technologies, Inc., BEA Systems, Inc., Hitachi Software, Inc., IONA Technologies, Inc.,
+ International Business Machines Corporation, and Microsoft Corporation,
+ February 2005. Available at http://schemas.xmlsoap.org/ws/2004/10/wsba/.</dd>
+ <dt class="label"><a name="WS-Device"></a>[Devices Profile for Web Services] </dt><dd>
+ <cite><a href="http://schemas.xmlsoap.org/ws/2006/02/devprof/">Devices Profile for Web Services</a></cite>, S. Chan, et al, Authors.
+ Intel Corporation, Lexmark, Inc., Microsoft Corporation, and Richo Software, Inc.,
+ February 2006. Available at http://schemas.xmlsoap.org/ws/2006/02/devprof/.</dd>
+ <dt class="label"><a name="WS-WinCard"></a>[A Technical Reference for Windows CardSpace] </dt><dd>
+ <cite><a href="http://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934-d47f91b66228/infocard-techref-beta2-published.pdf">A Technical Reference for Windows CardSpace</a></cite>, Authors,
+ Microsoft Corporation,
+ August 2005. Available at http://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934-d47f91b66228/infocard-techref-beta2-published.pdf.</dd>
<dt class="label"><a name="WS-MetadataExchange"></a>[WS-MetadataExchange] </dt><dd>
<cite><a href="http://schemas.xmlsoap.org/ws/2004/09/mex/">Web Services Metadata Exchange (WS-MetadataExchange)</a></cite>, K. Ballinger,
et al, Authors. BEA Systems Inc., Computer Associates International, Inc., International
@@ -2030,18 +2049,23 @@
Wide Web Consortium, 27 March 2006. This version of the WSDL 2.0 specification is
http://www.w3.org/TR/2006/CR-wsdl20-20060327. The <a href="http://www.w3.org/TR/wsdl20/">latest version of WSDL 2.0</a> is available at http://www.w3.org/TR/wsdl20. </dd>
<dt class="label"><a name="WS-Policy"></a>[Web Services Policy Framework] </dt><dd>
- <cite><a href="ws-policy-framework.html">Web Services Policy 1.5 - Framework</a></cite>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
+ <cite><a href="http://www.w3.org/TR/ws-policy/">Web Services Policy 1.5 - Framework</a></cite>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
Boubez and P. Yendluri, Editors. World Wide Web Consortium, @@,
@@@@ @@@@. This version of the specification of the
- Web Services Policy 1.5 - Framework specification is ws-policy-framework.html. The <a href="http://www.w3.org/TR/ws-policy-framework">latest version of
- Web Services Policy 1.5 - Framework</a> is available at http://www.w3.org/TR/ws-policy-framework. </dd>
+ Web Services Policy 1.5 - Framework specification is ws-policy-framework.html. The <a href="http://www.w3.org/TR/ws-policy/">latest version of
+ Web Services Policy 1.5 - Framework</a> is available at http://www.w3.org/TR/ws-policy/. </dd>
<dt class="label"><a name="WS-PolicyAttachment"></a>[Web Services Policy Attachment] </dt><dd>
- <cite><a href="ws-policy-attachment.html">Web Services Policy 1.5 - Attachment</a></cite>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
+ <cite><a href="http://www.w3.org/TR/ws-policy-attach/">Web Services Policy 1.5 - Attachment</a></cite>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
Boubez and P. Yendluri, Editors. World Wide Web Consortium, @@,
@@@@ @@@@. This version of the specification of the
- Web Services Policy 1.5 - Attachment specification is ws-policy-attachment.html. The <a href="http://www.w3.org/TR/ws-policy-attachment">latest version of
+ Web Services Policy 1.5 - Attachment specification is ws-policy-attachment.html. The <a href="http://www.w3.org/TR/ws-policy-attach/">latest version of
Web Services Policy 1.5 - Attachment</a> is available at
- http://www.w3.org/TR/ws-policy-attachment. </dd>
+ http://www.w3.org/TR/ws-policy-attach/. </dd>
+ <dt class="label"><a name="WS-RM-Policy"></a>[Web Services Reliable Messaging Policy] </dt><dd>
+ <cite><a href="http://schemas.xmlsoap.org/ws/2005/02/rm/policy/">Web Services Reliable Messaging Policy</a></cite>, S. Bates, et al, Authors.
+ BEA Systems, Inc., International Business Machines Corporation, Microsoft Corporation,
+ and TIBCO Software Inc., February 2005. Available at
+ http://schemas.xmlsoap.org/ws/2005/02/rm/policy/. </dd>
<dt class="label"><a name="WS-Security2004"></a>[WS-Security 2004] </dt><dd>
<cite><a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">Web Services Security: SOAP Message Security 1.0</a></cite>, A. Nadalin, C.
Kaler, P. Hallam-Baker and R. Monzillo, Editors. Organization for the Advancement of
@@ -2071,7 +2095,7 @@
<p>
Members of the Working Group are (at the time of writing, and by
alphabetical order):
- Dimitar Angelov, Abbie Barbir, Charlton Barreto, Toufic Boubez (Layer 7 Technologies), Paul Cotton (Microsoft Corporation), Jeffrey Crump, Glen Daniels, Ruchith Fernando (WSO2), Christopher Ferris, William Henry, Frederick Hirsch, Maryann Hondo, Tom Jordahl, Philippe Le Hégaret (W3C/MIT), Jong Lee (BEA Systems, Inc.), Mark Little (JBoss Inc.), Ashok Malhotra, Monica Martin, Jeff Mischkinsky, Dale Moberg, Anthony Nadalin, David Orchard (BEA Systems, Inc.), Bijan Parsia (University of Manchester), Fabian Ritzmann, Daniel Roth (Microsoft Corporation), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Seumas Soltysik, Yakov Sverdlov (Computer Associates), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp, Prasad Yendluri.
+ Dimitar Angelov, Abbie Barbir, Charlton Barreto, Toufic Boubez (Layer 7 Technologies), Paul Cotton (Microsoft Corporation), Jeffrey Crump, Glen Daniels, Ruchith Fernando (WSO2), Christopher Ferris, William Henry, Frederick Hirsch, Maryann Hondo, Tom Jordahl, Philippe Le Hégaret (W3C/MIT), Jong Lee (BEA Systems, Inc.), Mark Little (JBoss Inc.), Ashok Malhotra, Monica Martin, Jeff Mischkinsky, Dale Moberg, Anthony Nadalin, David Orchard (BEA Systems, Inc.), Bijan Parsia (University of Manchester), Fabian Ritzmann, Daniel Roth (Microsoft Corporation), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Seumas Soltysik, Yakov Sverdlov (Computer Associates), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp, Prasad Yendluri (webMethods, Inc.).
</p>
<p>
@@ -2140,7 +2164,21 @@
to insert a reference to the Security Considerations section from the Framework document.
</td>
</tr>
-
+ <tr>
+ <td rowspan="1" colspan="1">20060926</td>
+ <td rowspan="1" colspan="1">PY</td>
+ <td rowspan="1" colspan="1">Made a first pass at the changes to address issues
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0165.html">reported by Paul Cotton.</a>
+ </td>
+ </tr>
+ <tr>
+ <td rowspan="1" colspan="1">20060928</td>
+ <td rowspan="1" colspan="1">PY</td>
+ <td rowspan="1" colspan="1">Completed making remaining changes to address issues
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0165.html">reported by Paul Cotton.</a>
+ Fixing up the Acknowledgements is pending
+ </td>
+ </tr>
</tbody>
</table><br>
</div>
Index: ws-policy-primer.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- ws-policy-primer.xml 26 Sep 2006 20:44:46 -0000 1.11
+++ ws-policy-primer.xml 28 Sep 2006 19:45:46 -0000 1.12
@@ -143,7 +143,7 @@
must be delivered reliably, whether a message must flow a transaction, etc. Exposing this
class of metadata about the capabilities and requirements of a Web service enables tools
to generate code modules for engaging these behaviors. Tools can use this metadata to
- check the compatibility of requestors and providers. Web Services Policy can be used to
+ check the compatibility of requesters and providers. Web Services Policy can be used to
represent the capabilities and requirements of a Web service. </p>
<p>Web Services Policy is a machine-readable language for representing the capabilities and
requirements of a Web service. These are called ‘policies’. Web Services Policy offers
@@ -287,39 +287,32 @@
<ulist>
<item>
<p>
- <loc href="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/">Web Services
- Security Policy</loc>
+ Web Services Security Policy [<bibref ref='WS-SecurityPolicy'/>]
</p>
</item>
<item>
<p>
- <loc href="http://schemas.xmlsoap.org/ws/2005/02/rm/policy/">Web Services Reliable
- Messaging Policy</loc>
+ Web Services Reliable Messaging Policy [<bibref ref='WS-RM-Policy'/>]
</p>
</item>
<item>
<p>
- <loc href="http://schemas.xmlsoap.org/ws/2004/10/wsat/">Web Services Atomic
- Transaction</loc>
+ Web Services Atomic Transaction [<bibref ref='WS-Atomic'/>]
</p>
</item>
<item>
<p>
- <loc href="http://schemas.xmlsoap.org/ws/2004/10/wsba/">Web Services Business Activity
- Framework</loc>
+ Web Services Business Activity Framework [<bibref ref='WS-BA'/>]
</p>
</item>
<item>
<p>
- <loc href="http://schemas.xmlsoap.org/ws/2006/02/devprof/">Devices Profile for Web
- Services</loc>
+ Devices Profile for Web Services [<bibref ref='WS-Device'/>]
</p>
</item>
<item>
<p>
- <loc
- href="http://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934-d47f91b66228/infocard-techref-beta2-published.pdf"
- >A Technical Reference for Windows CardSpace</loc>
+ A Technical Reference for Windows CardSpace [<bibref ref='WS-WinCard'/>]
</p>
</item>
<item>
@@ -389,7 +382,7 @@
</All></eg>
</example>
<p>Using this policy expression, Contoso gives the choice of mechanisms for protecting
- messages to clients (or requestors).</p>
+ messages to clients (or requesters).</p>
</div2>
<div2 id="optional-policy-assertion">
<head>Optional Policy Assertion</head>
@@ -769,7 +762,7 @@
<p>Let us re-consider Contoso’s policy expression (see the example below). Contoso requires
the use of addressing and either transport- or message-level security and allows the use
of optimization. This policy expression is in the compact form and has four policy
- alternatives for requestors:</p>
+ alternatives for requesters:</p>
<olist>
<item>
<p>Requires the use of addressing and transport-level security</p>
@@ -940,7 +933,7 @@
</div2>
<div2 id="compatible-policies">
<head>Compatible Policies</head>
- <p>A provider, like Contoso, and a requestor, like Tony’s policy-aware client, may represent
+ <p>A provider, like Contoso, and a requester, like Tony’s policy-aware client, may represent
their capabilities and requirements for an interaction as policies and want to limit their
message exchanges to mutually compatible policies. Web Services Policy defines an
intersection mechanism for selecting compatible policy alternatives when there are two or
@@ -1168,7 +1161,7 @@
Extensions must not use the policy language XML namespace name. A consuming processor
processes known attributes and elements, ignores unknown attributes and treats unknown
elements as policy assertions.</p>
- <p>Web Services Policy language enables simple versioning practices that allow requestors to
+ <p>Web Services Policy language enables simple versioning practices that allow requesters to
continue the use of any older policy alternatives in a backward compatible manner. This
allows service providers, like Contoso, to deploy new behaviors using additional policy
assertions without breaking compatibility with clients that rely on any older policy
@@ -1188,7 +1181,7 @@
</example>
<p>Over time, Contoso adds support for advanced behaviors: requiring the use of addressing
and message-level security for protecting messages. They added this advanced support
- without breaking compatibility with requestors that rely on addressing and transport-level
+ without breaking compatibility with requesters that rely on addressing and transport-level
security. The example below is Contoso’s version 2 policy expression. In this version,
Contoso’s adds a new policy alternative that requires the use of addressing and
message-level security. The clients that rely on addressing and transport-level security
@@ -1220,10 +1213,10 @@
same class of versioning best practices built into WSDL constructs such as service, port
and binding.</p>
<p>Let us look at tooling for unknown policy assertions. As service providers, like Contoso,
- incrementally deploy advanced behaviors, some requestors may not recognize these new
- policy assertions. As discussed before, these requestors may continue to interact using
+ incrementally deploy advanced behaviors, some requesters may not recognize these new
+ policy assertions. As discussed before, these requesters may continue to interact using
old policy alternatives. New policy assertions will emerge to represent new behaviors and
- slowly become part of everyday interoperable interaction between requestors and providers.
+ slowly become part of everyday interoperable interaction between requesters and providers.
Today, most tools use a practical tolerant strategy to process new or unrecognized policy
assertions. These tools consume such unrecognized assertions and designate these for user
intervention. As you would recognize, there is nothing new in this practice. This is
@@ -1302,7 +1295,7 @@
to request a security token from the specified issuer. Parameters are the opaque payload
of a Policy Assertion, carry useful information for engaging the behavior described by an
assertion and are preserved through policy processing such as normalize, merge and
- intersection. Requestors may use policy intersection to select a compatible policy
+ intersection. requesters may use policy intersection to select a compatible policy
alternative for an interaction. Assertion parameters do not affect the outcome of policy
intersection.</p>
<p>For the <code>sp:Issuer</code> policy assertion parameter, the assertion author uses the
@@ -1316,7 +1309,7 @@
<code>sp:IssuedToken</code> policy assertion. The
<code>sp:RequireInternalReference</code> assertion requires the use of an internal
reference for referencing the issued token. A nested policy assertion further qualifies a
- dependent behavior of its parent policy assertion. As mentioned earlier, requestors may
+ dependent behavior of its parent policy assertion. As mentioned earlier, requesters may
use policy intersection to select a compatible policy alternative for an interaction.
Nested policy assertions affect the outcome of policy intersection.</p>
<p>The <code>sp:IssuedToken</code> security policy assertion identifies a visible domain
@@ -1355,7 +1348,7 @@
represented by a useful policy assertion: opt-in, shared and visible.</p>
<div3 id="opt-in-behavior">
<head>Opt-in behavior</head>
- <p>An opt-in behavior refers to a requirement that providers and requestors must
+ <p>An opt-in behavior refers to a requirement that providers and requesters must
deliberately choose to engage for a successful web service interaction. Examples of such
behaviors are the use of optimization, message-level security, reliable messaging and
atomic transaction. Policy assertions are not necessary to interoperate on widespread
@@ -1370,7 +1363,7 @@
relevant to an interoperable interaction. Non-shared behaviors do not add any value for
tooling or interoperability. An example of a non-shared behavior is the use of logging
or auditing by the provider.</p>
- <p>Requestors may use the policy intersection to select a compatible policy alternative
+ <p>requesters may use the policy intersection to select a compatible policy alternative
for a Web service interaction. If an assertion only describes one participant’s behavior
then this assertion will not be present in the other participants’ policy and the policy
intersection will unnecessarily produce false negatives.</p>
@@ -1382,7 +1375,7 @@
service interoperability is the capability of disparate systems to exchange data using
common data formats and protocols such as messaging, security, reliability and
transaction. Such data formats and protocols manifest on the wire. Providers and
- requestors only rely on these wire messages that conform to such formats and protocols
+ requesters only rely on these wire messages that conform to such formats and protocols
for interoperability. If an assertion describes a behavior that does not manifest on the
wire then the assertion is not relevant to an interoperable interaction.</p>
<p>For example, say an assertion describes the privacy notice information of a provider
@@ -1452,7 +1445,7 @@
<p>Policy assertion parameters are the opaque payload of an assertion. Parameters carry
additional useful information for engaging the behavior described by an assertion and
are preserved through policy processing such as normalize, merge and policy
- intersection. Requestors may use policy intersection to select a compatible policy
+ intersection. requesters may use policy intersection to select a compatible policy
alternative for an interaction. Assertion parameters do not affect the outcome of policy
intersection.</p>
<p>In the example below, <code>sp:Body</code> and <code>sp:Header</code> elements are the
@@ -1484,7 +1477,7 @@
<p>Do these assertions represent dependent behaviors?</p>
<p>If the answers are yes to both of these questions then leveraging nested policy
expressions is a good idea. Keep in mind that a nested policy expression participates in
- the policy intersection algorithm. If a requestor uses policy intersection to select a
+ 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
@@ -1734,7 +1727,7 @@
<p>Policy attachment provides WSDL 1.1 and UDDI attachment points. It appears that exchange of Policy will be in the context of WSDL or UDDI.
WRT WSDL, the policy model is an extension of the WSDL definition. As such, it is likely that future versions of Policy will be exchanged as multiple Policy expressions within a WSDL. One alternative is that there would be a separate WSDL for each version of Policy. The problem of how to specify and query for compound documents is very difficult, so it is more likely that each version of Policy will be exchanged within a WSDL. </p>
-<p>We show an example of a new version of policy that allows Qname reference to Policies in the PolicyReference:</p>
+<p>We show an example of a new version of policy that allows QName reference to Policies in the PolicyReference:</p>
<example><head>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</head>
<eg><![CDATA[<wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
@@ -1985,12 +1978,30 @@
- Core</loc> is available at http://www.w3.org/TR/ws-addr-core. </bibl>
<bibl key="WS-Addressing Policy" id="WS-AddressingPolicy"
href="http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/">
- <titleref>Web Services Addressing 1.0 - WSDL Binding</titleref>, M. Gudgin, M. Hadley, T.
+ <titleref>Web Services Addressing - WSDL Binding</titleref>, M. Gudgin, M. Hadley, T.
Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, 29 May 2006. This version of
the Web Services Addressing 1.0 - WSDL Binding is
http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/. The <loc
href="http://www.w3.org/TR/ws-addr-wsdl">latest version of Web Services Addressing 1.0 -
WSDL Binding</loc> is available at http://www.w3.org/TR/ws-addr-wsdl. </bibl>
+ <bibl id="WS-Atomic" key="Web Services Atomic Transaction" href="http://schemas.xmlsoap.org/ws/2004/10/wsat/">
+ <titleref>Web Services Atomic Transaction</titleref>, L. P. Cabrera, et al, Authors.
+ Arjuna Technologies, Inc., BEA Systems, Inc., Hitachi Software, Inc., IONA Technologies, Inc.,
+ International Business Machines Corporation, and Microsoft Corporation,
+ February 2005. Available at http://schemas.xmlsoap.org/ws/2004/10/wsat/.</bibl>
+ <bibl id="WS-BA" key="Web Services Business Activity Framework" href="http://schemas.xmlsoap.org/ws/2004/10/wsba/">
+ <titleref>Web Services Business Activity Framework</titleref>, L. P. Cabrera, et al, Authors.
+ Arjuna Technologies, Inc., BEA Systems, Inc., Hitachi Software, Inc., IONA Technologies, Inc.,
+ International Business Machines Corporation, and Microsoft Corporation,
+ February 2005. Available at http://schemas.xmlsoap.org/ws/2004/10/wsba/.</bibl>
+ <bibl id="WS-Device" key="Devices Profile for Web Services" href="http://schemas.xmlsoap.org/ws/2006/02/devprof/">
+ <titleref>Devices Profile for Web Services</titleref>, S. Chan, et al, Authors.
+ Intel Corporation, Lexmark, Inc., Microsoft Corporation, and Richo Software, Inc.,
+ February 2006. Available at http://schemas.xmlsoap.org/ws/2006/02/devprof/.</bibl>
+ <bibl id="WS-WinCard" key="A Technical Reference for Windows CardSpace" href="http://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934-d47f91b66228/infocard-techref-beta2-published.pdf">
+ <titleref>A Technical Reference for Windows CardSpace</titleref>, Authors,
+ Microsoft Corporation,
+ August 2005. Available at http://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934-d47f91b66228/infocard-techref-beta2-published.pdf.</bibl>
<bibl id="WS-MetadataExchange" key="WS-MetadataExchange"
href="http://schemas.xmlsoap.org/ws/2004/09/mex/">
<titleref>Web Services Metadata Exchange (WS-MetadataExchange)</titleref>, K. Ballinger,
@@ -2009,22 +2020,27 @@
http://www.w3.org/TR/2006/CR-wsdl20-20060327. The <loc href="http://www.w3.org/TR/wsdl20/"
>latest version of WSDL 2.0</loc> is available at http://www.w3.org/TR/wsdl20. </bibl>
<bibl id="WS-Policy" key="Web Services Policy Framework"
- href="&w3c-designation-framework;">
+ href="http://www.w3.org/TR/ws-policy/">
<titleref>&framework.title;</titleref>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
Boubez and P. Yendluri, Editors. World Wide Web Consortium, &draft.day;,
&draft.month; &draft.year;. This version of the specification of the
&framework.title; specification is &w3c-designation-framework;. The <loc
- href="http://www.w3.org/TR/&framework.prefix;">latest version of
- &framework.title;</loc> is available at http://www.w3.org/TR/&framework.prefix;. </bibl>
+ href="http://www.w3.org/TR/ws-policy/">latest version of
+ &framework.title;</loc> is available at http://www.w3.org/TR/ws-policy/. </bibl>
<bibl id="WS-PolicyAttachment" key="Web Services Policy Attachment"
- href="&w3c-designation-attachment;">
+ href="http://www.w3.org/TR/ws-policy-attach/">
<titleref>&attachment.title;</titleref>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
Boubez and P. Yendluri, Editors. World Wide Web Consortium, &draft.day;,
&draft.month; &draft.year;. This version of the specification of the
&attachment.title; specification is &w3c-designation-attachment;. The <loc
- href="http://www.w3.org/TR/&attachment.prefix;">latest version of
+ href="http://www.w3.org/TR/ws-policy-attach/">latest version of
&attachment.title;</loc> is available at
- http://www.w3.org/TR/&attachment.prefix;. </bibl>
+ http://www.w3.org/TR/ws-policy-attach/. </bibl>
+ <bibl id="WS-RM-Policy" key="Web Services Reliable Messaging Policy" href="http://schemas.xmlsoap.org/ws/2005/02/rm/policy/">
+ <titleref>Web Services Reliable Messaging Policy</titleref>, S. Bates, et al, Authors.
+ BEA Systems, Inc., International Business Machines Corporation, Microsoft Corporation,
+ and TIBCO Software Inc., February 2005. Available at
+ http://schemas.xmlsoap.org/ws/2005/02/rm/policy/. </bibl>
<bibl id="WS-Security2004" key="WS-Security 2004"
href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">
<titleref>Web Services Security: SOAP Message Security 1.0</titleref>, A. Nadalin, C.
@@ -2115,9 +2131,16 @@
<tr>
<td>20060926</td>
<td>PY</td>
- <td>Made a first pass at making the editorial changes
+ <td>Made a first pass at the changes to address issues
<loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0165.html">reported by Paul Cotton.</loc>
- Acknowledgements and Reference fix-up pending
+ </td>
+ </tr>
+ <tr>
+ <td>20060928</td>
+ <td>PY</td>
+ <td>Completed making remaining changes to address issues
+ <loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0165.html">reported by Paul Cotton.</loc>
+ Fixing up the Acknowledgements is pending
</td>
</tr>
</tbody>
Received on Thursday, 28 September 2006 19:46:09 UTC