[Bug 3989] [Guidelines] Suggested Format

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





------- Comment #1 from chrisfer@us.ibm.com  2007-03-14 18:48 -------
When resolving this issue, we should check to ensure that the content of the
removed section 4.6 is captured in the new best practices summary.

Removed section 4.6:

4.6 Typing Assertions

Since a QName is the central mechanism for identifying a policy assertion,
Assertion Authors should be aware of the possible evolution of their assertions
and how this would impact the semantics of the assertion overtime. A namespace
associated with the assertion may be used to indicate a specific version of an
assertion but this has its limitations. See section 5. Versioning Policy
Assertions for more detail.

The typing must be done in combination with the scoping of the semantics to a
policy subject. WS-PolicyAttachment provides a means of associating an
assertion with arbitrary subjects, regardless of their nature. This flexibility
can lead to ambiguity in the interpretation of policy; for example, if one
attaches an assertion with the semantic "must be encrypted" to a SOAP endpoint,
it's unclear what must be encrypted.

One way to disambiguate the semantic is to generally determine if an assertion
is specific to a policy attachment mechanism. An example could be identifying
whether the assertion expressed is associated with behaviors (endpoints) or
artifacts (messages) and then constraining the use of an assertion to one of
these subjects.

Thus our example encryption assertion would have a subject of "message", and
could only be attached to messages, where the assertion is valid. However,
Assertion Authors need to be aware that policy attachment subjects are not
limited to the subjects defined in WSDL. The external attachment model in
WS-PolicyAttachment allows for the definition of other domain expressions to be
policy subjects. More of this topic is covered in the Web Services Policy
Primer

Best Practice- To avoid confusion, assertion definitions should be precise
about their semantics and include information that restricts their set of
permissible policy subjects appropriately and indicates which QNames are
associated with which subjects.

   1.

      Description must clearly and completely specify the syntax (plus an XML
Schema document) and semantics of a policy assertion.
   2.

      If there is a nested policy expression, description must declare it and
enumerate the nested policy assertions that are allowed.
   3.

      A policy alternative may contain multiple instances of the same policy
assertion. Description must specify the semantics of parameters and nested
policy (if any) when there are multiple instances of a policy assertion in the
same policy alternative.
   4.

      If a policy assertion is to be used with WSDL, description must specify a
WSDL policy subject – such as service, endpoint, operation and message.

Received on Wednesday, 14 March 2007 18:49:12 UTC