Issue 020 - WS-C: Split out 002 c) -- Avoid normative statements on sameness of super- and sub-coordinator coordination types

["Peter Furniss" <peter.furniss@choreology.com>]

This is hereby identified as ws-tx issue 020.

Please follow up to this message or otherwise ensure your subject line
starts "Issue 020 - " 
  (after any Re:, [ws-tx] etc)

Alastair pointed out his original message referred to 007 when it should
have said 002. I have corrected the misreferences below.

==============================================

Issue name -- WS-C: Split out 002 c) -- Avoid normative statements on 
sameness of super- and sub-coordinator coordination types

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:

002, 018, 019, 021


Issue Description:

This issue separates out sub-issue c) of Issue 002, 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.