This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4660 - [Guidelines] Best Practice Statments should be statements
Summary: [Guidelines] Best Practice Statments should be statements
Status: RESOLVED FIXED
Alias: None
Product: WS-Policy
Classification: Unclassified
Component: Guidelines (show other bugs)
Version: FPWD
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: maryann
QA Contact: Web Services Policy WG QA List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-18 12:20 UTC by Christopher Ferris
Modified: 2007-07-18 11:14 UTC (History)
0 users

See Also:


Attachments

Description Christopher Ferris 2007-06-18 12:20:40 UTC
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
Comment 1 Christopher Ferris 2007-07-18 11:14:50 UTC
[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