Title

Remove term vocabulary from primer


Description

In reviewing the primer, Monica noted one oversight which was part of previous voluminous discussions on negation [1]. We had decided to remove the terms policy vocabulary and policy alternative vocabulary. The primer still uses these now undefined terms in section 2.6 and 3.4.1.

[1] Issues 4544 and 4288 at a minimum (4288 occurred before 4544).
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4288
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4544


Justification

We had earlier decided to remove the term vocabulary.


Target

Primer


Proposal

Section 2.6. Replace:

Company-X is able to meet their customer needs by adding optional support for the Optimized MIME Serialization. Optional support is outlined in section 3.4 Web Services Policy 1.5 - Framework and detailed in section 4.5.2, Web Services Policy 1.5 - Guidelines for Policy Assertion Authors, specifically for Optimized MIME Serialization. An optional policy assertion represents a behavior that may be engaged. When a policy assertion is absent from a policy vocabulary (See section 3.2, Web Services Policy 1.5 - Framework), a policy-aware client should not conclude anything (other than no claims) about the absence of that policy assertion. See section 2.11 Attaching Policy Expressions to WSDL on the absence of policy expressions.

With:

Company-X is able to meet their customer needs by adding optional support for the Optimized MIME Serialization. Optional support is outlined in section 3.4 Web Services Policy 1.5 - Framework and detailed in section 4.5.2, Web Services Policy 1.5 - Guidelines for Policy Assertion Authors, specifically for Optimized MIME Serialization. An optional policy assertion represents a behavior that may be engaged. When that policy assertion is absent from a policy alternative (See section 3.2, Web Services Policy 1.5 - Framework), a policy-aware client should not conclude anything (other than no claims) about the absence of that policy assertion. See section 2.11 Attaching Policy Expressions to WSDL on the absence of policy expressions.

Section 3.4.1. Replace:

In the strict intersection mode two policy alternatives are compatible when each assertion in one is compatible with an assertion in the other, and vice versa. For this to be possible they must share the same policy alternative vocabulary. The strict intersection mode is the mode of intersection discussed in the previous sections of this document.

When using the strict intersection mode all assertions are part of the policy alternative vocabulary, including those marked with wsp:Ignorable. Thus the wsp:Ignorable attribute does not impact the intersection result even when its attribute value is true.

If a requester wishes to ignore ignorable assertions in a provider's policy, then the requester should use the lax intersection mode. In the lax intersection mode all ignorable assertions (i.e. with the value "true" for the wsp:Ignorable attribute) are to be ignored by the intersection algorithm. Thus in the lax intersection mode two policy alternatives are compatible when each non-ignorable assertion in one is compatible with an assertion in the other, and vice versa. For this to be possible the two policy alternatives must share a policy alternative vocabulary for all non-ignorable assertions.

With:

In the strict intersection mode two policy alternatives are compatible when each assertion in one is compatible with an assertion in the other, and vice versa (See section 4.5, Web Services Policy 1.5 - Framework). For this to be possible they must contain the same policy assertion types. The strict intersection mode is the mode of intersection discussed in the previous sections of this document.

When using the strict intersection mode compatibility is computed for all assertions that are part of the policy alternative, including those marked with wsp:Ignorable. Thus the wsp:Ignorable attribute does not impact the intersection result even when its attribute value is true.

If a requester wishes to ignore ignorable assertions in a provider's policy, then the requester should use the lax intersection mode. In the lax intersection mode all ignorable assertions (i.e. with the value "true" for the wsp:Ignorable attribute) are to be ignored by the intersection algorithm. Thus in the lax intersection mode two policy alternatives are compatible when each non-ignorable assertion in one is compatible with an assertion in the other, and vice versa. For this to be possible the two policy alternatives must contain the same policy assertion types for all non-ignorable assertions.