This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
> Section 3.5.6: > Monica. Please specify what specifications of which you make > reference. An agreement protocol doesn't exist in web services, unless > this is the > infrastructure coordination/transactional evolving capabilities. Is > this the meaning of this statement? > David. Perhaps a "common understanding" would be better than > "agreement" as in "the Roles in the Choreography have a common > understanding of the outcome". > Monica. If this relates to WS-CAF, suggest this be a team discussion > item for specific reference (Note: Do we approach by requirement or by > specification?). Implicit dependencies exist. Should we pose these in > a separate document or section of this overview? > David. I agree that dependencies exist and need to be discussed.
After further review and discussion, a short list of specifications have been identified as either critical or optional to ws-chor: --> Critical * BPEL * WSDL * XPath/XQuery --> Optional * BPMN * BPSS * WS-Coordination * WS-Reliability * WS-Addressing There are others which I am continuing to investigate and will discuss. I would like to enter the above critical and optional dependencies as a part of a general discussion point on ws-chor dependencies. The BPEL, WSDL and XPath dependencies are critical to ws-chor and we will need to resolve which versions we will support in 1.0. The BPMN, BPSS and WS-Coordination are less critical yet may impact ws-chor and thus need to be discussed. I will present more details on these in this bug description.
I believe we've addressed - at least conditionally - the BPEL, WSDL and by extension the XPath/XQuery dependencies. As to the rest, Monica has commented as follows: - WS-Coordination WS-Coordination Framework, WS-BTP are open and emerging standards. WS-C is proprietary currently. - WS-Reliability Same holds true here (WS-ReliableMessaging is proprietary). - WS-Addressing WS-MessageDelivery also applies. At least three groups, WS-CAF, WS-Reliability and WS-BPEL are working on an abstract content model that abstracts away from such a dependency (i.e. a proprietary specification - lock in avoided as well). We definitely need to ensure that we conform to open standards. I propose that as far as WS-Reliability and WS-Addressing are concerned, we hold to the WS-CAF/WS-Reliability/WS-BPEL abstract content model (vs. WS-ReliableMessaging and WS-MessageDelivery). I propose that as far as WS-Coordination is concerned, we hold to the WS-Coordination Framework and WS-BTP standards (vs. WS-C).
*** Bug 557 has been marked as a duplicate of this bug. ***
SRT - Was talked about at the F2F. RECOMMENDATION - Due to Charlton's proposals at the F2F this should be marked as CLOSE FIXED.