ws-chor 12/8/2004: My Comments through 2.5.2

I was still somewhat in transit last evening in Paris during CDL call. Here are my comments:

page 21
From: "available to Roles within a Choreography, when the Variables contain
information that is common knowledge."
To: "available to Roles within a Choreography, when the Variables contain
information that is visible."

page 22
Suggest you more clearly differentiate local manipulation of variable information and that which is visible across Roles within a Choreography (first paragraph).

page 23
From: "...free when set to "false" describes that a Variable is defined in this Choreography."
To: "...free when set to "false" describes that a Variable is defined in this Choreography and is not visible to an enclosed choreography" (or performed?)

page 24
Question: I know we decided to punt on time synchronization but could it not be an available synchronization point by allowing one Role to
query another Role in a choreography on time (as a function to support synchronization)?

Section 2.4.3.1
Examples would make these easier to understand and use.

page 28
Question: I was under the impression there could be more than one finalizer block.
Ref: "A Choreography can also be coordinated. Choreography Coordination
guarantees that all involved Roles agree on how the Choreography ended. That
is, if the Choreography completed successfully or suffered an Exception
the Choreography completed successfully and Finalizer Block(s) were in
all Roles have the same Finalizer Block enabled."
See proposal 3 from Choreology re: multiple finalizers and final paragraph
in Section 2.4.5.

page 29
Question: On isolation
What is meant by "sibling Choreographies"? Is this a performed
choreography, non-root package used? Are these just coordinated choreographies? Please clarify.

Section 2.4.7 page 33
Should specify that a choreography must be included before it can be used. Although this is specified on page 53, it should also be identified here.

page 34
From: "If the Exception block is not present, the Choreography implicitly
enters the Closed State."
To: ""If the Exception block is not present, the Choreography implicitly
enters the Closed State when the Default Exception Work Unit is enabled."

Where would the exception be or how would it precipitate itself
if an exception block was not defined? Is this implicitly via the default Exception Work Unit (page 36)? Should this not be explicit in the preceding text? The same question applies later in Section 2.4.8 on finalizers. How
do you enter either an exception or a finalizer if either the Exception
Block is undefine or the Finalizer Block is not enabled?

page 37
From: "One "undo" Finalizer Block along with a "close" Finalizer Block to signal
that the "undo" Finalizer Block is no longer able to be enabled, that is, the
Choreography is now closed."
To: "One "undo" Finalizer Block along with a "close" Finalizer Block to signal
that the "undo" Finalizer Block is enabled, that is, the Choreography is now closed."
Otherwise, if the completed state has been realized and the choreography completed
unsuccessfully where the enclosed choreographies were closed, the Finalizer
Block will not be installed."

Reasoning is it is counterintuition to have the undo specify the choreography is no 
longer available for undo. You have specified the case where enclosed choreographies
could be completed by directon of an enclosing choreography. If this is the case you
cite, please explain in the corresponding section referenced above or use my tentative text to clarify.

page 37
Question: What is the reasoning for the restriction that no finalizer block may be in a root choreography (even global)?

page 47
Why restriction on a request not having causeException? For example, a request may not be valid in the the overall choreography and an exception could occur on the request, or example because the party that sent the request
is not authorized to do so. If this restriction applies, you should have a fixed value of 'true' on the request for causeException on the applicable send
(reference page 44, Section 2.5.2.3).

page 47
Comment: Align semantics infer that align=false only applies when variables are used. If correct, suggest this be explicitly stated rather than inferred.

page 49
Comment: Is it always true that if a record completes unsuccessfully, that an interaction fails? Take an order
acknowledgement. The successful receipt of an acknowledgement may be separate from its recording. Do we fail the
interaction because the recording did not take place although the acknowledgement receipt did occur as specified? I realize this is not
a black-white case so I can understand if you choose the more restrictive semantics. However, in the real world
the interaction and exchange of messages, and their receipt, may indeed be separate from the recording of that 
receipt.

Received on Wednesday, 8 December 2004 14:58:06 UTC