NEW ISSUE: 4073 [Guidelines] Free standing statements

Title: [Guidelines] Free standing statements

Description:

This issue identifies 7 free standing statements in the Guidelines
document without any support from the framework or the attachment or an
assertion specification.


a) "WS-Policy Domain owners or WS-Policy authors are defined by the
WS-Policy Framework to be a community that chooses to exploit the
WS-Policy Framework by creating their own specification to define a set
of assertions that express the capabilities and constraints of that
target domain." [1]

There isn't any such definition in the framework draft. Can't think of a
reason why this term should be defined either.


b) "WS-Policy Domain authors must also specify how to associate the
assertions they have defined with the policy subjects identified by the
WS-PolicyAttachment specification." [1]

A policy attachment mechanism defines how to associate policy
expressions with policy subjects.

Assertion authors are not required to specify how to associate an
assertion with a policy subject. But, an assertion description should
specify a policy subject. For instance, if a policy assertion were to be
used with WSDL, an assertion description should specify a WSDL policy
subject. This topic is well covered by Section 4.7 [2] in the Guidelines
document.


c) "When a web service provider chooses to make its capabilities and
constraints available, it may also need to conform to requirements of
other policy specifications it utilizes" [3]

'it may also need to conform' maps to 'provider may also need to
conform'. Neither the framework nor the attachment document defines
provider level conformance. There aren't any assertion specification
that defines provider level conformance.


d) "If the domain authors want to delegate the processing to the
framework, utilizing nesting should be considered. Otherwise, domain
specific comparison algorithms will need to be devised and be delegated
to the specific domain handlers that are not visible to the WS-Policy
framework." [4]

'will need to be devised' is too strong and doesn't have any basis to
support this statement. Suggest toning this statement to 'may'.


e) "WS-Policy is intended to communicate the requirements, capabilities,
preferences and behaviors of nodes that provide the message's path, not
specifically to declare properties of the message semantics." [5]

'preferences' cannot be represented using Web services Policy 1.5.


f) "In particular, the timing of a policy attachment or the role that a
party who attaches policy should have no bearing on the evaluation of
the policy assertion" [6] 

What does 'timing of a policy attachment' mean? Not aware of any such
concept in the framework or attachment draft.


g) "The policy framework only defines an algorithm for calculating
effective policies for WSDL 1.1 based subjects." [7]

This statement is incorrect. Policy framework neither defines any
attachment mechanisms nor any algorithm for calculating effective
policies. The attachment draft defines an algorithm for calculating the
effective policy for a given policy subject and effective policies for
WSDL 11, WSDL 20 and UDDI policy subjects.


Justification:

There is no basis to support these seven statements. These statements
will confuse and mislead the readers.


Proposal:

A. Drop a)

B. Replace b) with

'An assertion author should also specify a policy subject. For instance,
if a policy assertion were to be used with WSDL, an assertion
description should specify a WSDL policy subject.'

C. Drop c)

D. s/will need to be devised/may need to be devised/

E. s/capabilities, preferences and behaviors/capabilities and behaviors/

F. Drop f)

G. Drop g)

[1] http://tinyurl.com/y3as59#domain-owners
[2] http://tinyurl.com/y3as59#levels-of-abstraction 
[3] http://tinyurl.com/y3as59#providers  
[4] http://tinyurl.com/y3as59#which-one-to-use 
[5] http://tinyurl.com/y3as59#self-describing 
[6] http://tinyurl.com/y3as59#context-free-policies 
[7] http://tinyurl.com/y3as59#scenario

Regards,
 
Asir S Vedamuthu
Microsoft Corporation

Received on Tuesday, 12 December 2006 20:04:34 UTC