- From: Umit Yalsinap via cvs-syncmail <cvsmail@w3.org>
- Date: Sat, 14 Oct 2006 03:06:39 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv32377
Modified Files:
ws-policy-guidelines.xml
Log Message:
corrected syntax problems
Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- ws-policy-guidelines.xml 14 Oct 2006 02:54:35 -0000 1.3
+++ ws-policy-guidelines.xml 14 Oct 2006 03:06:37 -0000 1.4
@@ -687,20 +687,20 @@
</div2>
<div2 id="optional-policy-assertion">
<head>Optional Policy Assertion</head>
- <p>Optional assertions represent behaviours which may be
+ <p>Optional assertions represent behaviors which may be
engaged by a consumer. When using the compact authoring form
- for assertions, behaviours are marked by using
+ for assertions, behaviors are marked by using
<code>wsp:optional</code> attribute that has a value,
"true". During the process of normalization, the runtime
- behaviour is indicated by two policy alternatives, one with
+ behavior is indicated by two policy alternatives, one with
and one without containing the assertion. In a
consumer/provider scenario, the choice of engaging the runtime
- behaviour is upon the consumer although the provider is
- capable of engaging the runtime behaviour.
+ behavior is upon the consumer although the provider is
+ capable of engaging the runtime behavior.
</p>
<p>The <bibref ref="WS-Policy-Primer"/> document contains an
example that proposes the use of <bibref ref="MTOM"/> as an
- optional behaviour that can be engaged by a consumer. The
+ optional behavior that can be engaged by a consumer. The
primer proposes that an assertion that identifies the use of
MIME Multipart/Related serialization (see <bibref ref="MTOM"/>,
<bibref ref="XOP"/> for messages to enable a Policy-aware
@@ -710,7 +710,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 behaviours to be engaged, the wire message that
+ an optional behaviors 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
@@ -718,28 +718,28 @@
the Optimized MIME Serialization. By examining the message,
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 behaviours,
+ <p>Assertion authors should be aware that optional behaviors,
like utilizing optional support for Optimized MIME
Serialization require some care. </p>
<ulist>
<item>
- <p>Since optional behaviours indicate optionality for
- both the provider and the consumer, behaviours that must
+ <p>Since optional behaviors indicate optionality for
+ both the provider and the consumer, behaviors that must
always be engaged by a consumer must not be marked as
"optional" with a value "true" since presence of two
alternatives due to normalization enables a consumer to
choose the alternative that does not contain the assertion,
- and thus making the behaviour not being engaged in an
+ and thus making the behavior not being engaged in an
interaction.
</p>
</item>
<item>
- <p>As demonstrated in the MIME optimization behaviour,
- behaviours must be engaged with respect to messages that are
+ <p>As demonstrated in the MIME optimization behavior,
+ behaviors must be engaged with respect to messages that are
targeted to the provider so that the provider can determine
- that the optional behaviour is engaged. In other words, the
+ that the optional behavior is engaged. In other words, the
requirement of self describing nature of messages in order
- to engage behaviours must not be forgotton with regard to
+ to engage behaviors must not be forgotton with regard to
the client's ability to detect and select the alternative if
it is to participate in the exchange. It is recommended that
authors not utilize optional assertions for outbound
@@ -749,26 +749,26 @@
the optional capability must be engaged. </p>
</item>
<item>
- <p>When optional behaviours are attached with only
+ <p>When optional behaviors are attached with only
one side of an interaction, such as an inbound message of
a request-response, the engagement of the rest of the
interaction will be undefined. For example, 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 behaviour. Therefore, the assertion authors
+ 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 behaviours are specified for message
+ when optional behaviors are specified for message
exchanges within a request response for response
messages. Leaving the semantics undescribed 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 behaviour is only specified for an
+ engagement of a behavior is only specified for an
outbound message, it may be necessary to describe the
semantics if the incoming messages also utilized the
- behaviour. <bibref ref="WS-RM"/> Policy currently allows
+ behavior. <bibref ref="WS-RM"/> Policy currently allows
the incoming messages to utilize WS-RM protocol (see
<bibref ref="WS-RM"/>) to be engaged although the
assertion may only appear on an outbound message in a
@@ -808,7 +808,7 @@
which subjects. One way to do this is to generally determine
if an assertion is specific to a policy attachment
mechanism. An example could be identifying whether the
- assertion expressed is associated with behaviours
+ assertion expressed is associated with behaviors
(endpoints) or artifacts ( messages) and then constraining
the use of an assertion to one of these subjects.
</p>
@@ -821,7 +821,7 @@
the definition of other domain expressions to be policy
subjects. More of this topic is covered in the <bibref ref="WS-Policy-Primer"/>
</p>
- <p>EXAMPLE</p>
+ <example><p>EXAMPLE</p></example>
</div2>
<div2 id="subject-scoping-considerations">
<head>Subject Scoping Considerations</head>
@@ -837,7 +837,7 @@
associated policy subject. If a policy assertion is to be used
within WSDL, policy assertion authors must specify a WSDL
policy subject. The policy subject is determined with respect
- to a behaviour as follows behavior?
+ to a behavior as follows behavior?
</p>
<ulist>
<item>
@@ -879,7 +879,7 @@
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 behaviour.
+ assumptions for attachment and engagement of behavior.
</p>
<p>If the capability is not really suitable and may imply
different semantics with respect to attachment points, the
@@ -923,7 +923,7 @@
subjects then <emph>the assertion author has the burden to
describe the semantics of multiple instances of the same
assertion attached to multiple policy subjects at the same
- time in order to avoid conflicting behaviour. </emph>
+ time in order to avoid conflicting behavior. </emph>
</p>
<p>One approach is to specify a policy subject, choose the
most granular policy subject that the behavior applies to and
@@ -936,7 +936,7 @@
exchanges. Therefore, its semantics encompasses the cases when
message level policy subjects may be used as attachment but
considers when sequences are present. In addition, when the
- policy assertions do not target wire-level behaviours but
+ policy assertions do not target wire-level behaviors but
rather abstract requirements, this technique does not
apply. </p>
</div2>
@@ -1010,7 +1010,7 @@
<p>Domain authors must be aware of the interactions between
different domains. For example, security assertions interact
with other protocol assertions in a composition. Although
- modeling such assertions may appear independent behaviours,
+ modeling such assertions may appear independent behaviors,
protocol assertions and security assertions affect transport
bindings and their interactions must be considered. For
example, utilization of WS-Security Policy with other
Received on Saturday, 14 October 2006 03:06:42 UTC