RE: Revised TWIST Example XML

Dear Mayilraj,
 
Greetings, hope all is well with you.  My thoughts embedded below, but Steve
may have his own responses.
 
Looking for help from Steve or Nick or someone on your second question.
 
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@talk21.com  &
tony_fletcher@btopenworld.com)
 

-----Original Message-----
From: Mayilraj Krishnan [mailto:mkrishna@cisco.com] 
Sent: 13 June 2004 06:41
To: Tony Fletcher; public-ws-chor@w3.org
Subject: Re: Revised TWIST Example XML


Steve/Tony
I have few questions.. I understand this is not completed example.
(1) What is the motivation to declare the "dummy" behavior  CreditReqDummy,
CreditRespDummy in
CreditReqCreditResp relationship? 
<Tony>
In 

<relationship name="CreditReqCreditResp">

<role type="CreditReqRole" behavior="CreditReqDummy"/>

<role type="CreditRespRole" behavior="CreditRespDummy"/>

</relationship>

 I think it is because behaviour is currently a required attribute so you
have to put some valid NCName there and Steve chose those names as obvious
place holders that could be revised  later  to link to  WSDL files. 
 
 
(2) Why do we have to define interactions (priceRequest) for multiple
sellers in CDL?
Thought CDL provides some "repeat" construct for the activities.
This has been captured in the requirements document as well.
(Refer section 3.1.2.2) 
<Tony>  Section 3.1.2.2 does not exist in the latest version of the
specification dated 27 April 2004 (it would be in the middle of the yet to
be filled in example section.
In general I think we should capture CDL fragments for the primer and show
how you can use certain patterns and build up what you want to achieve from
the simple to the more complex.  So perhaps the idea here was to show how
you could do a small number of similar interactions by hand coding each.
Steve has used the parallel construct of section 2.5.1.2 to show how this
can be done in parallel rather than just sequentially (which in this case
could be seen as favouring one seller over another).
I agree that we then need to go on a show how you could do the same for N
sellers where N and the actual sellers involved can change each time the
choreography is run - i.e. is fixed at run time.  This needs a "while" or
"for loop" type of construct.
 
I have not discovered how to do this yet - but you should be correct that it
is already there in some form - perhaps Steve or Nick can help us here. 

Thanks
Mayilraj
At 06:30 PM 6/11/2004 +0100, Tony Fletcher wrote:


Dear Colleagues,
 
I have now been able to edit Steve's version of the TWIST Example so that it
passes schema validation in both XMLSpy 2004 and also the slightly older
version of Sonic Stylus Studio that was made available to us last year.
This does not, of course mean that it is now complete or semantically
correct - only that it is syntactically correct for the moment!!
 
My intent has only been to do the minimum necessary changes to make it
schema valid at the moment and not to actually improve the description in
terms of covering more of the example.
 
Please find attached the revised XML for the TWIST example I have generated
and also the schema I have validated it against (extracted straight from the
HTML version of the spec and not changed at all I hope).
 
I am not sure that I can remember all the changes I have made but here are
the ones I can remember (doing a diff between these files and Steve's
original will reveal all!)
 
<role> was out of sequence - fixed by moving <participant> to its proper
place.  The package element contains a sequence - and you have to stick to
the sequence the schema lays down to be schema valid (I think we could move
to using <all> rather than <sequence> if we thought the freedom to put the
child elements in any order was useful, but I am not convinced we need to do
that and am not raising as an issue).
 
Some name attributes need to be qualified names
 
Some type attributes in Steve's original should have been name attributes
 
The name attribute on interaction is mandatory.
 
A choreography element must have a relationship element and at least one
activity, so on the last two choreographies that have yet to be done I added
a relationship with its name attribute (but not necessarily correct values!)
and <noaction> element as a temporary measure to get to schema valid.
 
Last thing that seems to be tool dependent:  XMLSpy was fine with name=""
(that is provide the attribute but with a null value).  Stylus Studio did
not like that and demanded a proper Qname or NCName - so I have added fairly
arbitrary names in places - I am sure someone else will soon do better.
 
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   Fax: +44 (0) 870 7390077  Mobile: +44 (0) 7801
948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)