Comments on CDL 1.0 (for last call)

Kohei Honda
January, 2005.

Note:

(1) Small issues (readability, ambiguity in 
    punctuation, etc.) are not mentioned.

(2) Details of some of the technical points 
    will be later augmented.

For later reference, I put * to what can be important 
technically.

2.3.4, Overall.

When 

  "being the target of an information exchange" 

is first used, it is better to augment 

   (i.e. either a receiver of a request action
   or a sender of a reply action)

or something like this.

2.3.4. Para "The value of Variables:".

In the first bullet, 

   Are available to Roles within a Choreography, when the Variables
   contain information that is common knowledge.

is vague. It may be augmented as (for example)

    "as explicitly specified in Variable Definition, given later"

Or does it mean there is some special common variables? (the
sentence reads like that.)

* 2.3.4. The last two paragraphs, about "roleType" attribute.

It is not clear 

  roleTypes attribute 

is solely for visibility or ownership (can be altered etc.). Simply
put, 

  Does a variable always belong to a unique role type in a single
  Choreography?

A related question:

  If there are two role types specified in this attribute,
  can both alter the content of this variable?

2.4.4. The first para.

Can be made clearer by saying:

   ... in that Variables contain values which MAY be 
   populated or assigned as the result of actions or
   events within a Choreography Lifeline whereas..

In other words, a token denotes a value, while a variable refers
to a container of a value, which in turn defines its state.

2.4.5. The second para, last sentence.

>From the second to last sentence, if the root choreography 
can only be the sole top-level choreo, then the last
sentence seems redundant. 

Also the term "enabled" has not been defined at this point.

*2.4.6. Overall on workunits (1).

To have a clear semantics of guards, it is better to specify that the 
evaluation of the guard expression is done in a fixed order (may be
better to specify this explicitly in the CDL-function section or 
in an "expression" section). 

Reasons: If not, prediction of behaviours become hard; flow check 
         becomes hard; can lead to livelock/deadlock easily.

*2.4.6. Overall on workunits (2).

It is recommended that workunit construct is decomposed into "loop", 
"conditional" and "workunit", the last having the blocking guard.
Alternatively "loop" will be added as an additional construct.

Details are elsewhere. 

*2.4.7. Choreography Life-line, the eighth para.

The operational behaviour involving "complete condition" is not clear.
Is the condition evaluated lock-step, at each action? It at least 
needs transaction semantics for all related variables.

Suppose a variable V should have the value [not W]. Suppose W should have
the value [not V]. We never know it is true or not, especially if they
are situated in different roles.

As a possible way to record this point, one may augment the 3rd sentence
as:

  "A complete condition MUST be possible to be matched in all Roles that
   participate in the Choreography, for which we assume a consistent 
   global view is maintained."

This is a very useful feature, I can see, but I feel like recording a bit 
of subtlety inside the spec.

2.4.8--2.4.10. Exception-Finalization.

Cannot see why finalizer blocks etc. should not combine in them corresponding 
workunits --- the latter seem rather redundant in semantics (and examples). 
As far as I read, no repetition etc. seems possible in these blocks.

2.5.2.1. Interaction Based Information Alignment
2.5.2.3, Interaction Syntax, exchange element. 

The last paragraph of 2.5.2.1 may be too conceptual. It may be augmented 
as:

  ... In other words, after each action, its state is immediately shared by
  the other party through appropriate variables, so that both act on the 
  basis of shared understanding.

In 2.5.2.3, the illustration of "align" attribute is (in addition to be 
repetitive in a non-enlightening way) not clear. Concrete description 
based on shared variables (as above) may clarify, in addition to taking 
off repetition.

2.5.2.3. Interaction Syntax, record element.

The first bullet point under "if the align attribute is set to "true"":

 "Both parties know..." 

What does "know" mean in this context? Also a phrase, "the availability of the 
creation ..." is used, but "creation" is redundant and is not semantically
relevant.

2.5.4. Assigning Variables, the second para.

One may augment it with a possible cause of exception (such as unavailability
of referred tokens etc.).

[end]