This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Title: Best Practice Statments should be statements Target: Guidelines Description: The current section on Best Practices has incomplete "phrases" instead of statements. The proposal has 2 parts and an option on the second part: Part 1 is to change these phrases to be statements Part 2 is to reorganize them (and possibly renumber them). Option A-- reorganize within current table which is right now just a generated list of BP's as they occur within the document.....so its not known how much work is needed to do a "reorg" and whether it would be acceptable to move sections around so that the "auto generation" happens in the correct order. Option B-- is to put an additional table in the document which groups the Best Practices logically ( an example of this is that the first best practice included bullets which are really best practices later in the document). ------------------------------------------------------------------------------- <current text for Best practice 1: Parts of an Assertion Specification> 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. Any composition considerations if the assertion is used with other assertions in a context. ------------------------------------------------------------------------------- Part 1: <change from> 1. Parts of an Assertion Specification 2. Semantics Independent of Attachment Mechanisms 3. Semantics Independent of the Form 4. Start with Simple Assertion 5. Use Unique QNames 6. Provide an XML Outline 7. Specify Semantics Clearly 8. Not Necessary to Understand a Message 9. Avoid Duplication of Assertions 10. Use Parameters for Useful Information 11. Use Nested Assertions for Dependent Behaviors 12. Enumerate Nested Assertions 13. Discourage Domain Specific Intersection 14. Assertions Document Ignorable Behavior 15. Ignorable Attribute in XML 16. Assertion XML should allow use of wsp:Optional attribute 17. Assertion description should explicitly indicate that wsp:Optional is allowed. 18. Limit use of Optional Assertions 19. Consider entire message exchange pattern when specifying Assertions that may be optional 20. Indicate use of an Optional Assertion 21. Assertion Authors Should Specify Policy Subject(s) 22. Choose the Most Granular Policy Subject 23. Define Semantics of Attachment to Multiple Policy Subjects 24. Specify Preferred Attachment Point for an Assertion 25. Describe Semantics of Multiple Assertions of Same Type 26. Specify Composition with Related Assertions 27. Use Independent Assertions for Different Versions of a Behavior 28. Change of the Policy Subject Over Time ---------- <change to> ---------- Best Practice 1. What to include in an Assertion Specification Best Practice 6. Specify Assertion Semantics Clearly Best Practice 2. The semantics of an Assertion should be Independent of Attachment Mechanisms Best Practice 3. The Semantics of an Assertion should be Independent of the Form Best Practice 8. The Assertion Semantic should not depend on the semantics of the Message Best Practice 21. Assertion Description Should Specify a Policy Subject Best Practice 22. Choose a Granular Policy Subject Best Practice 26. Specify Composition with Related Assertions Best Practice 4. Start with Simple Assertion Best Practice 5. Use Unique QNames Best Practice 7. Provide an XML Outline for an Assertion <consider renumbering to 7a, 7b> Best Practice 16. Indicating Optional Behavior in XML Outline Best Practice 15. Indicating Ignorable Behavior in XML Outline Best Practice 9. Avoid Duplication of Assertions Best Practice 10. Use Parameters for Additional Assertion Information Best Practice 11. Use Nested Assertions for Dependent Behaviors Best Practice 12. Declare Nested Assertions Best Practice 13. Discourage Domain Specific Intersection Best Practice 14. Declare Ignorable Behavior Best Practice 17. Declare Optional Behavior. Best Practice 18. Limit use of Optional Assertions Best Practice 19. Consider entire message exchange pattern when specifying Assertions that may be optional Best Practice 23. Define Semantics of Attachment to Multiple Policy Subjects Best Practice 24. Specify Preferred Attachment Point for an Assertion Best Practice 25. Describe Semantics of Multiple Assertions Best Practice 27. Use Independent Assertions for Multiple Versions of a Behavior Best Practice 28. How to change the Policy Subject Over Time
[06:44] dorchard: #1: good [06:46] dorchard: #2: "make behaviours relevent to compatibility tests"... [06:46] fsasaki: s/relevent/relevant/ [06:47] dorchard: chrisf "define assertions relevent to compatibility tests" [06:47] dorchard: #2: Define assertions relevent to compatibilty tests [06:48] * Fabian likes revelant :-) [06:48] dorchard: #3: as-is [06:48] dorchard: #2: Define assertions relevant to compatibility tests [06:48] dorchard: #4: as-is [06:48] dorchard: #5: as-is [06:49] dorchard: #6: open issue [06:49] dorchard: #7: as-is [06:49] dorchard: #8: see above [06:50] dorchard: #9: document use of the ignorable attribute [06:50] dorchard: #10: define message format only [06:51] dorchard: #11: as-is\ [06:51] *** FrederickHirsch has joined #ws-policy. [06:51] *** fjh has signed off IRC (Quit: CGI:IRC (EOF)). [06:51] dorchard: #12: as-is [06:52] dorchard: #13: as-is [06:52] dorchard: #14: as-is [06:52] dorchard: #15: as-is [06:53] dorchard: #16: Allow use of wsp:Optional [06:53] dorchard: #17 may go away, part 4861 [06:54] dorchard: #18 also related to 4861 [06:54] dorchard: #19 also related 4861 [06:54] dorchard: #20 also related to 4861 [06:55] dorchard: #21: as-is [06:55] dorchard: #22: as-is [06:56] dorchard: #23: n/a, no change now [06:56] dorchard: #24: Specify Preferred Attachment Point [06:58] dorchard: #25: Semantics of Multiple Instances of Same Type [06:58] Zakim: -Abbie_Barbir [07:00] * fsasaki zakim, who is here? [07:00] * Zakim sees on the phone: Iona [07:00] * Zakim sees on irc: FrederickHirsch, monica, maryann, SergeyB, Ashok, TomR, charlton, pbc, asir, abbie, ArnaudM, dorchard, cferris, Fabian, RRSAgent, Zakim, dmoberg, fsasaki, trackbot [07:01] dorchard: #25: as-is [07:02] dorchard: #26: as-is [07:02] dorchard: #27: Independent Assertions for Different Versions of a Behavior [07:03] dorchard: #28: document changes to policy subject [07:05] dorchard: paulc: don't want to lose the question about whether we are talking just about assertion authors or also assertion "users" [07:07] dorchard: paulc: bp on how to write an individual assertion, and bp about non specific assertion things that an assertion author should do. [07:07] cferris: best practives for assertion authors and best practices for assertions [07:08] dorchard: and no best practices for policy expression authors [07:09] cferris: ACTION: Maryann to draft proposal to provide list of BPs that relate to assertion authors specifically [07:09] * trackbot noticed an ACTION. Trying to create it. [07:09] * RRSAgent records action 3 [07:09] trackbot: Created ACTION-337 - Draft proposal to provide list of BPs that relate to assertion authors specifically [on Maryann Hondo - due 2007-07-25]. [07:09] dorchard: audiences are: assertion authors, assertions, policy expression authors [07:11] dorchard: I give up. [07:11] * asir .. the problem is .. you are stateless :-) [07:12] * dorchard what did you say? [07:12] * dorchard who am i? [07:12] * dorchard what am I doing here? [07:12] cferris: RESOLUTION: issue 4660 closed with IRC documented changes to the BPs above [07:12] cferris: rrsagent, where am i? [07:12] * asir sounds like that movie, '50 dates [07:12] RRSAgent: See http://www.w3.org/2007/07/18-ws-policy-irc#T11-14-17