- From: Tony Fletcher <tony_fletcher@btopenworld.com>
- Date: Mon, 21 Mar 2005 15:38:00 -0000
- To: "'Gary Brown'" <gary@enigmatec.net>, "'Tony Fletcher'" <tony_fletcher@btopenworld.com>, <public-ws-chor@w3.org>
- Message-ID: <001301c52e2b$f7055380$6501a8c0@corp.choreology.com>
To Gary and others,
Comments below
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)
-----Original Message-----
From: Gary Brown [mailto:gary@enigmatec.net]
Sent: 21 March 2005 13:01
To: Tony Fletcher; public-ws-chor@w3.org
Subject: Re: toRole and fromRole names and type references and similar.
Hi Tony,
I still need a concrete example, as I don't see what is missing from the
current CDL spec. What you are suggesting seems to be adding more content to
a choreography definition without adding more value - I'm sorry but at the
moment I don't understand the problem you are trying to solve.
If you are objecting to the fact that we have role types, but no instances,
then possibly the problem is that we have "role types". Maybe we should just
have "roles" - i.e. a participant plays a set of roles, and a relationship
provides an association between two roles. Likewise, a relationship instead
of a relationshipType.
Yes that is exactly it. RoleTypes (and the other *Types) are useful in that
they give you one place to put the defintion material, but roleTypes do not
interact, in my understanding, roles do. So to use the same sort of example
that I used with Steve the other day:
participantType = DistributorType1
This particular type of participant has three roleTypes called
TalkToSupplier, TalkToBuyer and ReportToCustoms. The ReportToCustoms
roleTYpe is a standardised one common to many different paricipantType
definitions. The roleTypes define the allowed behaviours.
A participant of this participantType might be ACMEdistribution and it would
'comply' with its participantType definition by having roles
ACMETalkToSupplier, ACMETalkToBuyer and ACMEReportToCustoms (for imnstance -
I am not suggesting one has to stick to this way of naming things!). It is
these roles that would be shown as interactiong with other roles in a
chregraphy desvcription. That same chreography description might have a
second participant of the same participantType called ABCdistribution and it
would have roles ABCTalkToSupplier, ABCTalkToBuyer and ABCReportToCustoms
[Perhaps I should not complicate things further at this stage which is why I
am putting this bit in square brackets - it means I will quite understand if
people say we should ignore. In addtion I think we should allow a
participantType definition to say that some of its roleTypes are optioanl
for a participant that complies with this participantType to support. So in
the above example the participantType DistributorType1 could include an
optional roleType TalktoOtherDistributor which may not be used in some
chreographies but in othres would allow ABCdistribution to request parts
from ACMEdistribution so that it could make up an order - for instance.]
Hope it is clear now what I am driving at.
Regards
Gary
----- Original Message -----
From: Tony Fletcher <mailto:tony_fletcher@btopenworld.com>
To: 'Gary Brown' <mailto:gary@enigmatec.net> ; public-ws-chor@w3.org
Sent: Monday, March 21, 2005 12:46 PM
Subject: RE: toRole and fromRole names and type references and similar.
Dear Gary,
Thank you for your response. The intent was not role instances but rather
instances of roleTypes - which is a role!
That is the point I am making. At present we set up the participantType,
roleType and ChannelType definitions, but then each time we use a role we
have to give it a name and say what type it is. If you look towards the
bottom of my mail you will see I have suggested adding a roleAssignments
element where one could say what roles the choreography used give them names
and say what type they were and then we could just use the role name and
omit the type reference elsewhere.
<roleAssignments name="ncname" ">
<roleAssignment role name="ncname" roleType="qname" />+
</roleAssignments>
Maybe even better would be to have an element where one assigned a name to a
participant and said what type it was and gave names to each role in that
participant - we define participantTypes at present but never seem to use
participants (of a given type).
So we would then have:
<participantType name="ncname">
<roleType typeRef="qname" />+
</participantType>
and something like
<participant name="ncname" typeRef="qname">
<role name="ncname" typeRef="qname" />+
</participantType>
where the typeRef of the participant needs to match an 'ncname' of a
participantType and the typeRef (s) of the role(s) need to match the
corresponding 'ncname'(s) of a roleType contained in that participantType.
Best Regards Tony
A M Fletcher
Home: 35, Wimborne Avenue, IPSWICH IP3 8QW
Tel: +44 (0) 1473 729537 Mobile: +44 (0) 7801 948219
amfletcher@iee.org (also tony_fletcher@btopenworld.com)
-----Original Message-----
From: Gary Brown [mailto:gary@enigmatec.net]
Sent: 21 March 2005 08:57
To: Tony Fletcher; public-ws-chor@w3.org
Subject: Re: toRole and fromRole names and type references and similar.
Hi Tony,
I am not sure why we need the name and type reference, can you give a
concrete example? As we don't have the concept of role instances, I would
assume that a single attribute (whether called name or type ref) would be
sufficient.
Regards
Gary
----- Original Message -----
From: Tony Fletcher <mailto:tony_fletcher@btopenworld.com>
To: public-ws-chor@w3.org
Sent: Saturday, March 19, 2005 11:04 PM
Subject: toRole and fromRole names and type references and similar.
Dear Colleagues,
In trying to sort out roletypes from roles for issues 1018 and 1018
I wonder if we should not change the interaction syntax defined in 2.5.2.3
from
Interaction Syntax
The syntax of the <emph>interaction</emph> construct is:
<interaction name="ncname"
channelVariable="qname"
operation="ncname"
align="true"|"false"?
initiate="true"|"false"? >
<participate relationshipType="qname"
fromRole="qname" toRole="qname" />
<exchange name="ncname"
informationType="qname"?|channelType="qname"?
action="request"|"respond" >
<send variable="XPath-expression"?
recordReference="list of ncname"?
causeException="true"|"false"? />
<receive variable="XPath-expression"?
recordReference="list of ncname"?
causeException="true"|"false"? />
</exchange>*
<timeout time-to-complete="XPath-expression"
fromRoleRecordReference="list of ncname"?
toRoleRecordReference="list of ncname"? />?
<record name="ncname"
when="before"|"after"|"timeout"
causeException="true"|"false"? >
<source variable="XPath-expression"? | expression="Xpath-expression"?
/>
<target variable="XPath-expression" />
</record>*
</interaction>
to
Interaction Syntax
The syntax of the <emph>interaction</emph> construct is:
<interaction name="ncname"
channelVariable="qname"
operation="ncname"
align="true"|"false"?
initiate="true"|"false"? >
<participate relationshipType="qname"
fromRole="ncnameqname" fromRoleType="qname"
toRole="ncnameqname" toRoleType="qname"
/>
<exchange name="ncname"
informationType="qname"?|channelType="qname"?
action="request"|"respond" >
<send variable="XPath-expression"?
recordReference="list of ncname"?
causeException="true"|"false"? />
<receive variable="XPath-expression"?
recordReference="list of ncname"?
causeException="true"|"false"? />
</exchange>*
<timeout time-to-complete="XPath-expression"
fromRoleRecordReference="list of ncname"?
toRoleRecordReference="list of ncname"? />?
<record name="ncname"
when="before"|"after"|"timeout"
causeException="true"|"false"? >
<source variable="XPath-expression"? | expression="Xpath-expression"?
/>
<target variable="XPath-expression" />
</record>*
</interaction>
That is that we should give the roles names as well as showing what type the
correspond to.
Similarly for perform. Should we not change
<perform choreographyName="qname"
choreographyInstanceId="XPath-expression"? >
<bind name="ncname">
<this variable="XPath-expression" role="qname"/>
<free variable="XPath-expression" role="qname"/>
</bind>*
Choreography-Notation?
</perform>
to
<perform choreographyName="qname"
choreographyInstanceId="XPath-expression"? >
<bind name="ncname">
<this variable="XPath-expression" role="ncname" roleTypeRef="qname"/>
<free variable="XPath-expression" role="ncname" roleTypeRef="qname"/>
</bind>*
Choreography-Notation?
</perform>
I propose to change the syntax of assign from
<assign roleType="qname">
<copy name="ncname" causeException="true"|"false"? >
<source variable="XPath-expression"?|expression="Xpath-expression"?
/>
<target variable="XPath-expression" />
</copy>+
</assign>
to
<assign role="ncname" roleType="qname">
<copy name="ncname" causeException="true"|"false"? >
<source variable="XPath-expression"?|expression="Xpath-expression"?
/>
<target variable="XPath-expression" />
</copy>+
</assign>
I propose to change the syntax for noAction from
<noAction roleType="qname? />
to
<noAction role="ncname"? roleType="qname"? />
although having one place in a choreography where we say what roles are
involved and what the type of each role is would probably be better then
doing it in several places like this and having to check consistency.
Perhaps something like
<roleAssignments name="ncname" ">
<roleAssignment role name="ncname" roleType="qname" />+
</roleAssignments>
then noAction would become
<noAction role="ncname"? />
and similar elsewhere.
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)
Received on Monday, 21 March 2005 15:38:43 UTC