Re: issue 6401/6661: combined proposal

Doug,

Thanks for simplifying the proposal. We generally agree with your
changes but have two minor changes below enclosed in tags
<add>...</add>:

1. Second paragraph in Section A: add some text to spell out the
options. Otherwise, it's not clear which of the following three sections
describe the options.

<p>
There are many ways in which an Event Source could describe and
advertise the structure of the Events for which it will issue
Notifications. To provide a basic level of interoperability, this
specification defines the following two optional mechanisms <add>in
Section A.2 and A.3</add> for describing and advertising Event
information. If an implementation of a WS-Eventing Event Source chooses
to describe the structure of its Events and advertise this description,
it is RECOMMENDED that at least one of these mechanisms be used.
Mechanisms other than these MAY be used to describe and advertise the
structure of Events, but the definition of such mechanisms is out of the
scope of this specification. 
</p>

2. First paragraph in Section A.3: add two words to link this section
with section A.1 as section A.2 does. Otherwise, it may appear that the
concept Event Types only applies to the option in Section A.2.

<p>
As described previously, Event Sources transmit Events to Event Sinks as
SOAP messages called "Notifications". These <add>Events and</add>
Notifications MAY be described via a Web Services Definition Language
[WSDL 1.1] definitions element termed a "Notification WSDL". A
Notification WSDL describes the interface that the Event Sink is
required to implement to receive and process the Notifications that
might result from a successful Subscribe request that used a particular
Format URI. The following is an example of a Notification WSDL:
</p>

Best,
Li Li

Received on Wednesday, 26 August 2009 18:03:11 UTC