This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
While the WSDL of a data source can be used to advertise some aspects of the features supported by that event source, it can not be used to indicate all of them. For example, there is no way to list all of the supported Filter Dialects. Proposal: Define WS-Policy expression(s) for all of the variables/features of WS-Enumeration (that can not already be described by its WSDL) so that a Data Source can advertise which features/options a client can use.
proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0007.html
proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0007.html Following the pattern being proposed for WS-Eventing's policy, define a new section of WS-Enum that has the following: - - - - - - - - - - - - - - - - - - - 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: <wsenp:WSEnumeration [wsp:Optional="true"]? ...> <wsp:Policy> <x:FilterDialect xmlns:x="xs:anyURI" wsp:Optional="true"/> * ... </wsp:Policy> </wsenp:WSEnumeration> /wsenp:WSEnumeration A policy assertion that specifies that WS-Enumeration protocol MUST be used when communicating with this endpoint. This assertion has Endpoint Policy Subject. /wsenp:WSEnumeration/wsp:Optional Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the assertion. The intuition is that the behavior indicated by the assertion is optional, or in this case, that WS-Enumeration MAY be used. /wsenp:WSEnumeration/wsp:Policy This required element allows for the inclusion of nested policy assertions. /wsenp:WSEnumeration/wsp:Policy/x:FilterDialect When present, this 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 the namespace URI of this element. Note: the namespace of this element is application defined, but the Local Name MUST be "FilterDialect". /wsenp:WSEnumeration/wsp:Policy/x:FilterDialect@wsp:Optional This attribute specifies that the assertion is optional per WS-Policy. This attribute MUST be present since the inclusion of a Filter dialect in a Enumerate request is optional.
s/wsenp/wsen/g no need for a new namespace
modified proposal as above with the following: insert after :/wsenp:WSEnumeration/wsp:Policy/x:FilterDialect An endpoint should include a filterdialect policy assertion for each of the filter dialects that it supports.
Action-60
High-level proposal is at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0085.html
Directional Decision: 1. Enum supported or not 2. What features supported 3 support clients who do not care about the features 4. QNames for assertions we define should be in our namespace 5. assertions shall be concrete
comment at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0033.html
2009-08-18 Generally agreed to Ashok's comment #8
proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0090.html
Created attachment 747 [details] latest proposal from f2f latest proposal from f2f
Created attachment 748 [details] once again from f2f
Created attachment 749 [details] hopefully last one
resolved as proposed in comment #13