Re: WS-DD comments on WS-Eventing WD-ws-eventing-20090924

My take on these....
> 1.     A mechanism to relate the portType(s) of an event source Web 
> Service to the abstract description of the events it can produce is 
> needed. This mechanism cannot be solely based on WS-
> MetadataExchange, as this information may be needed by clients at 
> design time, before any service endpoints are available. The draft 
> replaces the previous mechanism for advertising events produced by a
> source, based on a portType extension (using both the wse:
> EventSource attribute and notification and solicit/response 
> operations), by two new mechanisms, one introducing a new language 
> (Event Descriptions), the second one using a WSDL definition for the
> sink. Both mechanisms provide an abstract description of the events,
> but no mechanisms to relate them to the portType of the event 
> source. Rather, it is suggested to use new WS-Eventing dialects in 
> conjunction with WS-MetadataExchange to retrieve the descriptions 
atruntime. 

I've heard similar comments before and I'm still confused by them.  :-)
How did the Subscriber get the Event Source's WSDL to begin with? Whatever
mechanism it used to retrieve that WSDL should be used to retrieve the
Sink's WSDL or the Event Description stuff.  Not sure what we can do
with this one - perhaps we should ask them for a proposal since, to me 
anyway, I'm not sure what the issue is.

> 2.     Minor comments / requests for clarification:
> In Section 4.1 Subscribe, it would be helpful to clarify if there is
> any difference in behavior between a missing Filter element and a 
> Filter element that is present but empty.

Behavior for an empty Filter is pretty much Dialect specific.  Ignoring 
that the
default is XPath, its possible that some filter dialects will in fact 
filter
stuff even w/o any child elements of the Filter element.  Maybe even 
saying this
is what they're looking for?  Perhaps getting them to formalize an
issue and proposal would help make sure we address their concerns.

> In Section 4.1 Subscribe, the description of wse:Filter says that 
> the Event Source MUST generate a wse:EmptyFilter fault if it 
> receives a Subscribe request with a filter that will never evaluate 
> to true for the lifetime of the Subscription, but Section 6.11 
EmptyFilter
> says that the fault MAY be sent. This should be made consistent. A 
> similar inconsistency exists with the wse:UnusableEPR fault.

+1 - I think we should change the MAY to a MUST in section 6.11. I think
this is just a consistency issue and can be editorial if the WG is ok with 
it.

> In Section 4.4 Unsubscribe, the text references faults defined for 
> Renew, mentioning that they are also applicable to Unsubscribe. 
> However, the only fault defined in Renew is wse:UnableToRenew, which
> does not seem applicable to Unsubscribe. 

I think the latest editor's copy fixes this by talking about the soap
faults.

> In Section 4.4 Unsubscribe and Section 5 Notifications, the term 
> "subscribing event sink" is used several times. Should these be 
> replaced with the term "Subscriber" (defined in section 3.4 
> Terminology) to avoid confusion?

Fixed

> In Section 4.2 Renew and Section 4.4 Unsubscribe, the status of the 
> subscription after the failure of either request could be clarified 
> (e.g., that any existing subscription is unaffected).

+1 - we should clarify this.  In fact we should probably check this
for all specs in all fault conditions.  The state tables should help
with this too.

> In Section 5 Notifications: Uses of the XPath expression /s:
> Envelope/s:Body/wse:Subscribe/wse:NotifyTo/ should be replaced by 
> /s:Envelope/s:Body/wse:Subscribe/wse:Delivery/wse:NotifyTo/ (in two 
> instances).

Fixed.

-Doug