[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: NEW Issue: WS-C: Split out 007 c) -- Avoid normative statements onsameness of super- and sub-coordinator coordination types
Issue name -- WS-C: Split out 007 c) -- Avoid normative statements on sameness of super- and sub-coordinator coordination types PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. The issues coordinators will notify the list when that has occurred. Target document and draft: Protocol: Coord Artifact: spec Draft: Coord spec working draft uploaded 2005-12-02 Link to the document referenced: http://www.oasis-open.org/committees/download.php/15738/WS-Coordination-2005-11-22.pdf Section and PDF line number: Section 3 "Coordination Service", ll. 181-209 Issue type: Design / editorial Related issues: None Issue Description: This issue separates out sub-issue c) of Issue 007, which can be found here: http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200512/msg00059.html Avoid normative statements on sameness of super- and sub-coordinator coordination types. Issue Details: [This issue stems from Choreology Contribution issue TX-17.] The initial part of Section 3 (up to and inluding the diagram, Figure 2., on p. 10) uses an example to convey three things: a) the basic interactions of a registering application service and a Registration Service, and their relationship to Coordinators and Participants b) the notion of an interposed Coordinator, and c) some seemingly normative rules relating to how interposed coordination works. On the last point: There are two statements, which are too restrictive -- or perhaps which seem too restrictive because they are actually intended only as examples of one possible use of the protocol, but appear to have normative weight because there are no other statements at all in the specification about the behaviours being discussed. One of these statements is contained within the following call-out, which refers to the diagram. It is flagged with the inserted tags [Statement 1]. ll. 197-206 "3. App2 prefers CoordinatorB, so it uses CreateCoordinationContext with Ca as an input to interpose CoordinatorB. CoordinatorB creates its own CoordinationContext Cb that [Statement 1] contains the same activity identifier and coordination type as Ca but with its own Registration service RSb. There is a business need to combine coordination types in a transaction tree. But the second part of [Statement 1] implies that interposition can only occur between contexts of identical coordination types. As Tom Freund pointed out at the first F2F, the (unstated) design intent has been to permit combined-type tree creation. Proposed Resolution: Remove any normative statement relating to sameness of superior and sub-coordinator coordination types or protocols.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]