- From: Tony Fletcher <tony_fletcher@btopenworld.com>
- Date: Tue, 22 Mar 2005 14:54:20 -0000
- To: "'Martin Chapman'" <martin.chapman@oracle.com>, "'Gary Brown'" <gary@enigmatec.net>, <public-ws-chor@w3.org>
- Message-ID: <002501c52eef$085dbeb0$530a0a0a@corp.choreology.com>
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