- From: Jon Dart <jdart@tibco.com>
- Date: Mon, 28 Jul 2003 17:19:42 -0700
- To: Monica Martin <monica.martin@sun.com>
- CC: Daniel_Austin@grainger.com, public-ws-chor@w3.org
Comments inline. Monica Martin wrote: >> I notice the latest draft has incorporated some of my proposed text >> (and maybe my diagram, I'm not sure). > > > mm1: It is the updated diagrams I provided in the reformatting of the > use cases, as requested by the editors. The draft I'm looking at was in SRT's agenda mailing (for some reason) and doesn't have diagrams, AFAIK. I'd be happy to review these if I could see them. Therefore we have: > > * An agreement is understood prior to entry. > o Business rules known and applied at entry > + Parallel processing - A dependency exists and the > parallel processes are combined at the end (quality > check applied prior to completion). > + Dependency: See ordering process Jon specifies above > (quality checks used as a subprocess). > o Business rules known and applied during process execution > + Dynamic: See ordering process Jon specifies above > where the quality check may or may not be applied > during process execution. > o Business rules unknown prior to entry > + Dependency: See above. > + Dynamic: See above. This is a nice breakdown and it would be nice to have it in the use case intro. Do I understand that main difference between "dependency" and "dynamic" is that in the first case you are altering the process flow by calling a subprocess, and in the latter you are, in effect, re-writing the process diagram (adding in some activities). Also, don't both these cases really amount to a conditional branch triggered off some flag the business rule sets? At least that would seem the most straightforward way to accomplish it. But I am still looking for some text to replace/supplement the two paras I found murky .. although with more context I understand them better now. When you say "business rules unknown prior to entry", unknown to whom? Both parties or only one? You could imagine the seller has a rule that is not being published to the buyer. Or do you really mean "I am going to make up the rules when I get a message - they're determined by something outside the choreography, e.g. phase of the moon". In either interpretation, IMO the third case may be a level of complexity that is best omitted here. You can always add more dynamism but maybe this use case has enough for illustrative purposes. > mm1: I think if we look at this more abstractly, many types of Quality > Checks could be applied. Handle Questionnaire is just one example. I > would be happy to say apply Quality Check and specify in this case it is > Handle Questionnaire. Thoughts? My original proposal was to rev the diagrams to say "Quality check" because that's what the text says, but your proposal is probably good enough. --Jon
Received on Monday, 28 July 2003 20:19:58 UTC