New Issue: Update RM and MC policy assertions per Policy 1.5guidelines

[Marc Goodner <mgoodner@microsoft.com>]

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.  

The issues coordinators will notify the list when that has occurred.

Title: Update RM and MC policy assertions per Policy 1.5 guidelines

Protocol:  ws-rmp, ws-mc

Artifact:  spec 

Type: editorial

Description: 

I’ve reviewed the Policy 1.5 guidelines doc and in general didn’t find much, see attached. The one thing we didn’t do was handle in prose what to do for wsp:Ignorable according to guidelines 9 (describe in prose) and 10 (describe in XML). In many instances we’ve handled the XML job by already. The instances where it isn’t handled is where there is attribute extensibility, say for wsp:Optional, which would incorrectly permit the use of wsp:Ignorable. So we can pull the RM and MC assertions into shape from the guidelines perspective by adding prose that it isn’t allowed. For RM that would be a specific statement for the only assertion that allows attribute extensibility, and a similar change for the MC assertion. My suggested text follows.

 

Proposal:

For RM Policy, add the following statement to the end of section 2.2

http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.html#_Toc160540908   

 

The RM policy assertion MUST NOT include the wsp:Ignorable attribute in its attributes with a value of true.

 

For MC, add the following statement to the end of section 3.4

http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-spec-os-01.html#_Toc162743908

 

The MakeConnection policy assertion MUST NOT include the wsp:Ignorable attribute in its attributes with a value of true.

 

 

Title: RM Policy Guidelines analysis

RM Policy Guidelines analysis

Best Practices	Apply to RM?	RM follow practice?	Comments
1. Semantics Independent of Attachment Mechanisms	Y	Y
2. Define assertions relevant to compatibility tests	Y	Y
3. Mark Ignorable Assertions not related to compatibility	N
4. Semantics Independent of the Form	Y	Y	RM cited example
5. Start with a Simple Assertion	Y	Y	RM cited example
6. Use Unique QNames	Y	Y	RM cited example
7. Provide an XML definition	Y	Y	RM cited example
8. Specify Semantics Clearly	Y	Y	RM cited example
9. Document Ignorable Behavior	Y	N	The RM assertion should not permit wsp:Ignorable
10. Document Use of the Ignorable Attribute in XML	Y	N	Needs to be documented in prose where not allowed but schema might permit it via extensibility.
11. Assertion Authors should allow use of wsp:Optional	Y	Y
12. Define message format only	Y	Y
13. Avoid Duplication of Assertions	Y	Y
14. Use Parameters for Useful Information	N
15. Use Nested Assertions for Dependent Behaviors	Y	Y
16. Enumerate Nested Assertions	Y	Y
17. Discourage Domain Specific Intersection	Y	Y
18. Limit use of Optional Assertions	Y	Y	RM cited example
19. Consider entire message exchange pattern when specifying Assertions that may be optional	Y	Y
20. Indicate use of an Optional Assertion	Y	Y
21. Reusable Assertions	Y	Y
22. Describe Semantics of Multiple Assertions of Same Type	Y	Y	Default WS-Policy rules apply
23. Leverage Defined Attachment Mechanisms	Y	Y
24. Use Defined Policy Subjects	Y	Y
25. Identify Policy Subjects	Y	Y
26. Specify WSDL Policy Subject(s)	Y	Y
27. Consider Scope of Attachment Points	Y	Y
28. Choose the Most Granular WSDL Policy Subject	Y	Y
29. Define Rules for Attachment of an Assertion type to Multiple WSDL policy subjects	Y	Y	RM cited example
30. Specify Preferred WSDL Attachment Point	Y	Y
31. Use defined tModels when appropriate	N
32. Specify Composition with Related Assertions	Y	Y	RM cited example
33. Independent Assertions for Different Versions of a Behavior	N
34. Document changes to policy subject	Y	Y	Changed from contrib to standard and was documented