NEW Issue: 4852 [Guidelines] Minor Editorial Comments

These are editorial comments on the Guidelines document at http://tinyurl.com/2hm9cc

Section 1

a) s/The WS-Policy specification defines a policy to be a collection of policy alternatives with each policy alternative a collection of policy assertions./The WS-Policy specification defines a policy to be a collection of policy alternatives. Each policy alternative is a collection of policy assertions./

Section 2

b) s/4. Start with Simple Assertion/4. Start with a Simple Assertion/

c) s/21. Assertion Authors Should Specify Policy Subject(s)/21. Specify Policy Subject(s)/

Section 4.1.1

d) s/Assertion Authors are a community that chooses to exploit the WS-Policy Framework by creating their own specification to define a set of assertions that express the capabilities and constraints of that target domain./Assertion Authors are part of a community that chooses to exploit the WS-Policy Framework by creating their own specifications to define a set of assertions that express the capabilities and constraints of that target domain./

Section 4.1.2

e) s/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./A consumer of WS-Policy Assertions can be any entity that is capable of parsing a WS-Policy expression and selecting one alternative from the policy./

Section 5.1

f) s/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./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 expressions (nested assertions), where each nested assertion of which relates to an aspect of the behavior, yet encapsulated within a single assertion./

g) s/Therefore, Assertion Authors need to have a specific goal in mind for the assertions that they author. Assertion specifications should include a detailed specification of the assertion's semantics, a set of valid policy subjects to which the asserction maybe attached./Assertion Authors need to have a specific goal in mind for the assertions that they author. Assertion specifications should include a detailed specification of the assertion's semantics and, a set of valid policy subjects to which the assertion may be attached./

h) s/Finally, if a set of assertions describes a wide range of behaviors, the ability to combine individual assertions may also need to be considered./Finally, the ability to combine individual assertions may also need to be considered./

Section 5.3.1

i) s/Assertion Authors have the option to 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/Assertion Authors have the option to 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. 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./

Section 5.6.2

j) s/5.6.2.1 Example//

Section 6

k) s/There are three aspects to versioning policy assetions:/There are three aspects to versioning policy assertions:/

Regards,

Asir S Vedamuthu
Microsoft Corporation

Received on Friday, 13 July 2007 01:48:04 UTC