Some comments on the WS-CDL Primer v0.2 (17 March 05)

Dear Steve,
Well Done - I think this is a good start.  Here are a few comments, which
are intended to encourage you and help things on their way - I know there is
still much to do.
 
Editorials:
Section 1.2 sentence inside[] BPEL4WS --> WS-BPEL
Section 2.1 2nd para involves --> involve
                 last para  'What WS-CDL provides in an unambiguous ...'
-->  'What WS-CDL provides is an unambiguous ...'   and ensure  --> ensures
Section 2.2  I would not use the word guarantee personally.  As standards
specifiers we can not guarantee that any implementation of the spec or of a
description conforming to the spec is conformant and will remain so!
I agree that less testing time should be a tangible benefit to be gained
from using CDL.
Section 2.3 'Adding Non-Observable Conditionals makes it is possible' -->
'Adding Non-Observable Conditionals makes it possible'
(Not commented on the parts that you have and therefore that you are likely
to change)
'By this we mean that none of roles' --> 'By this we mean that none of the
roles'
Section 3.1 'Because the buyers' --> 'Because the buyer's'
Section 3.2.3  'In this context a token defines an alias to the web service
so that we can treat refer to it by a shorter name.'  --> 'In this context a
token defines an alias to the web service so that we can refer to it by a
shorter name.'
 
Not completely editorial
Section 3.1  'We have used a heavily annotated form of sequence diagram to
describe the business collaboration protocol necessary for the buyer,
seller, credit agency and shipper to go about their business.'  --> 'We have
had to use a heavily annotated form of sequence diagram, and several of
them, to describe the business collaboration protocol necessary for the
buyer, seller, credit agency and shipper to go about their business.'
(Making the point that in general many sequence diagrams are required to
fully specify a protocol, and Chore description should be able to capture
them all.)
 
Section 3.2  Up to this point the primer has talked about participants,
roles, channels and so on, which I think is probably correct, but in this
section we suddenly find roletype used in the XML and
fromRole="BuyerRoleType"
As a group we need to decide whether the primer is correct in stating that
that the description is written in terms of roles, participants, channels,
etc., should at some point (perhaps before we get to what is currently 3.2),
explain that roletype is used to define the behaviour of a type of role and
that is a useful economy if there are several roles conforming to that type
used in a description - and similarly for participants, channels and so on.
The alternative I guess would be to say that a choreo description is written
purely in terms of types and each time it is 'enacted' a role of the
specified type is used, a channel of the specified type is used and so on.
We need to agree how we use 'things' and types of 'things', and make sure
that the specification is self consistent and that the primer explains the
way of using types and instances of those types.
 
Section 3.2 and beyond:  The description element is given a type attribute
value of 'description'  (<description type="description">
Unfortunately this is not one of the currently allowed values for this type
attribute which is an enumeration type with the permitted values of
"documentation", "reference" and "semantics", so should either use one of
these values in the primer, or get the spec changed to include "description"
(or allow any string value perhaps).
 
 
Best Regards     Tony
A M Fletcher
 
Cohesions  (TM)
 
Business transaction management software for application coordination
www.choreology.com <http://www.choreology.com/> 
 
Choreology Ltd., 68 Lombard Street, London EC3V 9LJ     UK
Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)