alternate proposal for 4072

This relates to bug 
4072-----http://www.w3.org/Bugs/Public/show_bug.cgi?id=4072 

Description:

The bug 4072, proposes removing section 4.1. 
This proposal addresses a revision of the section (4.1) rather than 
removing it.


Target: Guidelines 
Replace section 4.1 with the following: 
Assertion Authors need to have a specific goal in mind for the assertions 
that they author. Assertion Authors should also understand the 
functionality that the WS-Policy framework provides and apply the 
knowledge of the policy framework processing when defining the set of 
assertions. 
 
Assertions can be simple or they can be complex. Assertion Authors may 
choose to specify multiple peer assertions, each carrying the semantic of 
a particular behavior, or they may choose to specify assertions that 
contains assertion parameters and/or nested policy expression (nested 
assertions), each of which relate to an aspect of the behavior, yet 
encapsulated within a single assertion. There are advantages to 
simplifying the set of assertions. The ultimate goal of policy is to 
enable interoperability. By keeping assertion design as simple as 
possible, Assertion Authors will more likely be able to meet that 
objective. 
 
If a set of assertions describes a wide range of behaviors, the ability to 
combine individual assertions may also need to be considered. 
 
The WS-Policy Attachment specification defines a number of different 
policy subjects to which an assertion can be attached. For attaching to 
WSDL subjects see 4.7 Levels of Abstraction in WSDL for more detail. 
Additionally, the framework provides for the means to extend the set of 
policy subjects beyond the set of subjects defined in the WS-Policy 
Attachment specification.
 
The WS-Policy Attachment specification provides various mechanisms to 
attach a policy expression to a policy subject. Although a policy 
assertion may be constrained to a specific set of policy subjects by 
assertion authors, its semantics should not be dependent upon the 
mechanism by which the policy expression is attached to a given policy 
subject. For instance, an assertion "Foo" has the same semantic when 
attached to an operation policy subject regardless of whether it was 
attached using XML element policy attachment or the external URI 
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. 
 
Best practice: Assertion Authors should include the following items in an 
assertion specification: 
 
    * The definition of the assertion's semantic 
 
    * The specification of the set of valid policy subjects to which an 
assertion may be attached. 
 
    * The scope of the assertion in the context of a particular policy 
subject. For example, an assertion with Endpoint Policy Subject can be 
scoped to a given message exchange with that endpoint, or it can be scoped 
to all messages exchanged with that endpoint. The former case permits a 
client to select a different alternative with each successive message 
exchange. 
 
    * Composition. If the assertion is used with other assertions in a 
context, it is necessary to consider how the assertion may, or may not, 
affect the composition. 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.
 
Best practice: The semantics a policy assertion should not depend on the 
attachment mechanism used.