- From: Felix Sasaki via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 24 May 2007 14:29:11 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv6679/policy
Modified Files:
guidelines-bestpractices.xml ws-policy-guidelines.html
xmlspec-policy.xsl
Log Message:
"ACTION-287 - Update the stylesheets to say Best Practice instead of Good Practice " done.
Index: xmlspec-policy.xsl
===================================================================
RCS file: /sources/public/2006/ws/policy/xmlspec-policy.xsl,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- xmlspec-policy.xsl 2 May 2007 17:07:39 -0000 1.8
+++ xmlspec-policy.xsl 24 May 2007 14:29:09 -0000 1.9
@@ -225,7 +225,7 @@
<p>
<a name="{@id}" id="{@id}"/>
<span class="practicelab">
- <xsl:text>Good
+ <xsl:text>Best
practice </xsl:text>
<xsl:value-of select="$practicenumber"/>
<xsl:text>: </xsl:text>
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -d -r1.61 -r1.62
--- ws-policy-guidelines.html 20 May 2007 17:58:14 -0000 1.61
+++ ws-policy-guidelines.html 24 May 2007 14:29:09 -0000 1.62
@@ -390,7 +390,7 @@
For example, if an assertion applies to the SOAP protocol, it would be necessary
to consider how its presence must interact with other policy assertions that
are defined for security.
- </p><div class="boxedtext"><p><a name="bp-assertion-specification-parts" id="bp-assertion-specification-parts"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-assertion-specification-parts" id="bp-assertion-specification-parts"></a><span class="practicelab">Best
practice 1: Parts of an Assertion Specification</span></p><p class="practice">
Assertion Authors should include the following items in an
assertion specification: </p></div><p>
@@ -415,7 +415,7 @@
attachment mechanism. Independence from a specific attachment mechanism
allows policy tools to choose the most appropriate mechanism to attach a
policy without having to analyze the contents of the policy.
- </p><div class="boxedtext"><p><a name="bp-assertion-semantics" id="bp-assertion-semantics"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-assertion-semantics" id="bp-assertion-semantics"></a><span class="practicelab">Best
practice 2: Semantics Independent of
Attachment Mechanisms</span></p><p class="practice">
The semantics of a policy assertion should not depend on the
@@ -447,7 +447,7 @@
policy expression would be when it is processed. As a result, the
description for a policy assertion should not depend on the style used
to author a policy expression that contains the assertion.
- </p><div class="boxedtext"><p><a name="bp-semantics-and-form" id="bp-semantics-and-form"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-semantics-and-form" id="bp-semantics-and-form"></a><span class="practicelab">Best
practice 3: Semantics Independent of the Form</span></p><p class="practice">The semantics of an assertion should be independent of
the form (compact or normal form) of policy expressions that contain the
assertion.</p></div><p>
@@ -544,7 +544,7 @@
a simple working assertion that allows extensibility. As the design
work progresses, one may add more parameters or nested policy assertions
to meet one's interoperability needs.
- </p><div class="boxedtext"><p><a name="bp-assertion-start" id="bp-assertion-start"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-assertion-start" id="bp-assertion-start"></a><span class="practicelab">Best
practice 4: Start with Simple Assertion</span></p><p class="practice">An assertion author should start with a simple working assertion
that allows assertion parameter extensibility. </p></div><p>New Assertion Authors are encouraged to look at <cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite> to see an example of a
relatively simple domain that has defined three assertions. Assertion Authors are encouraged to look at <cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite> to see an example of a complex domain that has been decomposed into a set of policy expressions.
@@ -556,7 +556,7 @@
represent an assertion parameter as a child element (by leveraging natural XML nesting)
or an attribute of an assertion. The general guidelines on when to use XML elements
versus attributes apply is. Use a unique QName to identify a distinct behavior and provide
- an XML outline (plus an XML schema document) to specify the syntax of an assertion. </p><div class="boxedtext"><p><a name="bp-unique-qnames" id="bp-unique-qnames"></a><span class="practicelab">Good
+ an XML outline (plus an XML schema document) to specify the syntax of an assertion. </p><div class="boxedtext"><p><a name="bp-unique-qnames" id="bp-unique-qnames"></a><span class="practicelab">Best
practice 5: Use Unique QNames</span></p><p class="practice">An assertion author should use a unique QName to identify a distinct behavior.</p></div><p>The syntax of an assertion can be represented using an XML outline (plus an XML schema
document). If the assertion has a nested policy expression then the assertion XML
outline can enumerate the nested assertions that are allowed. An example is the following:
@@ -575,10 +575,10 @@
...
</sp:IssuedToken>
- </pre></div></div><div class="boxedtext"><p><a name="AssertionDefinitions" id="AssertionDefinitions"></a><span class="practicelab">Good
+ </pre></div></div><div class="boxedtext"><p><a name="AssertionDefinitions" id="AssertionDefinitions"></a><span class="practicelab">Best
practice 6: Specify Semantics Clearly</span></p><p class="practice"> An assertion description must clearly and completely specify the semantics of a policy
assertion.
- </p></div><div class="boxedtext"><p><a name="XMLOutline" id="XMLOutline"></a><span class="practicelab">Good
+ </p></div><div class="boxedtext"><p><a name="XMLOutline" id="XMLOutline"></a><span class="practicelab">Best
practice 7: Provide an XML Outline</span></p><p class="practice"> An assertion description should provide an XML outline plus an XML schema to specify the
syntax of the assertion.
</p></div><div class="exampleOuter"><div class="exampleInner"><pre>
@@ -615,7 +615,7 @@
consider how to make messages self describing when utilizing
their assertions by specifying additional properties, headers,
etc. that must be present in a message as part of their assertion design.
- </p><div class="boxedtext"><p><a name="bp-not-necessary-to-understand-a-message" id="bp-not-necessary-to-understand-a-message"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-not-necessary-to-understand-a-message" id="bp-not-necessary-to-understand-a-message"></a><span class="practicelab">Best
practice 8: Not Necessary to Understand a Message</span></p><p class="practice">An assertion author should not define policy assertions to represent information that is necessary to understand a message.</p></div><p>For example, if the details of a message's encryption ( e.g., the cipher used, etc) are expressed
in policy that isn't attached to the message, it isn't possible
to later decipher it. This is very different from expressing, in
@@ -645,7 +645,7 @@
their service descriptions.
</p><p>It is the responsibility of the assertion authors to avoid duplication of assertions.
A review by a broad community is the best way to ensure that the granularity of a set
- of domain assertions is appropriate.</p><div class="boxedtext"><p><a name="bp-assertion-duplication" id="bp-assertion-duplication"></a><span class="practicelab">Good
+ of domain assertions is appropriate.</p><div class="boxedtext"><p><a name="bp-assertion-duplication" id="bp-assertion-duplication"></a><span class="practicelab">Best
practice 9: Avoid Duplication of Assertions</span></p><p class="practice">An assertion author should reuse an existing assertion (rather than create a new one) whenever possible.</p></div></div></div><div class="div2">
<h3><a name="comparison" id="comparison"></a>5.4 Comparison of Nested and Parameterized Assertions</h3><p>There are two different ways to provide additional information in an
assertion beyond its type. We cover these two cases below followed by a
@@ -660,7 +660,7 @@
affect the outcome of policy intersection unless the assertion specifies
domain specific processing for policy intersection.</p><p>In the XML representation of a policy assertion, the child elements
and attributes of the assertion excluding child elements and attributes
- from the policy language namespace name are the assertion parameters.</p><div class="boxedtext"><p><a name="bp-assertion-parameters" id="bp-assertion-parameters"></a><span class="practicelab">Good
+ from the policy language namespace name are the assertion parameters.</p><div class="boxedtext"><p><a name="bp-assertion-parameters" id="bp-assertion-parameters"></a><span class="practicelab">Best
practice 10: Use Parameters for Useful
Information</span></p><p class="practice">An assertion author should represent useful (or additional)
information necessary for engaging the behavior represented by a policy
@@ -694,10 +694,10 @@
description should declare it and enumerate the nested policy assertions
that are allowed. There is one caveat to watch out for: policy assertions
with deeply nested policy can greatly increase the complexity of a policy and should be
- avoided when they are not needed.</p><div class="boxedtext"><p><a name="bp-dependent-behaviors" id="bp-dependent-behaviors"></a><span class="practicelab">Good
+ avoided when they are not needed.</p><div class="boxedtext"><p><a name="bp-dependent-behaviors" id="bp-dependent-behaviors"></a><span class="practicelab">Best
practice 11: Use Nested Assertions for Dependent Behaviors</span></p><p class="practice">An assertion author should represent dependent behaviors that are relevant
to a compatibility test and apply to the same policy subject using
- nested policy assertions.</p></div><div class="boxedtext"><p><a name="bp-declare-nested-assertions" id="bp-declare-nested-assertions"></a><span class="practicelab">Good
+ nested policy assertions.</p></div><div class="boxedtext"><p><a name="bp-declare-nested-assertions" id="bp-declare-nested-assertions"></a><span class="practicelab">Best
practice 12: Declare Nested Assertions</span></p><p class="practice">If there is a nested policy expression, an assertion description should declare it
and enumerate the nested policy assertions that are allowed.</p></div><p>The main consideration for selecting parameters or nesting
of assertions is that <em>the framework intersection
@@ -719,7 +719,7 @@
specific comparison algorithms may need to be devised and be
delegated to the specific domain handlers that are not visible
to the WS-Policy framework. However, domain specific intersection processing reduces
- interop and increases the burden to implement an assertion.</p><div class="boxedtext"><p><a name="bp-discourage-domain-specific-intersection" id="bp-discourage-domain-specific-intersection"></a><span class="practicelab">Good
+ interop and increases the burden to implement an assertion.</p><div class="boxedtext"><p><a name="bp-discourage-domain-specific-intersection" id="bp-discourage-domain-specific-intersection"></a><span class="practicelab">Best
practice 13: Discourage Domain Specific Intersection</span></p><p class="practice">An
assertion description should only specify domain specific intersection
semantics when policy intersection is insufficient.</p></div><p>We will use the WS-SecurityPolicy to illustrate the use of nested assertions.
@@ -815,11 +815,11 @@
compatability assessment between two alternatives. See [tbd] for details on the use
of the ignorable attribute.
</p><div class="div3">
-<h4><a name="doc-ignorable-assertions" id="doc-ignorable-assertions"></a>5.5.1 Assertions and Ignorable Behavior</h4><div class="boxedtext"><p><a name="DefineIgnorable" id="DefineIgnorable"></a><span class="practicelab">Good
+<h4><a name="doc-ignorable-assertions" id="doc-ignorable-assertions"></a>5.5.1 Assertions and Ignorable Behavior</h4><div class="boxedtext"><p><a name="DefineIgnorable" id="DefineIgnorable"></a><span class="practicelab">Best
practice 14: Assertions Document Ignorable Behavior</span></p><p class="practice"> An assertion description should use the wsp:Ignorable attribute
to indicate that the behavior indicated by the QName may be ignored by policy intersection.
</p></div></div><div class="div3">
-<h4><a name="XML-ignorable-assertions" id="XML-ignorable-assertions"></a>5.5.2 XML Outline for Ignorable </h4><div class="boxedtext"><p><a name="ignorableAssertions" id="ignorableAssertions"></a><span class="practicelab">Good
+<h4><a name="XML-ignorable-assertions" id="XML-ignorable-assertions"></a>5.5.2 XML Outline for Ignorable </h4><div class="boxedtext"><p><a name="ignorableAssertions" id="ignorableAssertions"></a><span class="practicelab">Best
practice 15: Ignorable Attribute in XML</span></p><p class="practice"> An assertion XML outline should allow for the use of the wsp:Ignorable attribute
to indicate ignorable behavior.
</p></div></div></div><div class="div2">
@@ -838,7 +838,7 @@
include policy alternatives in a policy expression, by using
the wsp:Optional attribute. An assertion author should clearly indicate in the assertion
definition that it is possible to be optional
- and to allow the use of the wsp:Optional attribute in the XML definition. </p><div class="boxedtext"><p><a name="bp-assertion-xml-allow-optional" id="bp-assertion-xml-allow-optional"></a><span class="practicelab">Good
+ and to allow the use of the wsp:Optional attribute in the XML definition. </p><div class="boxedtext"><p><a name="bp-assertion-xml-allow-optional" id="bp-assertion-xml-allow-optional"></a><span class="practicelab">Best
practice 16: Assertion XML should allow use of wsp:Optional attribute</span></p><p class="practice">An assertion XML outline should allow the use of the wsp:Optional attribute to
indicate optional behaviors.</p></div><p>To give a general example, the definition of assertion syntax for a hypothetical assertion such as SampleAssertion,
should allow attribute extensibility as part of the XML definition, allowing the wsp:Optional attribute to be used:
@@ -846,7 +846,7 @@
<p style="text-align: left" class="exampleHead"><i><span>Example 5-8. </span>Use of @any for attribute extensibility</i></p><div class="exampleInner"><pre>/samplePrefix:SampleAssertion/@any
This is an extensibility mechanism to allow additional attributes to be added to the element, including wsp:Optional.
</pre></div></div><p>The portion of the assertion definition that describes policy subjects and assertion attachment should indicate
- that wsp:Optional can be used to indicate that the behavior is optional for the policy subject.</p><div class="boxedtext"><p><a name="bp-assertion-description-explicitly-allow-optional" id="bp-assertion-description-explicitly-allow-optional"></a><span class="practicelab">Good
+ that wsp:Optional can be used to indicate that the behavior is optional for the policy subject.</p><div class="boxedtext"><p><a name="bp-assertion-description-explicitly-allow-optional" id="bp-assertion-description-explicitly-allow-optional"></a><span class="practicelab">Best
practice 17: Assertion description should explicitly indicate that wsp:Optional is allowed.</span></p><p class="practice">An assertion description should use the wsp:Optional attribute to indicate that the
behavior indicated by the QName is optional for the associated policy subject.</p></div><p>Continuing the example with the hypothetical SampleAssertion, the section on Assertion Attachment should
include discussion of optionality.
@@ -861,7 +861,7 @@
"optional" with a value "true" since this would allow the
consumer to select the policy alternative that does not contain the assertion,
and thus not engaging the behavior.
- </p><div class="boxedtext"><p><a name="bp-limit-optional-assertions" id="bp-limit-optional-assertions"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-limit-optional-assertions" id="bp-limit-optional-assertions"></a><span class="practicelab">Best
practice 18: Limit use of Optional Assertions</span></p><p class="practice">Assertion Authors should not use optional assertions for behaviors that must be present
in compatible policy expressions.</p></div><p> The target scope of an optional assertion is an important factor for
Assertion Authors to consider as it determines the
@@ -893,7 +893,7 @@
introduce both message and endpoint policy subjects for one of its
assertions and require the use of endpoint policy subject
when message policy subject is used via attachment.
- </p><div class="boxedtext"><p><a name="bp-entire-mep-for-optional" id="bp-entire-mep-for-optional"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-entire-mep-for-optional" id="bp-entire-mep-for-optional"></a><span class="practicelab">Best
practice 19: Consider entire message exchange pattern when specifying Assertions that may be optional</span></p><p class="practice">Assertion Authors should associate optional assertions with the appropriate endpoint and use the smallest
possible granularity to limit the degree to which optionality applies.</p></div><p>
Behaviors must be engaged
@@ -907,7 +907,7 @@
the optional behavior is engaged.
(Such an out of band mechanism is outside the scope of WS-Policy
Framework).
- </p><div class="boxedtext"><p><a name="bp-indicate-optional-assertion-use" id="bp-indicate-optional-assertion-use"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-indicate-optional-assertion-use" id="bp-indicate-optional-assertion-use"></a><span class="practicelab">Best
practice 20: Indicate use of an Optional Assertion</span></p><p class="practice">When a given behavior may be optional, it must be possible for both message participants to determine that the assertion is selected by both parties,
either out of band or as reflected by the message content.</p></div><div class="div4">
<h5><a name="d3e851" id="d3e851"></a>5.6.2.1 Example</h5><p>
@@ -946,7 +946,7 @@
subject is the service policy subject. </p></li><li><p>If the behavior applies to any message exchange
made using an endpoint then the subject is the endpoint policy subject. </p></li><li><p>If the behavior applies to any message exchange
defined by an operation then the subject is the operation policy subject. </p></li><li><p>If the behavior applies to an input message then
- the subject is the message policy subject - similarly for output and fault message policy subjects.</p></li></ul><div class="boxedtext"><p><a name="bp-WSDL-policy-subject" id="bp-WSDL-policy-subject"></a><span class="practicelab">Good
+ the subject is the message policy subject - similarly for output and fault message policy subjects.</p></li></ul><div class="boxedtext"><p><a name="bp-WSDL-policy-subject" id="bp-WSDL-policy-subject"></a><span class="practicelab">Best
practice 21: Assertion Description Should Specify a Policy Subject</span></p><p class="practice">Assertion authors should associate assertions with the appropriate policy subject.
For instance, if a policy assertion is to be used with WSDL, the assertion description
should specify a WSDL policy subject – such as service, endpoint, operation and message.
@@ -978,7 +978,7 @@
policy subject instead of a message policy subject. However such
policy attachments to policy subjects of broader scope and granularity
should be done only after careful evaluation.
- </p><div class="boxedtext"><p><a name="bp-WSDL-policy-subject-Granularity" id="bp-WSDL-policy-subject-Granularity"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-WSDL-policy-subject-Granularity" id="bp-WSDL-policy-subject-Granularity"></a><span class="practicelab">Best
practice 22: Choose a Granular Policy Subject</span></p><p class="practice">Assertion authors should choose the most granular policy subject
that the behavior represented by a policy assertion applies to.
</p></div><p>
@@ -989,7 +989,7 @@
the burden to describe the semantics of multiple instances of the
same assertion attached to different policy subjects at the same
time in order to avoid conflicting behavior.
- </p><div class="boxedtext"><p><a name="bp-WSDL-multiple-policy-subjects" id="bp-WSDL-multiple-policy-subjects"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-WSDL-multiple-policy-subjects" id="bp-WSDL-multiple-policy-subjects"></a><span class="practicelab">Best
practice 23: Define Semantics of Attachment to Multiple Policy Subjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple policy
subjects, the assertion description should describe the semantics of multiple
instances of the same assertion attached to multiple policy subjects
@@ -1030,7 +1030,7 @@
also considers the case when sequences are present. In addition,
when the policy assertions do not target wire-level behaviors but
rather abstract requirements, this technique does not apply.
- </p><div class="boxedtext"><p><a name="bp-WSDL-preferred-attachment-point" id="bp-WSDL-preferred-attachment-point"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-WSDL-preferred-attachment-point" id="bp-WSDL-preferred-attachment-point"></a><span class="practicelab">Best
practice 24: Specify Preferred Attachment Point for an Assertion</span></p><p class="practice">If an assertion can be attached at multiple points within a policy
subject, an assertion author should specify a preferred attachment
point for the chosen policy subject.
@@ -1049,7 +1049,7 @@
at the endpoint could have more than one SignedParts assertion in the
same alternative. However, the clear semantics defined by the SignedParts
assertion enable processing of the multiple occurrences properly.
- </p><div class="boxedtext"><p><a name="bp-WSDL-policy-multiple-instance-semantics" id="bp-WSDL-policy-multiple-instance-semantics"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-WSDL-policy-multiple-instance-semantics" id="bp-WSDL-policy-multiple-instance-semantics"></a><span class="practicelab">Best
practice 25: Describe Semantics of Multiple Assertions of Same Kind</span></p><p class="practice">A policy alternative can contain multiple instances of the
same policy assertion. An assertion description should specify the
semantics of multiple instances of a policy assertion in the same
@@ -1068,7 +1068,7 @@
Assertions [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>]. </p><p>Assertion authors should not duplicate existing
assertions and should also make sure that when adding assertions those new assertions are consistent
with pre-existing assertions of any
- interrelated domain. </p><div class="boxedtext"><p><a name="bp-specify-composition" id="bp-specify-composition"></a><span class="practicelab">Good
+ interrelated domain. </p><div class="boxedtext"><p><a name="bp-specify-composition" id="bp-specify-composition"></a><span class="practicelab">Best
practice 26: Specify Composition with Related Assertions</span></p><p class="practice">An assertion description should clearly specify how the assertion may compose
with other related assertions, if any.</p></div></div></div><div class="div1">
<h2><a name="versioning-policy-assertions" id="versioning-policy-assertions"></a>6. Versioning Policy Assertions</h2><p>Assertion Authors need to consider not just the expression of the current set of requirements but
@@ -1098,7 +1098,7 @@
vs. 1.1 and WS-Addressing August 2004 version vs. WS-Addressing W3C Recommendation
[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]. These equivalent behaviors
are mutually exclusive for an interaction. Such equivalent
- behaviors can be modeled as independent assertions. </p><div class="boxedtext"><p><a name="bp-independent-assertions" id="bp-independent-assertions"></a><span class="practicelab">Good
+ behaviors can be modeled as independent assertions. </p><div class="boxedtext"><p><a name="bp-independent-assertions" id="bp-independent-assertions"></a><span class="practicelab">Best
practice 27: Use Independent Assertions for Multiple Versions of a Behavior</span></p><p class="practice">An assertion author should use independent assertions for modeling multiple
versions of a behavior.</p></div><p>The
policy expression in the example below requires the use of
@@ -1127,7 +1127,7 @@
provided that endpoint policy subject is also retained in its design. When
new policy subjects are added it is incumbent on the authors to retain the
semantic of the policy assertion.
- </p><div class="boxedtext"><p><a name="bp-policy-subject-change" id="bp-policy-subject-change"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-policy-subject-change" id="bp-policy-subject-change"></a><span class="practicelab">Best
practice 28: Change of the Policy Subject Over Time</span></p><p class="practice">If the policy subjects change over time,
the assertion description should also be versioned to reflect this
change.</p></div></div></div><div class="div1">
Index: guidelines-bestpractices.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/guidelines-bestpractices.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- guidelines-bestpractices.xml 2 May 2007 17:07:39 -0000 1.2
+++ guidelines-bestpractices.xml 24 May 2007 14:29:09 -0000 1.3
@@ -1 +1 @@
-<?xml version="1.0" encoding="UTF-8"?><ulist><item><p><specref ref="bp-assertion-specification-parts"/></p></item><item><p><specref ref="bp-assertion-semantics"/></p></item><item><p><specref ref="bp-semantics-and-form"/></p></item><item><p><specref ref="bp-assertion-start"/></p></item><item><p><specref ref="bp-unique-qnames"/></p></item><item><p><specref ref="bp-assertions-and-message-semantics"/></p></item><item><p><specref ref="bp-assertion-duplication"/></p></item><item><p><specref ref="bp-assertion-definition"/></p></item><item><p><specref ref="bp-nesting"/></p></item><item><p><specref ref="bp-assertion-xml-allow-optional"/></p></item><item><p><specref ref="bp-assertion-description-explicitly-allow-optional"/></p></item><item><p><specref ref="bp-limit-optional-assertions"/></p></item><item><p><specref ref="bp-entire-mep-for-optional"/></p></item><item><p><specref ref="bp-indicate-optional-assertion-use"/></p></item><item><p><specref ref="bp-independent-assertions"/></p></item><item><p><specref ref="bp-olicy-subject-change"/></p></item></ulist>
\ No newline at end of file
+<?xml version="1.0" encoding="UTF-8"?><ulist><item><p><specref ref="bp-assertion-specification-parts"/></p></item><item><p><specref ref="bp-assertion-semantics"/></p></item><item><p><specref ref="bp-semantics-and-form"/></p></item><item><p><specref ref="bp-assertion-start"/></p></item><item><p><specref ref="bp-unique-qnames"/></p></item><item><p><specref ref="AssertionDefinitions"/></p></item><item><p><specref ref="XMLOutline"/></p></item><item><p><specref ref="bp-not-necessary-to-understand-a-message"/></p></item><item><p><specref ref="bp-assertion-duplication"/></p></item><item><p><specref ref="bp-assertion-parameters"/></p></item><item><p><specref ref="bp-dependent-behaviors"/></p></item><item><p><specref ref="bp-declare-nested-assertions"/></p></item><item><p><specref ref="bp-discourage-domain-specific-intersection"/></p></item><item><p><specref ref="DefineIgnorable"/></p></item><item><p><specref ref="ignorableAssertions"/></p></item><item><p><specref ref="bp-assertion-xml-allow-optional"/></p></item><tem><p><specref ref="bp-assertion-description-explicitly-allow-optional"/></p></item><item><p><specref ref="bp-limit-optional-assertions"/></p></item><item><p><specref ref="bp-entire-mep-for-optional"/></p></item><item><p><specref ref="bp-indicate-optional-assertion-use"/></p></item><item><p><specref ref="bp-WSDL-policy-subject"/></p></item><item><p><specref ref="bp-WSDL-policy-subject-Granularity"/></p></item><item><p><specref ref="bp-WSDL-multiple-policy-subjects"/></p></item><item><p><specref ref="bp-WSDL-preferred-attachment-point"/></p></item><item><p><specref ref="bp-WSDL-policy-multiple-instance-semantics"/></p></item><item><p><specref ref="bp-specify-composition"/></p></item><item><p><specref ref="bp-independent-assertions"/></p></item><item><p><specref ref="bp-policy-subject-change"/></p></item></ulist>
\ No newline at end of file
Received on Thursday, 24 May 2007 14:29:19 UTC