analysis of EventDescriptions proposal against use cases and requirements

The following is an analysis of how the EventDescriptions proposal for 
describing and advertising Event Types attached to this email satisfies 
the use cases and requirements specified on the Wiki 
<http://www.w3.org/2002/ws/ra/wiki/Use_Cases_for_6401-6661>.

*I. Event Sink Code Generation*

    *A. Raw Notifications* - the EventDescriptions proposal supports the
    use of current WSDL-based tools to generate the code to marshal and
    dispatch Raw Notifications by specifying the transformation of the
    EventDescriptions element into a BP 1.1 conformant, WSDL 1.1
    definitions element (see Appendix F).

    *B. Wrapped Notifications* - since the WSDL for Wrapped
    Notifications is already specified in Appendix D and, by definition,
    all listeners for Wrapped Notifications must support this WSDL,
    there is nothing more that needs to be done to provide support for
    Wrapped Notifications. Support for the additional marshalling of the
    contents of Wrapped Notifications may be provided by using XML data
    binding technologies (e.g. XMLBeans <http://xmlbeans.apache.org/>)
    in conjunction with the information in the
    /EventDescriptions/eventType though the use cases around this are
    unclear.

    *C. Extension Notifications* - Since the EventDescriptions element
    describes the shape of Events independently of how they are included
    in a Notifications, it is well suited for the definition of
    additional Notification formats.

*II. Event Type Visibility* - As described in Section 6.2 "Retrieving 
Event Types", a Subscriber can view metadata (i.e. schema definitions) 
on the set of Event Types supported by an Event Source. An Event Source 
could pre-filter this metadata based on the Subscribers authenticated 
identity to insure that the Subscriber is only provided with a list of 
those Event Types to which he/she has access.

*III. Event Type Completeness* - There are two crucial pieces of 
information needed to implement an Event Sink. The first is the schema 
for the set of Event Types that may be emitted. This can be retrieved as 
described in Section 6.2 "Retrieving Event Types". The second is the 
format of the Notifications in which the Events will be transmitted. 
This is selectable at Subscribe time and defined by either the 
WS-Eventing spec (for Raw and Wrapped Notifications) or by some 
extension spec.

*IV. Non-Metadata Use Cases* - Nothing in the EventDescriptions proposal 
prevents the Subscriber and Event Source provider from communicating the 
information necessary to implement these use cases by some means other 
than metadata.

*V. Multiple Notification Variations* - because the EventDescriptions 
proposal separates the Event Type information from the Notification 
Format, it is particularly well suited to support this use case (this 
use case was, in fact, the motivating factor for the development of this 
proposal).

*VI. Advertise Notification Variations* - because it separates the 
description Event Types from Notification formats, nothing in the 
EventDescriptions proposal supports this use case, but neither is there 
anything that prevents its support via some other, more appropriate 
mechanism such as the use of WS-Policy assertions (or sub-assertions) 
that indicate which Notification formats are supported by an Event Source.

*VII. Deterministic WSDL* - for Raw Notifications a deterministic 
process for generating a WSDL is described in Appendix F. For Wrapped 
Notifications the WSDL is included in Appendix D. Extended Notification 
formats should describe the mapping for Event Types to Notifications in 
that format.

*VIII. WS-I Basic Profile* - the transformation of the EventDescriptions 
element into a WSDL 1.1 definitions element described in Appendix F 
results in a WSDL that conforms to Basic Profile 1.1 
<http://www.ws-i.org/Profiles/BasicProfile-1.1.html>.

*IX. Extensibility of Message Exchange Patterns* - the EventDescriptions 
proposal does nothing to prevent the definition of extended MEPS in 
WS-Eventing.

*Global Non-Functional Requirements
*

    *Constrained Environments* - since the EventDescriptions proposal
    describes build-time artifacts and processes, it does not impact
    constrained environments.

    *Known Technologies* - the EventDescriptions proposal is dependent
    upon the following known technologies: XML Schema, WSDL 1.1, and
    optionally XSL Transformations to transform the EventDescriptions
    element into a wsdl:definitions element.

    *Consistent with UDDI* - nothing in the EventDescriptions proposal
    prevents either the Event Source or Event Sink from publishing and
    registering their services though UDDI.

- gp