W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > July 2009

RE: issue 6403: ws-enum policy proposal

From: Asir Vedamuthu <asirveda@microsoft.com>
Date: Thu, 30 Jul 2009 17:45:47 -0700
To: Paul Nolan <NOLANPT@uk.ibm.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-ID: <D46B7A44F5BD0C4A96D7D69E31C51D6B597C765D1F@NA-EXMSG-C118.redmond.corp.microsoft.com>
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 00:46:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:08 GMT