OK, then I would propose
the following revised proposed resolution, which also corrects an error
("Coordination information " should read "Coordinator information").
Alastair
Revised Proposed Resolution for issue 012:
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 Coordinator
information to parties involved in an activity. 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 Header of an application SOAP message. [delete new
paragraph and run on to next sentence]"
Thomas Freund wrote:
Alastair,
Which was the point of my original email response ... i.e. drive to the
minimum (i.e. the absolute requirement), removing the additional text.
Regards
Tom
Alastair Green
<alastair.green@choreology.com>
Tom,
I think my proposed resolution accords with my summary. You could
remove the definition or commentary on the term "flow" but I was trying
to be a non-destructive "editor". My rewording removes the bits that
aren't a) and b) and sets the scene (more accurately, I think) for the
normative sentence on use of headers. You could do more Occam's razor,
and remove any reference to SOAP body too, if you really want to drive
to the minimum.
Alastair
Thomas Freund wrote:
Alastair,
I agree with your summary ... so does your comment 'which is already
said' mean the issue can be resolved leaving the document as-is (or are
you suggesting an additional rewording).
Regards
Tom
Alastair Green <alastair.green@choreology.com>
I think the point is to say
a) if the context info gets to a service by any means then this enables
the service to register participants (which is already said). This is
unavoidably true, and anything we say can't prohibit OOB communications
(e.g. via e-mail).
b) if the context is sent as a SOAP header element then it should do so
with mustUnderstand=true (which is already said). This is a legitimate
normative statement, helping to make precise usage in the 80-90th
percentile of use cases.
and then to avoid
making any other statements that might be interpreted as normative
(which is to say, any statement that doesn't include "for example",
"e.g.", and is especially true of any statement that shouts MUST).
Definitions of "flow", "propagate" and "infect" are not strictly
necessary.
Alastair
Peter Furniss wrote:
Are you
saying that an application that included the Coordination context as a
descendant element of a SOAP:Body, with the expectation that the
receiving service would register a Participant would NOT be
"propagating the activity" ? (this obviously would be equivalent to OTS
explicit propagation).
We aren't really specifying normative behaviour here, but rather giving
a (normative) definition of the term "propagate an activity". Recasting
the text as a definition, avoiding MUST may be helpful. Then it becomes
a distinct aspect of the issue of what behaviour we wish to include in
the definition, and what other, narrower or wider terms we wish to
define (e.g. "flowing a context", "infection")
Some candidate behaviours would be:
a) CoordinationContext as a soap header element in a request (including
one-way)
b) CoordinationContext as a soap header in a response
c) CoordinationContext as descendant element of soap body
d) CoordinationContext as field in non-soap communication sent at
coordinator-side initiative (e.g. multicast email)
e) CoordinationContext as field in non-soap communication (e.g. http
response)
f) communication of the semantics and content of CoordinationContext,
such that receiving party can send Register, but without actual
transmission of the normative CoordinationContext element.
I'd call all of those "propagating the activity". f) is clearly out of
our scope, but still legitimate and the Register/RegisterResponse
exchange and subsequent ws-tx protocol exchanges are in scope. And the
activity has clearly got propagated by some means.
We might want to say more about a) and b) as being typical, or even
give them a special name.
Peter
-----Original Message-----
From: Thomas Freund [mailto:tjfreund@us.ibm.com]
Sent: 13 December 2005 05:26
To: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 012
- WS-C: Make precise, permissive statement relating to methods of
context propagation
In general the specification defines
the normative behavior. When read the text from that perpective it
seems to read fine. The sentences might be tightened slightly (as per
the suggestions) to read "When an application propagates an activity,
it includes a Coordination context as a header element of a SOAP
application message" (11 177-178), i.e. retaining the semantics of the
normative behavior.
If the user choses to do something else they are operating outside the
scope of the document (and we certainly wouldn't want to include any
text to explain that).
Regards
Tom
"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]"
|