Unofficial minutes from conf call 30th March 2004

WS Choreography WG

Unofficial minutes from conference call on 30th March 2004

Scribed by SRT

 

Comment SS1 (line 204-206): It would be most helpful if some examples 
were provided. I presume that WS-CAF is one example that would fit the 
bill so listing some examples would help clarify.

Response SS1: Should try to align with WSA so that the diagram is 
aligned with the WSA layers with any further layers that we need to 
add.

 

Comment SS2 (line 223): I’m afraid the colour scheme and shadows on the 
diagram make it hard to read. It would be better to have a muted colour 
scheme with black text and no shading.

Response SS2: See SS1 above



 

Comment SS3 (line 259): The use of the term complementary appears to be 
significant and yet is never described (I think). Can you provide a 
clear and precise definition of what it means?

Response SS3: Complementary behavior is really the notion of an interact

 

Comment SS4 (line 277): The Choreo GUI bit need tidying up on the 
diagram as the WS-CDL is lost on my version.

Response SS4: Editing instruction

 

Comment SS5 (line 296): I’m a bit worried abou this being very 
restrictive. When the term “synchronized” is used in this way it 
appears mandatory rather than optional.

Response SS5: Done - it's gone.

 

Comment SS6 (line 315-321): Might be a good idea to define observable 
and how it applies to state, exchange of information and so on. If this 
was done earlier on then these terms could loose their “observable” 
prefix.

Response SS6: Need general statement about observability and then bind 
it to relevant concepts



Comment SS7 (line 364): The notion of a collaboration type is, I think, 
not defined and so needs a precise defintion of what it is.

Response SS7: Gone.

 

Comment SS8 (line 416-427): I see this as a binding and not a concrete 
choreography. I would rather, as I think we agreed at the F2F, rename 
the conceret choreography as a binding and adjust everything 
accordingly

Response SS8: Skipped



Comment SS9 (line 527): Question: Can the additional information about 
usage and type be used to check for liveness properties. It seems to me 
that it has this benefit.

Response SS9: Yes



Comment SS10 (line 559): This makes it well suited to protocols such as 
FIXML, SWIFT, TWIST and fpML since they are not based on WSDL at this 
point.

Response SS10: Note message types do not exist anywhere and the 
document has been updated to reflect WSDL2.0. Pointing to a type is 
pointing to some type system that you can leverage/bind to.



Comment SS11 (line 573-579): This would seem very useful for skeleton 
generation. Would that be correct?

 

Comment SS12 (line 583-595): As above.

Response SS11 and SS12: Kind of correct because it is not just for 
executable end points but can be used in a more computable contract.



Comment SS13 (line 679-682): Confusing as to what is a root and what is 
an iniator. In particular a bit confusing when you get to the bit that 
says you can have multiple choreographies that can initiate and yet 
here the implication is one. Can you make it clearer what is meant by a 
root choreography as distinguished from a choreography that can be an 
initiator?

Response SS13: This is something that we need to discuss in a conf call.



Comment SS14 (line 706-708): Does this mean that exceptional behaviour 
is defined at the workunit level and not at the interact level?

Response SS14: Yes at the workunit level



Comment SS15 (line 765-777): From the description it looks like you 
don’t have much integration to do. Just reference the appropriate 
choreographies and go. This doesn’t sound as if it is the case. So my 
comment is that this needs to be made little more explicit like “adding 
the appropriate channel and state variables to allow them to work 
together correctly”. Or perhaps I am missing something? I would have 
though you need at least a line that checks the exit/termination state 
of one because the other is dependent on it.

Response SS15: David explained how you do it and made it clear how easy 
it was to do.



Comment SS16 (line 835-836): How is an interaction failure, as 
described above, different to a timeout? And how is such an interaction 
failure observed?

Response SS16: They are different. Interaction failure may be a 
specific observable message that was sent, perhaps security failure, 
and results in the expected message not being sent. Timeout is no 
message after an amount of time.



Comment SS17 (line 858-859): I really don’t understand what “refined 
mechanism” means. Could you clarify?

Response SS17: “refined” is removed.



 

 

ACTION: SRT to raise SS11,SS12 as issue and get airtime on conf call.



 

Received on Wednesday, 31 March 2004 05:53:05 UTC