Re: issue 6403: ws-enum policy proposal

I wanted to present an alternative proposal for this issue.  The impetus 
for this suggestion is driven by some general points I would like to make.

1. I do not believe the use of a nested Assertions is appropriate in this 
case. Although nesting is a good way of grouping related Assertions 
together it is best suited for describing the capabilities of a single 
domain. On the one hand Enumeration is a single domain. However in this 
instance we fully intend users  to extend the  Enumeration Policy to 
include further Assertions. Some of these new assertions will have 
alternative namespaces which effectively means the sub-Assertions are from 
different domains than the outer Assertion.  A WS-Policy processing 
framework will dispatch the Policy to the domain of the outer Assertion - 
Enumeration in the previous proposal. This means that the Enumeration 
domain must know how to route any sub-Assertions it finds to the relevant 
domain. There is also a headache understanding the meanings of ha various 
combinations of  the sub-Assertion and the outer Assertion being optional 
during intersection.
 
2.  If we give the FilterDialect Assertion the namespace of the 
Enumeration Policy domain this will allow an Enumeration framework to 
entirely own the behaviour of these Assertions. Also to some extent 
keeping the FilterDialect Assertion in the Enumeration Policy domain 
simplifies the post-Policy-Intersection combine operation. Since the 
Enumeration Policy domain has entirely defined the Assertion it can take 
ownership of this combine operation. If other domains are required to 
perform the combine operation then the Enumeration framework will have to 
manage this.

3. Any new Assertions defined that relate to Enumeration should be defined 
and processed externally by the extension domain. This may lead to the 
loss of association between the a newly defined Assertion and Enumeration. 
However this association may be preserved in other ways - such as the 
context in which the Policy is published.

---------------------------------------------------------------------------------------------------
WS-Policy Framework and WS-Policy Attachment [WS-PolicyAttachment] 
collectively define a framework, model and grammar for expressing the 
requirements, and general characteristics of entities in an XML Web 
services-based system. To enable a Data Source to describe its
requirements, this specification defines a single policy assertion that 
leverages the WS-Policy framework.  This assertion has Endpoint
Policy Subject.

The normative outline of this assertion is:

<wsep:Filter Dialect="xs:anyURI" wsp:Optional="xs:boolean"/>*
 
A policy assertion that specifies that WS-Enumeration protocol MUST be 
used when communicating with this endpoint. This assertion has Endpoint 
Policy Subject.

/wsenp:Filter
 
When present, this OPTIONAL assertion defines the requirement that the 
consumer, if it chooses to include a filter in the wsen:Enumerate request, 
MUST use the filter dialect associated with Dialect URI of this element. 

/wsenp:Filter@Dialect

This attribute indicates the URI of the Dialect required for this filter 
operation.

/wsenp:Filter@wsp:Optional

This attribute specifies that the assertion is optional per WS-Policy. 


Paul Nolan
Web Services Development
Hursley, England, 44(0) 1962 817228 (Internal 247228) 
Internet: nolanpt@uk.ibm.com





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU