RE: toRole and fromRole names and type references and similar.

Dear Martin,
 
I understand that we use channels as the means of representing the
communication 'pipe' between two roles, but not that they are roles - if
this is to be the case we need to make this much clearer.
 
By the way, I am assuming that when we say 'type' we really mean 'type'.  It
maybe that in some places we are overusing the this word type in places we
we actually mean the a thing itself rather than the type of a thing - this
is what I am trying to clarify / sort out for myself and hopefully hence
everyone else.
 
We need to compare what you are saying below with what the spec currently
actually says.
 
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: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
On Behalf Of Martin Chapman
Sent: 21 March 2005 16:54
To: 'Tony Fletcher'; 'Gary Brown'; public-ws-chor@w3.org
Subject: RE: toRole and fromRole names and type references and similar.


Tony,
 
Roles manifest themselves in the current spec as channels. Rather than talk
about a single role instance of a role type we talk about access points to
the role. Hence the role doesn't have to be explicit, and is really only a
deployment time concept.
 
For example suppose we have the RoleType BuyerType. Rather than talk about a
Buyer such as Tesco, Sainsbury etc, we talk about channels to buyer:
tescochan1, sainsburychan2 for example. This is because each role may need
multiple access points for different participants, so the role becomes
superfluous at this level of specification.
 
Martin.
 
 
 

-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
On Behalf Of Tony Fletcher
Sent: 21 March 2005 15:38
To: 'Gary Brown'; 'Tony Fletcher'; public-ws-chor@w3.org
Subject: RE: toRole and fromRole names and type references and similar.


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 Tuesday, 22 March 2005 15:03:29 UTC