Re: Updated exit examples bundle and notes from 2007-Jan-23 telcon

Attached is a new archive of the exit examples. The 'update' directory has been removed and the examples therein replaced with the updated versions from Gary and myself. The updated Issues.txt is included.
The structure is as follows:
- 'examples' containing all examples
- 'implemented' folder containing the examples that are implemented and working in pi4soa
- 'notimplemented' folder containing examples that either relate to features that are not implemented in pi4soa (alignment and coordinated choreographies) or at risk features (i.e. the initiate flag).

-Charlton.
-- 
charlton_b@mac.com
+1.650.222.6507 m
+1.415.692.5396 v
 
On Wednesday, January 24, 2007, at 12:11AM, "Charlton Barreto" <charlton_b@mac.com> wrote:
>As per my AI I have rebundled the exit examples 
>- dropping the eight examples noted in the telcon.
>- changing the questions directory in the archive to "update" and placing the four examples to be updated therein
>- updating the Issues.txt to reflect these notes.
>
>I've included the notes from the telcon below.
>
>-Charlton.
>--
>charlton_b@mac.com
>+1.650.222.6507 m
>+1.415.692.5396 v
>
>----- Original Message -----
>
>assign-with-causeexception:
>
>[gb] There is alot of unnecessary interactions, workunits etc just to test
>an assignment. Also the variable associated with the assignment is
>not initialized anywhere, so this would result in an exception before
>the 'causeException' executes.
>
>CHANGES: Simplified to two req/resp interactions with assignment in
>between that causes an exception, and therefore the second interaction
>should not occur.
>
>[cbb] The initialization was missed by mistake and the correction seems fine. 
>Thanks. The simplification is fine as it makes the example more clear. 
>
>
>assign-without-causeexception:
>
>[gb] Same problems as above.
>
>CHANGES: Three interactions - rfq, update and accept. The update is
>conditional on the assignment of a boolean that occurs after the rfq
>interaction, which demonstrates that the assignment must have
>occurred on both endpoints.
>
>[cbb] Same as above.
>
>
>channeltypes-with-action:
>[gb] Just seems to be related to syntax - the example does not test any runtime semantics.
>Should this place a restriction on the channel type with the intention of
>a validating parser detecting an message being sent? But didn't think this
>was the aim of the exit examples. In which case this example may not be required?
>
>[cbb] We want to be able to test runtime as well as validation (where not overlapping with runtime). I think this is relevant for the latter and for illustrating how to use the feature. 
>[cbb1] Drop this example.
>
>channeltypes-with-identity*:
>
>[gb] These choreographies only do a single interaction. To test whether an
>endpoint is correctly associating messages to channel instances through identity,
>it would be necessary to do multiple interactions, potentially on different channel
>instances, identified by different identities which are chained.
>
>    channeltypes-with-identity.cdl - this is just the same as the primary identity case?
>                    - as primary is the default identity usage
>                    - so recommend deleting in favour of the primary identity example
>
>[cbb] This does overlap with the primary identity case, especially as primary is the default. I agree with removing this example.
>[cbb1] Drop this example.
>
>CHANGES: Have removed channel passing channel as this is not relevant to the identity
>examples. Where appropriate have added second channel for the purpose of demonstrating
>chaining of messages across channel instances.
>
>[cbb] The changes are fine. 
>
>
>channeltypes-without-attributes:
>
>[gb] what runtime behaviour is this testing?
>
>[cbb] This is providing a "basic" test case for channel without any constraints. As is, this tests syntax/validation rather than runtime behaviour. 
>[cbb1] Update by reducing to simple one-interaction request-response choreo.
>
>channeltypes-with-passing:
>
>[gb] Needs to have interactions on passed channel to demonstrate correct passing.
>
>[cbb1] This appears to be fine. 
>
>
>channeltypes-with-usage*:
>
>[gb] The usage property is primarily for guidance to the model checking -
>so is it relevant when these tests seem to be for runtime conformance?
>
>[cbb] We want to be able to test runtime as well as whatever modelling conformance possible. I think this is relevant for the latter and for illustrating how to use the feature. 
>[cbb1] Drop this example(s) as very difficult to positive test without going outside scope of WS-CDL
>
>
>
>choreo-with-complete:
>
>CHANGES: Have taken out the loop as this was irrelevant. Have moved the assign
>to between the req4quote and acceptquote, as this then demonstrates
>that the accept is not performed as both endpoints terminate early.
>Also added assign on seller side, so that both participants are in step.
>
>[cbb] The changes are a clear improvement. Thanks. 
>
>
>choreo-with-coordination:
>
>[gb] Coordination not implemented in pi4soa - however this choreo has no
>root choreo.
>
>[cbb] Corrected. 
>[cbb1] At risk feature. No intention to implement in pi4soa. Keep as part of bundle.  
>
>
>
>choreo-with-exception-block:
>
>[gb] Missing alot of static type details and references from dynamic model
>to those types.
>
>CHANGES: Obtained static data from other example and based the
>interaction causing the exception on that data - and changed the
>interaction in the exception block. Also added interaction after the
>exception causing interaction to demonstrate that it is not
>performed when exception occurs.
>
>[cbb] This was missed by mistake and the details added are fine. Thanks.
>
>
>choreo-with-finalizer-block:
>
>[gb] Same as above - plus needs a sub-choreo performed to then show
>finalize in action.
>
>CHANGES: Added main and sub choreos - then performed Sub from Main
>and then finalized - had two finalizers as in original example,
>each does a different interaction to demonstrate that the correct
>finalizer has occurred.
>
>[cbb] This was missed by mistake and the details added are fine. Thanks.
>
>
>choreo-with-sequence:
>
>CHANGES: Moved middle interaction outside workunit loop, as supposed to be
>showing sequence.
>
>[cbb] Either one would have been showing a sequence, but this change makes the example more clear.
>
>
>choreo-with-parallel????
>
>CHANGES: Added one on the assumption that it was missed by mistake.
>
>[cbb] This one was missed and the one added is fine. Thanks.
>
>
>choreo-with-single-level:
>
>[gb] Not sure what this is supposed to be testing, as looks similar to others.
>
>[cbb] This should be dropped since we are already testing a "basic" choreo without specifying any quality of service.
>[cbb1] Drop this example. 
>
>
>choreo-with-subchoreo:
>
>CHANGES: Too complex - just need to test that a sub-choreo is performed - so stripped out
>the loop in the top choreo and only dealing with a req/resp in the sub.
>
>[cbb] The changes are fine. The other areas are being tested elsewhere. 
>
>
>choreo-with-subchoreo-free:
>
>[gb] Isn't this the same as the choreo-with-subchoreo example?
>
>[cbb] It functionally is the same. We can drop this one. 
>[cbb1] Drop this example.
>
>
>choreo-with-subchoreo-complete:
>
>[gb] No point in completing the choreo at the end, and the root choreo is
>being completed, which has already been tested. What is the purpose
>of this test?
>
>CHANGES: Put completion condition (flag set) on sub choreo performed
>from main, completed sub between sending second interaction, then
>did further interaction in main to prove point.
>
>[cbb] The changes are fine and clarify the example. 
>The purpose of this test is to illustrate that explicit completion of a sub-choreo 
>behaves as if it were a root choreo, with the exception that the root choreo in this 
>case carries on with additional work (as illustrated by the further interaction). 
>
>
>choreo-with-subchoreo-nofree:
>
>CHANGES: Changed to be same as modified choreo-with-subchoreo, but taking away the
>bound parameter, which is all that seemed to be the difference with
>original version.
>
>[cbb] The changes are fine.
>
>
>choreo-with-subchoreo-isolation:
>
>[gb] The isolation is on the root choreo - it should be on the performed
>sub-choreo that has bound variables that are shared with other
>sibling choreos. How is this going to be tested though?
>
>[cbb] After further thought this seems to only be testable in a negative sense - 
>can sibling sub-choreos perform conditional (simple) interactions based on updated 
>variable data before the isolated sub-choreo is completed? As such I am in favour of 
>dropping this example. 
>[cbb1] Drop this example. 
>
>
>choreo-without-qos:
>
>[gb] Not sure what this is supposed to be testing.
>
>[cbb] This supposed to test a basic choreo without any specified quality of service. 
>This should behave as a single level choreo with root="false" so we can drop the single level test 
>[cbb1] Update the example as per further discussion in WG. (Charlton)
>
>
>interaction-with-align-true:
>
>[gb] Unimplemented feature.
>[cbb1] At risk feature. Will keep in bundle until decision made on feature. 
>
>
>interaction-with-exception-noaction:
>
>[gb] No static definitions.
>
>CHANGES: Updated to be similar to choreo-with-exception-blocks, except
>it does a no-action in the exception handler.
>
>[cbb] The definitions were missed by mistake - thanks for the correction. 
>
>
>interaction-with-initiate:
>
>[gb] Initiate flag is no longer relevant, so this test could be deleted.
>
>[cbb] I may have missed something, but how is initiate no longer relevant? 
>[cbb1] At risk feature. Issue 3843 in discussion at present. Waiting for next formal meeting to make a decision. 
>Leave in the bundle pending decision made on issue 3843.
>
>
>interaction-with-record-causeexception:
>
>[gb] Currently not supported due to ambiguous statement in spec section 6.2.3
>"When two or more record elements are specified for the same roleType in an
>interaction, with their causeException attributes set to indicate that an 
>exception should be caused, then one of the exception types MAY be caused. 
>The throwing of an exception has a non-observable predicate condition associated 
>implicitly with it, that decides if an exception is caused"
>[gb] Think that causeexception should be removed from here, and just occur on the exchanges
>which are deterministic
>
>[cbb] Should we not address the ambiguity instead of not testing this feature? 
>[cbb1] Gary made a proposal as per http://lists.w3.org/Archives/Public/public-ws-chor/2007Jan/0010.html toward resolving this ambiguity. The example should stay in the bundle as the resolution will remove the issue. 
>
>
>interaction-with-record-noCauseException:
>
>[gb] How does this prove the fact that the record occurred? Possibly better to assign
>a value to a variable, and then have a choice which tests the value and should
>so the same interaction in both endpoints?
>
>[cbb] This should perform a conditional interaction based on an assigned variable. 
>[cbb1] Similar example to that described for choreo-without-qos.cdl. 
>Update the example as per further discussion in WG. (Gary to update)
>
>
>interaction-with-reqresp-causeexception and nocauseexception:
>
>[gb] These should probably be variations of the
>interaction-with-record-causeexception etc. At the moment they are too
>complex for the simple test they represent.
>
>CHANGES: Don't think these are required, causeexception is basically
>interaction-with-exception-noaction and nocauseexception is same as
>choreo-with-sequence.
>
>[cbb] As these overlap with the other examples I am fine with dropping these.
>[cbb1] Drop these examples. (2)
>
>
>interaction-with-timeout-causeException:
>
>[gb] No timeout expression - no static definitions.
>
>[cbb] Corrected.
>
>
>workunit-with-block:
>
>[gb] Need concurrent paths, one to block and the other to restart the other
>path when it completes. Also the interactions cannot send/receive
>Strings as not possible to extract identity information.
>
>CHANGES: Used static information from other examples. Setup parallel
>activity with blocking workunit waiting for variable that is only
>set after interaction in other path.
>
>[cbb] Corrected.
>
>
>workunit-with-guard:
>
>[gb] Changed from what was attempting to use a loop (with no repetition
>condition) to actually be a conditional, which should fail as the
>acceptQuote variable is not available.
>
>[cbb] Corrected. 
>
>Summary: 
>- Drop eight examples as listed above.
>- Update four examples as listed above.
>
>Actions:
>Gary and Charlton to update two examples each as noted above.
>Charlton to repackage examples in their present state and:
>1. Drop the eight examples noted above.
>2. Change the questions directory in the archive to "update" and place the four examples to be updated therein
>3. Update the Issues.txt to reflect these notes. 
>
>
>
>