[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WS-DD comments on WS-Eventing WD-ws-eventing-20090924
Dear colleagues in W3C WS-RA WG: The OASIS Web Services Discovery and Web Services Devices Profile (WS-DD) Technical Committee reviewed the draft WS-Eventing, WS-MetadataExchange, and WS-Transfer specifications as requested in your email on September 26 (we did not review the other specifications because they are not referenced in DPWS). As a result of this review, we submit to you the following substantive comment and several minor editorial/clarification comments on WS-Eventing: 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 at runtime. 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. 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. 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. 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? 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). 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). Thank you very much for the opportunity to participate in the preview of the Last Call drafts. Best regards, Toby Nixon Alain Regnier Co-Chairs, OASIS WS-DD TC From: Bob Freund [mailto:bob.freund@hitachisoftware.com] Dear WS-RA Reviewers, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]