This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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 assertions 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 assertions 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:/
RESOLUTION: issue 4852 closed with proposed edits adopted, editors to incorporate changes See http://www.w3.org/2007/07/17-ws-policy-irc#T10-01-45