SOA RA Policy stuff from W3C

[Duane Nickull <dnickull@adobe.com>]

IN an attempt not to redefine the semantics of the various terms used, here
is some potentially useful terminology from the W3C WS-Policy activity at
http://www.w3.org/Submission/WS-Policy/

2.4 Terminology



Policy
    A policy is a collection of policy alternatives.
Policy Alternative
    A policy alternative is a collection of policy assertions.
Policy Assertion
    A policy assertion represents an individual requirement, capability, or
other property of a behavior.
Policy Assertion Type
    A policy assertion type represents a class of policy assertions and
implies a schema for the assertion and assertion-specific semantics.
Policy Assertion Parameter
    A policy assertion parameter qualifies the behavior indicated by a
policy assertion.
Policy Vocabulary
    The policy vocabulary of a policy is the set of all policy assertion
types used in the policy.
Policy Expression
    A policy expression is an XML Infoset representation of a policy, either
in a normal form or in an equivalent compact form.
Policy Subject
    A policy subject is an entity (e.g., an endpoint, message, resource,
interaction) with which a policy can be associated.
Policy Scope
    A policy scope is a collection of policy subjects to which a policy may
apply.
Policy Attachment
    A policy attachment is a mechanism for associating policy with one or
more policy scopes.

3. Policy Model

This section defines an abstract model for policies and for operations upon
policies.

This abstract model is independent of how it is represented as an XML
Infoset.
3.1 Policy Assertion

A policy assertion identifies a behavior that is a requirement (or
capability) of a policy subject. Assertions indicate domain-specific (e.g.,
security, transactions) semantics and are expected to be defined in
separate, domain-specific specifications.

Assertions are strongly typed by the domain authors that define them. The
type is identified only by the XML Infoset [namespace name] and [local name]
properties (that is, the qualified name or QName) of the root Element
Information Item representing the assertion. Assertions of a given type MUST
be consistently interpreted independent of their policy subjects.

Domain authors MAY define that an assertion contains a policy expression as
one of its [children]. Policy expression nesting is used by domain authors
to further qualify one or more specific aspects of the original assertion.
For example, security policy domain authors may define an assertion
describing a set of security algorithms to qualify the specific behavior of
a security binding assertion.

The XML Infoset of an assertion MAY contain a non-empty [attributes]
property and/or a non-empty [children] property. Such content MAY be used to
parameterize the behavior indicated by the assertion. For example, an
assertion identifying support for a specific reliable messaging mechanism
might include an Attribute Information Item to indicate how long an endpoint
will wait before sending an acknowledgement.

Domain authors should be cognizant of the processing requirements when
defining complex assertions containing additional assertion content or
nested policy expressions. Specifically, domain authors are encouraged to
consider when the identity of the root Element Information Item alone is
enough to convey the requirement (capability).
3.2 Policy Alternative

A policy alternative is a logical construct which represents a potentially
empty collection of policy assertions. An alternative with zero assertions
indicates no behaviors. An alternative with one or more assertions indicates
behaviors implied by those, and only those assertions.

The vocabulary of a policy alternative is the set of all assertion types
within the alternative. The vocabulary of a policy is the set of all
assertion types used in all the policy alternatives in the policy. An
assertion whose type is part of the policy's vocabulary but is not included
in an alternative is explicitly prohibited by the alternative.

Assertions within an alternative are not ordered, and thus aspects such as
the order in which behaviors (indicated by assertions) are applied to a
subject are beyond the scope of this specification.

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) content, if any)
are specific to the assertion type and are outside the scope of this
document.
3.3 Policy

At the abstract level a policy is a potentially empty collection of policy
alternatives. A policy with zero alternatives contains no choices; a policy
with one or more alternatives indicates choice in requirements (or
capabilities) within the policy.

Alternatives are not ordered, and thus aspects such as preferences between
alternatives in a given context are beyond the scope of this specification.

Alternatives within a policy may differ significantly in terms of the
behaviors they indicate. Conversely, alternatives within a policy may be
very similar. In either case, the value or suitability of an alternative is
generally a function of the semantics of assertions within the alternative
and is therefore beyond the scope of this specification.
-- 
**********************************************************
Sr. Technical Evangelist - Adobe Systems, Inc.           *
Chair - OASIS SOA Reference Model Technical Committee    *
Blog: http://technoracle.blogspot.com                    *
Music: http://www.mix2r.com/audio/by/artist/duane_nickull*
**********************************************************