Re: issue 6403: ws-enum policy proposal

Asir:
I don't think you answered Paul's concern about extending the 
Enumeration assertion with sub-assertions from
other namespaces.
Paul: If you could give an example of such an extension, that may help 
move the argument forward.
All the best, Ashok


Asir Vedamuthu wrote:
>
> Dear Paul,
>
> Keeping it simple, minting a concrete policy assertion and 
> representing supported filter dialects as policy assertion parameters 
> are good ideas!
>
> It would be good to use ‘wsep:Enumeration’ to identify the use of Web 
> Services Enumeration protocol (instead of a ‘wsep:Filter’).
>
> A data source endpoint may support multiple filter dialects. Suggest 
> that we allow sufficient room to accommodate multiple filter dialects.
>
> This means, the suggested normative outline for the assertion would be:
>
> <wsep:Enumeration [wsp:Optional=‘true’]? …>
>
> <wsep:SupportedFilterDialect>xs:anyURI</wsep:SupportedFilterDialect>*
>
> …
>
> </wsep:Enumeration>
>
> We will be happy to work with you to prepare a concrete proposal to 
> close issue 6403.
>
> Regards,
>
> Asir S Vedamuthu
>
> Microsoft Corporation
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Paul 
> Nolan
> *Sent:* Tuesday, July 28, 2009 6:39 AM
> *To:* public-ws-resource-access@w3.org
> *Subject:* 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/
>
>
>
>
>

Received on Friday, 31 July 2009 12:28:31 UTC