- From: Charlton Barreto <charlton_b@mac.com>
- Date: Tue, 23 Jan 2007 12:14:21 -0800
- To: WS-Choreography List <public-ws-chor@w3.org>
Comments inline.
-Charlton
-----
assign-with-causeexception:
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:
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:
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.
channeltypes-with-identity*:
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.
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:
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.
channeltypes-with-passing:
Needs to have interactions on passed channel to demonstrate correct
passing.
[cbb] Corrected.
channeltypes-with-usage*:
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.
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:
Coordination not implemented in pi4soa - however this choreo has no
root choreo.
[cbb] Corrected.
choreo-with-exception-block:
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:
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:
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.
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:
Isn't this the same as the choreo-with-subchoreo example?
[cbb] It functionally is the same. We can drop this one.
choreo-with-subchoreo-complete:
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:
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.
choreo-without-qos:
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="true" so we can drop the single level test
interaction-with-align-true:
Unimplemented feature.
interaction-with-exception-noaction:
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:
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?
interaction-with-record-causeexception:
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"
- 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?
interaction-with-record-noCauseException:
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.
interaction-with-reqresp-causeexception and nocauseexception:
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.
interaction-with-timeout-causeException:
No timeout expression - no static definitions.
[cbb] Corrected.
workunit-with-block:
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] The changes are fine.
workunit-with-guard:
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] The changes are fine.
--
charlton_b@mac.com
+1.650.222.6507 m
+1.415.692.5396 v
Received on Tuesday, 23 January 2007 20:14:30 UTC