ws-p 6/19/2007: Related to Action 316 (was RE: Strawman for AI 286, 303, 305, 313)

Further comments on these changes. Thanks to MaryAnn for the substantive 
work.

    * Comment: Four editorial nits exist in attached files (.doc and .pdf).
    * Comment: In Section 5.3.4, consider reiterating reuse:
          o Change from: "New Assertion Authors should focus on creating
            assertions for those specific constraints and capabilities
            that do not overlap with other domains but that communicate
            new functionality."
          o Change to: "New Assertion Authors should focus on creating
            assertions for those specific constraints and capabilities
            that do not overlap with other domains but that communicate
            new functionality, and to reuse existing policy assertions
            where possible."
    * Comment: Specify this important information earlier in Section 5.4
      rather than waiting until after Best Practice 12; suggested
      location for specifying this is at the end of first paragraph in
      Section 5.4. Keep similar information later after Best Practice 12.
          o "It is important to note that the main consideration for
            selecting parameters or nesting of assertions is that the
            framework intersection algorithm processes nested
            alternatives, but does not consider parameters in its
            algorithm."
    * Comment: In Section 5.4.1, make clear than an assertion parameter
      is additional qualifying information.
          o Change from: "An assertion author should represent useful
            (or additional) information necessary for engaging the
            behavior represented by a policy assertion as assertion
            parameters."
          o Change to: "An assertion author should represent useful
            additive information necessary for engaging the behavior
            represented by a policy assertion as assertion parameters."
    * Comment: For text to be retained after Best Practice 12:
          o Change from: "The main consideration for selecting
            parameters or nesting of assertions is that the framework
            intersection algorithm processes nested alternatives, but
            does not consider parameters in its algorithm."
          o Change to: "As previously indicated, nested policy
            assertions in policy alternatives are processed by the
            framework intersection algorithm while assertion parameters
            are not."
    * Comment: In Section 5.6.1, since the use of wsp:Optional is not
      directional, revise slightly. Reason: Both may specify policies.
      This proposed change is consistent with succeeding text early in
      Section 5.6.2.
          o Change from: "The provider may influence what is possible by
            choosing whether or not to include policy alternatives in a
            policy expression, by using the wsp:Optional attribute.
          o Change to: "The consumer or provider may influence what is
            possible by choosing whether or not to include policy
            alternatives in a policy expression, by using the
            wsp:Optional attribute. "
    * Comment: Update text Best Practice 11 and the succeeding text to
      be consistent with recent Framework changes in Section 3.1. See:
      http://www.w3.org/Bugs/Public/show_bug.cgi?id=4579.
          o Change from:
                + Best practice 11: Use Nested Assertions for Dependent
                  Behaviors
                  "An assertion author should represent dependent
                  behaviors that are relevant to a compatibility test
                  and apply to the same policy subject using nested
                  policy assertions."
          o Change to:
                + Best practice 11: Use Nested Assertions for Dependent
                  or Associated Behaviors
                  "An assertion author should represent dependent or
                  associated behaviors that are relevant to a
                  compatibility test and apply to the same policy
                  subject using nested policy assertions."
    * Comment: Related to comment above to account for either dependent
      or associated behavior.
          o Change from: "Therefore, when providers require dependent
            behaviors these behaviors should be explicitly specified as
            assertions in a nested policy expression. When the
            definition of an assertion allows for nested dependent
            behaviors, but the use of the assertion only contains an
            empty nested policy expression, this specific use indicates
            the specification of no nested dependent behaviors."
          o Change to: "Therefore, when providers require dependent or
            associated behaviors these behaviors should be explicitly
            specified as assertions in a nested policy expression. When
            the definition of an assertion allows for nested behaviors,
            but the use of the assertion only contains an empty nested
            policy expression, this specific use indicates the
            specification of no nested behaviors."
    * Comment: Consistent with Asir's question, on first Best Practice
      in Section 5.7: "Best Practice: Preserve Context-Free Policies"
      By default, context is part of policies. This should be specific
      to the attachment mechanism being independent of the policy
      alternative.
    * Comment: For this Best Practice 24, this information is
      unspecified in the Framework. Therefore, is this not outside of
      the scope of policy framework? We've deferred preferences to
      v.next which could be related to this text (see:
      http://www.w3.org/Bugs/Public/show_bug.cgi?id=4179).
          o "If an assertion can be attached at multiple points within a
            policy subject, an assertion author should specify a
            preferred attachment point for the chosen policy subject."
    * Comment: In Section 8.1, be specific to what WS-Addressing
      wsam:addressing indicates in two instances.
          o [1] Change from: "The “parent” assertion indicates that both
            forms of responses are supported."
          o [1] Change to: "The “parent” assertion indicates that
            WS-Addressing is supported without qualification."
          o [2] Change from: "Within the specification it was possible
            for implementers to chose whether they supported anonymous
            responses or non-anonymous responses in the context of a
            message exchange patterns."
          o [2] Change to: "Within the specification it was possible for
            implementers to chose whether they supported anonymous
            responses or non-anonymous responses in the context of a
            message exchange patterns, or whether WS-Addressing is
            supported without qualification."