This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6403 - Enumeration: define policy
Summary: Enumeration: define policy
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Enumeration (show other bugs)
Version: FPWD
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Doug Davis
QA Contact: notifications mailing list for WS Resource Access
Keywords: hasProposal
Depends on:
Blocks: 6402 6406 6407 6721
  Show dependency treegraph
Reported: 2009-01-14 00:06 UTC by Doug Davis
Modified: 2009-12-08 22:12 UTC (History)
2 users (show)

See Also:

latest proposal from f2f (86.50 KB, application/msword)
2009-09-30 10:21 UTC, Doug Davis
once again from f2f (81.50 KB, application/msword)
2009-09-30 10:23 UTC, Doug Davis
hopefully last one (82.50 KB, application/msword)
2009-09-30 10:25 UTC, Doug Davis

Description Doug Davis 2009-01-14 00:06:56 UTC
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.

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.
Comment 2 Doug Davis 2009-03-12 02:07:31 UTC

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"]? ...>
    <x:FilterDialect xmlns:x="xs:anyURI" wsp:Optional="true"/> *

  A policy assertion that specifies that WS-Enumeration protocol 
  MUST be used when communicating with this endpoint. This assertion 
  has Endpoint Policy Subject.

  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.

  This required element allows for the inclusion of nested policy 

  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".

  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.
Comment 3 Doug Davis 2009-04-21 20:37:39 UTC
no need for a new namespace
Comment 4 Robert Freund 2009-04-21 20:38:56 UTC
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.
Comment 5 Robert Freund 2009-04-28 21:18:38 UTC
Comment 6 Asir V Selvasingh 2009-08-04 18:41:15 UTC
High-level proposal is at
Comment 7 Robert Freund 2009-08-06 18:28:22 UTC
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 9 Robert Freund 2009-08-18 21:02:10 UTC
2009-08-18 Generally agreed to Ashok's comment #8
Comment 11 Doug Davis 2009-09-30 10:21:38 UTC
Created attachment 747 [details]
latest proposal from f2f

latest proposal from f2f
Comment 12 Doug Davis 2009-09-30 10:23:02 UTC
Created attachment 748 [details]
once again from f2f
Comment 13 Doug Davis 2009-09-30 10:25:01 UTC
Created attachment 749 [details]
hopefully last one
Comment 14 Robert Freund 2009-09-30 10:26:38 UTC
resolved as proposed in comment #13