BurdettML comments

I've had a chance to look over David Burdett's WS Choreography spec 
(http://lists.w3.org/Archives/Public/public-ws-chor/2003Jun/0107.html) 
in more detail, and view it in a decent schema editor (which helps a lot).

I used a simple example choreography to see how this works.

In this choreography, there's a client and server role. The client has 
the ability to perform a "login" interaction with the server. Once 
logged in, he/she can perform one of five operations: query, add, 
modify, delete, and logout. The first four of these can be done in any 
order and multiple times. However, logout ends the choreography. (Sorry 
for the textual description: I don't have a good diagrammer for this).

In this example, we'd have to have at least three states: NotLoggedIn, 
LoggedIn, LoggedOut. The "login" interaction transitions betweens 
NotLoggedIn and LoggedIn. Any of query/add/modify/delete transition from 
LoggedIn to LoggedIn (in other words, loop). The "logout" interactions 
transitions from state LoggedIn to LoggedOut.

A couple of comments from looking at this use case:

1. As I mentioned at the F2F, IMO it would be more convenient if the 
states could be implicitly named. For example, I could do:

<InteractionDef name="DoLogin" fromRole="client" toRole="server"
messageFamily="Login">
</InteractionDef>
<InteractionDef name="DoLogout" fromRole="client" toRole="server"
messageFamily="Logout">
<InteractionEndStates fromState="DoLogin:end">
</InteractionDef>

Here, instead of using a state called "LoggedIn", I use the convention 
that state "DoLogin:end" means the end result of the DoLogin 
InteractionDef. I also omit the "toState" in the DoLogout InteractionDef 
- if I had to name it, I would use "DoLogout:end". And I didn't put any 
named InteractionEndStates in the DoLogin InteractionDef - again, the 
name is implicitly "DoLogin:end".

This is just shorthand, but IMO it also makes modelling tools simpler, 
because you can just connect interactions without having to name the 
connections - this is like UML, where you can name a relationship, but 
don't have to.

2. I notice that a Precondition on an Interaction element is mandatory. 
But in some (most?) cases, this is redundant, because you've already 
specified in the InteractionDef what the state prior to the interaction 
is. For example, in my simple use case, the "query" interaction would be 
modelled like this:

<InteractionDef name="DoQuery">
<InteractionEndStates fromState="DoLogin:end" toState="DoLogin:end">
</InteractionDef>

<Interaction name="DoQuery">
<Precondition condition="DoLogin:end">
</Interaction>

But you already know from the "fromState" attribute that "DoLogin:end" 
is a precondition for DoQuery. IMO in this simple case the precondition 
could/should be omitted. We do not need to specify that the client is 
not logged out, because DoLogout will be an end state for the 
choreography. I am assuming that reentering a choreography via other 
than a state state after an end state has been reached is an error.

Notice also that removing the precondition makes the Interaction itself 
redundant: you've already specified what you need in the InteractionDef.

Comments welcome .. it is still possible I am misunderstanding some of this.

--Jon

Received on Monday, 23 June 2003 18:49:44 UTC