Action 309 Wording to Resolve Bug 4583

1.	Change Section 3.2 of the Framework Document as follows:

Was:

Section 3.2: A policy alternative MAY contain multiple assertions of the same type. Mechanisms for determining the aggregate behavior indicated by the assertions (and their Post-Schema-Validation Infoset (PSVI) (See XML Schema Part 1 [XML Schema Structures]) content, if any) are specific to the assertion type and are outside the scope of this document.
Suggested (based on wording from Dale and Asir): 
Section 3.2: A policy alternative MAY contain multiple assertions of the same type. Mechanisms for determining the aggregate behavior indicated by the assertions (and their Post-Schema-Validation Infoset (PSVI) (See XML Schema Part 1 [XML Schema Structures] content) are specific to the assertion type and are outside the scope of this document. If domain policy assertion language authors fail to specify the semantics of  repetition of policy assertions of a type that allows neither parameters nor nested policy expressions within a policy alternative, then repetition is simply redundancy, and multiple assertions of the assertion type within a policy alternative have the same meaning as a single assertion of the type within the policy alternative."

2.	Add a final bullet to the bullets at the start of section 5.4.

.	The output of the intersection of two policies is one or more compatible alternatives.  Each compatible alternative contains pairs of compatible assertions, one from each of the input policies.  The contents of both assertions in the pair are used to indicate the correct behavior.  Whether the two assertions in the pair are compatible or redundant depends on the domain-specific semantics of the assertion type. If the assertions have no parameters and the assertions in nested policies have no parameters the assertions of that type are redundant.


3.	Change the paragraph that follows the result of the intersection in section 4.5.

Was:
Note that there are > 1 assertions of the type sp:SignedParts; when the behavior associated with sp:SignedParts is invoked, the contents of both assertions are used to indicate the correct behavior. Whether these two assertions are compatible depends on the domain-specific semantics of the sp:SignedParts assertion. To leverage intersection, assertion authors are encouraged to factor assertions such that two assertions of the same assertion type are always (or at least typically) compatible.

Suggested (adds wording specific to the example).:
Note that there are 2 assertions of the type sp:SignedParts and 2 assertions of the type sp:EncryptedParts, one from each of the input Policies. In general, whether the two assertions in each pair are compatible or redundant depends on the domain-specific semantics of the assertion types. As mentioned above, if the assertions have no parameters and the assertions in nested policies have no parameters, the assertions are redundant.   Thus, the two sp:EncryptedParts assertions are redundant.  Whether the two sp:SignedParts assertions are compatible or redundant depends on the semantics defined for this assertion type.





All the best, Ashok