- From: Paul Nolan <NOLANPT@uk.ibm.com>
- Date: Tue, 28 Jul 2009 14:38:45 +0100
- To: public-ws-resource-access@w3.org
- Message-ID: <OFB06CA11A.DE8528AE-ON80257601.0048B509-80257601.004AF659@uk.ibm.com>
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
Received on Tuesday, 28 July 2009 13:47:15 UTC