[Bug 5204] Remove term vocabulary from primer

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5204

           Summary: Remove term vocabulary from primer
           Product: WS-Policy
           Version: LC
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Primer
        AssignedTo: fsasaki@w3.org
        ReportedBy: fabian.ritzmann@sun.com
         QAContact: public-ws-policy-qa@w3.org


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.

Received on Wednesday, 17 October 2007 10:56:25 UTC