- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 30 Nov 2006 04:04:21 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv10608
Modified Files:
ws-policy-guidelines.xml
Log Message:
Editorial revision related to editorial actions 84 and 90
Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -d -r1.16 -r1.17
--- ws-policy-guidelines.xml 28 Nov 2006 23:05:15 -0000 1.16
+++ ws-policy-guidelines.xml 30 Nov 2006 04:04:19 -0000 1.17
@@ -87,26 +87,26 @@
<p>The WS-Policy specification defines a policy to be a collection
of policy alternatives with each policy alternative a
- collection of policy assertions. Policy is a flexible framework to represent
- consistent compinations of behaviors from a variety of domains.
- A policy assertion is a machine readable metadata exxpression that
+ collection of policy assertions. The &framework.title; provides a flexible framework to
+ represent
+ 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>&guideline.title;</emph>
- is a resource primarily for assertion authors that provides
+ 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
- service by adhering to the specification, WS-Policy Framework. It
- was recognized that in order to enable interoperability of web
- services, different sets of WS-Policy Assertions needed to be
- defined by different communities based upon the requirements of
+ 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
the web service.
</p>
<p>The focus of these guidelines is to capture best practices
- and usage patterns for practitioners to follow. It is a
+ and usage patterns for practitioners. It is a
complementary guide to the Framework and Attachments
specifications and primer. It is intended to provide
non-normative guidelines for:
@@ -158,15 +158,14 @@
<head>What is an Assertion? </head>
<p>An assertion is a piece of metadata that describes a
- capability of a specific WS-Policy domain. Sets of assertions
- are typically defined in a dedicated specification that describe
+ capability related to a specific WS-Policy domain. Sets of domain-specific assertions
+ are typically defined in a dedicated specification that describes
their semantics, applicability and scoping requirements as well
as their data type definition using XML Schema.
</p>
- <p>Given that interoperability and automation are the motivations, policy assertions that
- represent, shared and visible behaviors are useful pieces of metadata. Such
- assertions enable tooling and improve interoperability. The key to understanding when to
+ <p>Policy assertions representing shared and visible behaviors are useful pieces of metadata to enable
+ interoperability and tooling for automation. The key to understanding when to
design policy assertions is to have clarity on the characteristics of a behavior
represented by a policy assertion. Some useful ways to discover relevant behaviors are
to ask questions like the following:
@@ -179,23 +178,26 @@
<item>
<p>Is the behavior visible?
</p>
- <p>A visible behavior refers to a requirement that manifests on the wire. Web services
+ <p>A visible behavior refers to a requirement that manifests itself on the wire. Web services
provide interoperable machine-to-machine interaction among disparate systems. Web
service interoperability is the capability of disparate systems to exchange data using
- common data formats and protocols such as messaging, security, reliability and
+ common data formats and protocols supporting characteristics such as messaging, security,
+ reliability and
transaction. Such data formats and protocols manifest on the wire. Providers and
- 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.
+ requesters rely on wire messages conforming to such formats and protocols
+ to achieve interoperability.
</p>
- <p>For example, say an assertion describes the privacy notice information of a provider
- and there is an associated regulatory safeguard in place on the provider’s side. Such
+ <p>If an assertion describes a behavior that does not manifest on the
+ wire then the assertion is not relevant to an interoperable interaction.
+ An example is an assertion that describes the privacy notice information of a provider
+ and the associated regulatory safeguard in place on the provider’s side. Such
assertions may represent business or regulatory level metadata but do not add any value
to interoperability.
</p>
- <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
+ <p>If an assertion has no wire or message-level visible behavior then the interacting
+ participants may require some sort of additional mechanism to indicate
+ compliance with the assertion and to enable dispute resolution.
+ Introducing an additional non-repudiation mechanism adds
unnecessary complexity to processing a policy assertion.
</p>
</item>
@@ -208,9 +210,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>requesters may use the policy intersection to select a compatible policy alternative
+ 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.
@@ -224,8 +224,8 @@
<item>
<p>Is there a requirement that a choice must be made for successful interaction?</p>
- <p>Some behaviors refer to a requirement that providers and requesters must deliberately choose
- to engage in. Examples, of such behaviors are the use of optimization, and reliable messaging.
+ <p>Sometimes providers and requesters are required to engage in certain behaviors.
+ The use of optimization and reliable messaging are two examples.
</p>
</item>
</ulist>
@@ -298,18 +298,17 @@
a way that multiple WS-Policy domains can co-exist and
consumers and providers can utilize the framework consistently across domains.
</p>
- <p>In order to take advantage of the WS-Policy Framework, any
- domain author attempting to define new WS-Policy assertions
- must adhere to the MUST's and SHOULD's in the specifications
+ <p>When using the WS-Policy Framework, any
+ domain author 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
the assertions they have defined with the policy subjects
- identified by the WS-PolicyAttachment specification
+ identified by the WS-PolicyAttachment specification.
</p>
- <p>An example of a domain specification that
- includes these properties can be seen in the WS-SecurityPolicy
- pecification [<bibref ref="WS-SecurityPolicy"/>]. The
+ <p>An example of a domain specification that follows these practices is the WS-SecurityPolicy
+ specification [<bibref ref="WS-SecurityPolicy"/>]. The
WS-SecurityPolicy authors have defined their scope as follows:
</p>
<p><emph>"This document [WS-SecurityPolicy] defines a set of
@@ -335,8 +334,8 @@
<head>Consumers</head>
<p>A consumer of WS-Policy
Assertions can be any entity that is capable of parsing a
- WS-Policy xml element, and selecting one alternative from the
- policy, that it then uses to govern the creation of a message
+ WS-Policy XML element and selecting one alternative from the
+ policy. This selected alternative is then used to govern the creation of a message
to send to the subject to which the policy alternative was
attached. The WS-Policy Attachment specification defines a
set of attachment models for use with common web service
@@ -347,7 +346,7 @@
References (EPR) [<bibref ref="WS-Addressing"/>].
</p>
<p>
- In the degenerate case, a human could read the xml and
+ In the degenerate case, a human could read the XML and
determine if a message could be constructed conformant to the
advertised policy.
</p>
@@ -362,7 +361,7 @@
<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
+ 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
@@ -372,7 +371,7 @@
it may also need to conform to requirements of other policy
specifications it utilizes ( i.e., WS-SecurityPolicy).
</p>
- <p>When deploying services with policies it is uesful for providers to anticipate how
+ <p>When deploying services with policies it is useful for providers to anticipate how
to evolve their services capabilities over time. If
forward compatibility is a concern in order to accommodate
compatibility with different and potentially new clients,
@@ -387,10 +386,10 @@
<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
- advantage of WS-Policy building on XML principles and XML Schema validation in their desgin. WS-Policy
- relies on the Qname of a policy assertion being an XML element but allows authors to optionally
+ 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
provide additional semantics through nesting assertions, or specifying assertion parameters.
- This section covers several aspects of assertion design and provides somes answers to the following questions:</p>
+ This section covers several aspects of assertion design and provides some answers to the following questions:</p>
<ulist>
<item>
<p>What is the intended use of the policy assertion?</p>
@@ -399,7 +398,7 @@
<p>Which authoring style will be used?</p>
</item>
<item>
- <p>Is this a new policy domain? does it need to compose with other domains?</p>
+ <p>Is this a new policy domain? Does it need to compose with other domains?</p>
</item>
<item>
<p>How complex are the assertions?</p>
@@ -439,7 +438,7 @@
stand alone client applications to "active" web service
requestors that are capable of modifying their own configurations dynamically.
</p>
- <p> Once the range of policy subjects are identified, there are choices for ways of
+ <p> Once the range of policy subjects is identified, there are choices for ways of
attaching multiple instances of a simple policy
assertion to multiple subjects. One way is to utilize
the referencing mechanism that is present in the
@@ -447,7 +446,7 @@
in different policies (e.g. with different
alternatives) via reference, a policy assertion may be
associated with different alternatives and subjects. A
- eferencing mechanism is very useful in a tooling
+ referencing mechanism is very useful in a tooling
environment; when creating a domain specific
attachment in multiple WSDL files or Endpoint
References in which the same set of policies are expected to be applied.
@@ -491,7 +490,7 @@
<div2 id="compact-full">
<head>Authoring Styles </head>
- <p> WS-Policy supports 2 different authoring styles. A compact form is one in which an expression consists of three
+ <p> WS-Policy supports two different authoring styles. A compact form is one in which an expression consists of three
constructs: an attribute to decorate an assertion (to indicate whether it is required or optional), semantics for
recursively nested policy operators, and a policy reference/inclusion mechanism.
</p>
@@ -559,7 +558,7 @@
in a policy, the normal form may express the choices more explicitly.
On the other hand, the compact form is more
readable for humans when an assertion is marked as optional
- using the <code>@optional</code> attribute as our example illustrates above.
+ using the <code>wsp:optional</code> attribute as our example illustrates above.
</p>
<p>Best practice: use the authoring style most appropriate for the target audience </p>
@@ -590,13 +589,13 @@
</p>
<p>It requires a good deal of effort to evaluate the
capabilities of a domain and capture them in a way that
- eflects the options of the domain if the domain has a lot of
+ reflects the options of the domain if the domain has a lot of
assertions to define. Interoperability testing of new policy
domains is recommended to ensure that consumers and providers
are able to use the new domain assertions.
</p>
<p>New authors are encouraged to look at <bibref ref="WS-RM-Policy"/> to see an example of a
- relatively simple domain that has defined 3 assertions. Domain authors are encouraged to look at <bibref
+ relatively simple domain that has defined three assertions. Domain 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
@@ -605,7 +604,7 @@
design work progresses, you may add more parameters or nested policy assertions to meet
your interoperability needs.
</p>
- <p>Best practice: start with a simple working assertion that allows extensibility.
+ <p>Best practice: Start with a simple working assertion that allows extensibility.
</p>
</div3>
<div3 id="QName_and_XML_Information_Set_representation">
@@ -621,7 +620,7 @@
document). If the assertion has a nested policy expression then the assertion XML
outline can enumerate the nested assertions that are allowed.
</p>
- <p>Best practice: use a unique QName to identify the behavior and provide an XML outline
+ <p>Best practice: Use a unique QName to identify the behavior and provide an XML outline
(plus an XML schema document) to specify the syntax of an assertion.
</p>
</div3>
@@ -670,9 +669,9 @@
<p>Another approach is to use of the assertion to selectively apply to subjects. For example, a
dedicated endpoint may be allocated to ensure the engagement of a
behavior that is expressed by a policy assertion. This approach
- can be considered when messages can not be self describing.
+ can be considered when messages cannot be self describing.
</p>
- <p>Best practice:Policy assertions should not be used to express the semantics of a message.
+ <p>Best practice: Policy assertions should not be used to express the semantics of a message.
</p>
</div3>
<div3 id="single-domains">
@@ -694,7 +693,7 @@
</p>
<p>The model advocated for new
assertion development is a cooperative marketplace
- [some might say its an "opt-in" model]. The providers
+ [some might say it is an "opt-in" model]. The providers
of services need to find value in the set of
assertions or they will not include the assertions in
their service descriptions.
@@ -808,25 +807,25 @@
</example>
<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>
<emph>in the example above</emph>) and further qualifies the behavior of the
<code>sp:TransportBinding</code> policy assertion.
</p>
<p>Setting aside the details of using transport-level
- security,, a policy-aware client that recognizes this policy
+ security, a policy-aware client that recognizes this policy
assertion can engage transport-level security and its
- dependent behaviors automatically. That is, the complexity of
+ dependent behaviors automatically. This means the complexity of
security usage is absorbed by a policy-aware client and hidden
- from these Web service developers.
+ from Web service application developers.
</p>
</div3>
<div3 id="which-one-to-use">
<head>Considerations for choosing parameters vs nesting</head>
<p>The main consideration for selecting parameters or nesting
- of assertions, is that <emph>the framework intersection
+ of assertions is that <emph>the framework intersection
algorithm processes nested alternatives, but does not consider
parameters in its algorithm</emph>.
</p>
@@ -844,9 +843,15 @@
vs. the flexibility and complexity of the comparison expected for a domain. </p>
<p>
The following design questions below can help
- you to determine when to use nested policy expressions:</p>
+ to determine when to use nested policy expressions:</p>
+ <ulist>
+ <item>
<p>Are these assertions designed for the same policy subject? </p>
+ </item>
+ <item>
<p>Do these assertions represent dependent behaviors?</p>
+ </item>
+ </ulist>
<p>If the answers are yes to both of these questions then leveraging nested policy
expressions is something to consider. Keep in mind that a nested policy expression participates in
the policy intersection algorithm. If a requester uses policy intersection to select a
@@ -869,7 +874,7 @@
<head>Optional behavior in Compact authoring</head>
<p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
compact authoring form for assertions, behaviors are marked by
- using <code>wsp:optional</code> attribute that has a value,
+ using <code>wsp:Optional</code> attribute that has a value,
"true". During the process of normalization, the runtime
behavior is indicated by two policy alternatives, one with and
one without the assertion. In a consumer/provider
@@ -894,7 +899,7 @@
<p>The semantics of this assertion declare that the behavior
is reflected in messages: they use an optimized wire format
(MIME Multipart/Related serialization). Note that in order for
- an optional behaviors to be engaged, the wire message that
+ an optional behavior to be engaged, the wire message that
would utilize the specific assertion must be self
describing. For example, an inbound message to a web service
that asserts MTOM, must evaluate, the protocol format of the
@@ -961,12 +966,12 @@
when optional behaviors are specified for message
exchanges within a request response for response messages,
using message policy subject. Leaving the semantics
- undescribed may result in providers making assumptions
+ not specified or incompletely specified may result in providers making assumptions
(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 to describe 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
@@ -1005,7 +1010,7 @@
if an assertion is specific to a policy attachment
mechanism. An example could be identifying whether the
assertion expressed is associated with behaviors
- (endpoints) or artifacts ( messages) and then constraining
+ (endpoints) or artifacts (messages) and then constraining
the use of an assertion to one of these subjects.
</p>
<p>Thus our example encryption assertion would have a
@@ -1020,7 +1025,7 @@
<p>Best Practice- To avoid confusion, assertion definitions should be
precise about their semantics and include information that
restricts their set of permissible policy subjects
- appropriately and indicates which Qnames are associated with
+ appropriately and indicates which QNames are associated with
which subjects.</p>
<olist>
<item>
@@ -1081,10 +1086,11 @@
the domain 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 the senders
- choose to engage RM semantics (although not specified via
- attachment in WSDL at incoming messages), the providers will
- honor the engagement of RM. This is illustrative of how the
+ assertion semantics also indicates that the if
+ a sender chose to engage RM
+ semantics (although not specified via attachment in WSDL at incoming
+ messages), the providers will honor the engagement of RM.
+ This is illustrative of how the
assertion author can specify additional constraints and
assumptions for attachment and engagement of behavior.
</p>
@@ -1219,7 +1225,7 @@
<p>ADD THE EXAMPLE HERE </p>
</example>
<p>Best practice: use independent assertions for modeling multiple equivalent behaviors. </p>
- <!-- EDS TO DO REconcile from Primer. GET THE REST FROM DAVE and Umit -->
+ <!-- EDS TO DO reconcile from Primer. GET THE REST FROM DAVE and Umit -->
</div2>
</div1>
@@ -1231,8 +1237,8 @@
modeling protocol assertions may appear to be an independent behavior,
protocol assertions and security assertions affect transport
bindings and their interactions must be considered. For
- example, utilization of WS-Security Policy with other
- protocols affect transport binding and would result in nested
+ 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
be aware of the compositional semantics with other related
@@ -1279,17 +1285,17 @@
mechanisms should make it possible to clearly identify the
source of a poly assertion both for debugging and for
verification. This could take several forms: it could be
- assumed ( in WSDL, the source of the assertion is the same
- as the WSDL provider) or it could be proven ( using
+ assumed (in WSDL, the source of the assertion is the same
+ as the WSDL provider) or it could be proven (using
<bibref ref="WS-Trust"/>). </p>
</div2>
</div1>
- <div1 id="scenerio">
+ <div1 id="scenario">
<head>Scenario and a worked example</head>
<p>To illustrate the topics explored in this document, we
include an example of a web service and how a fictitious company
might utilize the WS-Policy Framework to enable Web Service
- interoperability. CompanyA has determined to utilize WS-Security,
+ interoperability. Company A has determined to utilize WS-Security,
WS-Addressing and WS-Reliable Messaging in all its new web
service offerings and has instructed its developers to use the
policy assertions defined by the following documents: </p>
@@ -1304,11 +1310,11 @@
<p>Web Services Addressing WSDL Binding</p>
</item>
</ulist>
- <p>The application developers at CompanyA are instructed to
- review the current web services at CompanyA and propose a plan
+ <p>The application developers at Company A are instructed to
+ review the current web services at Company A and propose a plan
for adding policy assertions. </p>
<p>The application developers collect information about web
- services within CompanyA and determine that all of the web
+ services within Company A and determine that all of the web
services already have a WSDL 1.1 description. The developers
have determined that Company A's web services fall into two
types of web services. There are those that fall into the
@@ -1322,7 +1328,7 @@
or message exchange. </p>
<p>Service A is a WSDL 1.1 conformant web service and requires
the use of transport-level security for protecting messages as
- well as including addressing headers. Employees of CompanyA have
+ well as including addressing headers. Employees of Company A have
already incorporated <code>wss:Security</code> headers into their
messages. </p>
<example>
@@ -1343,7 +1349,7 @@
</example>
<p>The SOAP message in the example above includes security
timestamps that express creation and expiration times of this
- message. CompanyA requires the use of these security timestamps
+ message. Company A requires the use of these security timestamps
and transport-level security, such as HTTPS for protecting
messages. </p>
<p>The example below illustrates a policy expression that
@@ -1361,7 +1367,7 @@
<p>The <code>sp:TransportBinding</code> element is a policy assertion. The
assertion identifies the use of transport-level-security - such
as HTTPS for protecting messages at the transport
- level. CompanyA's policy aware clients can now recognize this
+ level. Company A's policy aware clients can now recognize this
policy assertion and if they support it, engage in transport
level security for protecting messages and providing security
timestamps in SOAP envelopes for any WSDL with this policy
@@ -1374,26 +1380,26 @@
alternatives rather than forcing a single client
configuration. </p>
<p>The developers read the WS-Policy specification and noted that
- there were 3 ways to express combinations of behaviors. The three
- policy operators, ( Policy, All and ExactlyOne) were considered
+ there were three ways to express combinations of behaviors. The three
+ policy operators, (Policy, All and ExactlyOne) were considered
and the result was the creation of two policy elements. </p>
<p>The first policy is shown in Figure
<emph>CompanyA-ProfileA</emph> and it is the policy that is used
- by many web services at Company A that rely on https to provide
+ by many web services at Company A that rely on HTTPS to provide
transport level protection of messages. </p>
<p>The second policy is shown in Figure
<emph>CompanyA-ProfileB</emph> and it offers requestors of a
service the ability to provide additional integrity protection by
including WS-Security Headers to protect the message content
after it is processed by the transport. The additional security
- processing is not required by all CompanyA web services. </p>
- <example> <head>CompanyA-ProfileB ( not expanded)</head> <eg
+ processing is not required by all Company A web services. </p>
+ <example> <head>CompanyA-ProfileB (not expanded)</head> <eg
xml:space="preserve"> <Policy wsu:Id="CompanyA-ProfileB">
<wsa:UsingAddressing /> <ExactlyOne>
<sp:TransportBinding></sp:TransportBinding>
<sp:AsymmetricBinding></sp:AssymetricBinding>
</ExactlyOne> </Policy> </eg> </example>
- <p>We have shown above that CompanyA offered a
+ <p>We have shown above that Company A offered a
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>
@@ -1406,7 +1412,7 @@
an <code>sp:TransportBinding</code> assertion, just indicating the use of
transport-level security for protecting messages is not
sufficient. For a consumer of a web service provided by a company,
- like CompanyA, to successfully interact, the consumer must also
+ like Company A, to successfully interact, the consumer must also
know what transport token, what algorithm suite, etc. is
required. The <code>sp:TransportBinding</code> assertion, can (and has)
represent (ed) these dependent behaviors as "nested" policy
@@ -1447,24 +1453,24 @@
indicates the use of a specific type of token, in this case an
HttpsToken. </p>
<p>It should be noted that each policy has an Identifier. In the
- case of the default policy expression, CompanyA has decided that
+ case of the default policy expression, Company A has decided that
this policy expression should be broadly available via a URI.
There are advantages and disadvantages to using each type of
identifier. For URI's there is the issue of maintaining the
- policy expression when it may no longer be used ( CompanyA gets
- bought by CompanyB and starts using the policies of Company B,
+ policy expression when it may no longer be used (Company A gets
+ bought by Company B and starts using the policies of Company B,
but some "old" consumers may still try to reference the
URI). </p>
<p> For the second type of web services, which may be used only
- by certain of CompanyA's business partners, the id is an XML ID.
+ by certain of Company A's business partners, the id is an XML ID.
The relative URI for referencing this within the same WSDL
document is #CompanyA-ProfileB. This can be useful for company's
when the policy expressions are agreed to between partners but
may be changed as the business agreements change. But the
disadvantage is that the policy expression must be included in
each WSDL document. </p>
- <p>Since CompanyA has decided to use well known policy
- expressions that are themselves part of a specification, they
+ <p>Since Company A has decided to use well known policy
+ expressions that are part of a specification, they
adhere to the guidance given in the WS-SecurityPolicy
specification and attach the policies to the web service endpoint
policy subject as recommended by the WS-SecurityPolicy
@@ -1480,7 +1486,7 @@
</wsdl:binding> </eg>
</example>
<p>The partner specified policy is included in the beginning of
- the wsdl 1.1document and referenced by the binding for the service
+ the WSDL 1.1 document and referenced by the binding for the service
as in the example below.</p>
<example>
<head/>
@@ -1828,7 +1834,13 @@
<td>MH</td>
<td>Replaced section in Lifecycle with pointer to the text in the primer: related to action 77
</td>
- </tr>
+ </tr>
+ <tr>
+ <td>20061129</td>
+ <td>FH</td>
+ <td>Editorial revision (editorial actions 84 and for action 90)
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Thursday, 30 November 2006 04:04:27 UTC