Issue 012 - WS-C: Make precise, permissive statement relating to methods of context propagation

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

This is hereby declared to be ws-tx Issue 012.

Please follow-up to this message or ensure the subject line starts Issue
012 - (ignoring Re:, [ws-tx] etc)

The Related Issues list has been updated to show the issue numbers.

 
Issue name -- WS-C: Make precise, permissive statement relating to 
 methods of context propagation.
 
Owner:  Alastair Green [mailto:alastair.green@choreology.com]

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 2 "Coordination Context", ll. 136-137, ll. 177-178

 
Issue type:  Editorial (minor)
 
 
Related issues:
 
 Issue 013 - WS-C: Remove fault 4.5 ContextRefused
 
 
Issue Description:
 
Means of context propagation by application cannot be prescribed by 
WS- Coordination.
 
 
Issue Details:

 ll. 136-137 contain the following sentence:
 
 "CoordinationContext elements are placed within application messages."
 
 ll. 177-178 read:
 
 "When an application propagates an activity using a coordination 
 service, applications MUST include a Coordination context in the 
 outgoing message."
 
These two statements are examples of how contexts may be communicated,
flowed or propagated. They are not the only examples. This wording is 
overly prescriptive. It is also a little imprecise.
 
For example: a context might have a static value, which is well-known,
and is supplied by publication which does not even involve computers.
Imagine a procurement 
transaction which 
occurs daily, but reuses the same
static context value. All registered suppliers are provided with a 
context value, which they receive by means
which are out-of-band to the distributed procurement system. The term 
"application message" tends to convey
"network message".
 
The general statement used elsewhere in the spec (ll. 26-27) is 
preferable:
 
 "Once a coordination context is acquired by an application, it is then 
 sent by whatever appropriate means to  another application."
 
The second aentence cited above (ll. 177-178) contains a very strong
(MUST) statement, whose meaning is not
very clear, in several respects.

  * An application does not "propagate an activity using a 
    coordination service", it propagates the context
    of an activity, which has been generated by a
    coordination service.  The coordination service is not the
    agent of propagation.

  * The term "outgoing message" is not defined. Outgoing from who to
    whom? There may not be an outgoing
    message in a given application protocol.
 
  * The term "include" is not well-defined. If an interoperability 
    spec makes a statement that something
    MUST be done then it usually implies that something
    predictable will 
    happen, either on the wire, or in
    terms of the actions or reactions of an actor in a 
    protocol. Here, the most we can say is that the context
    will have to arrive in the hands of a registering service 
   (requester) by some means.
 
The statement immediately following (ll. 179-180), relating to use of 
SOAP headers and the MustUnderstand flag, is precise and necessary.
 
 
Proposed Resolution:
 
Replace the paragraph (ll. 135-139), which reads:
 
 "The CoordinationContext is a Context type that is used to pass 
 Coordination information to parties involved in a coordination 
 service. CoordinationContext elements are placed within application 
 messages. Conveying a context on an application message is commonly 
 referred to as flowing the
 context. A CoordinationContext provides access to a coordination 
 registration service, a coordination
 type, and relevant extensions."
 
with the paragraph:
 
  "The CoordinationContext is used by applications to pass Coordination 
 information to parties involved in an  activity. CoordinationContext
elements are propagated to 
 parties which  may need to register Participants for
 the activity, using application-defined mechanisms -- e.g. 
 as a header element of a SOAP application message
 sent to such parties. (Conveying a context in an application 
 message is  commonly referred to as flowing the
 context.) A CoordinationContext provides access to a coordination 
 registration service, a coordination type, and relevant extensions."
 
Replace the statement (ll. 177-178)
 
 "When an application propagates an activity using a coordination 
 service, applications MUST include a Coordination context in the 
 outgoing message."
 
 with the following sentence:
 
 "An application may propagate a CoordinationContext element as a child
element 
 of the Body, or of the Header,  of an application SOAP message. [delete
new paragraph and run 
 on to next sentence]"