- From: Assaf Arkin <arkin@intalio.com>
- Date: Tue, 29 Jul 2003 19:12:35 -0700
- To: jdart@tibco.com
- CC: public-ws-chor@w3.org
Jon Dart wrote: > > Kudos and thanks to the editors for getting this out. > > A few comments: > > re: 4.3 Scalability. One of the requirements I have mentioned is > re-entrancy: execution of a choreography flow should not block > execution of another instance of the same flow (e.g. two orders coming > in from customers should be able to be processed in parallel). (This > is in the F2F minutes, I believe). This may be purely an > implementation issue, but we shouldn't preclude it at the spec level, > or assume serialized execution. I'm not sure I would call this re-entrancy since there are two distinct instances. Just mention that the specification should not in any way preclude multiple instances of the choreography happening concurrently. (Other specs or implemenations may preclude that, though) > (This is different from D-CR-040 or D-CR-041 because I'm not talking > about parallel flows within a choreography, but parallel execution of > choreography instances). > > D-CR-009 is a special case of D-CR-061, I think. Maybe they should be > grouped together. > > Re D-CR-049 (design-time validation): it isn't really clear to me what > this means. What does "correct behavior" mean at design time? Absence > of deadlock, or ? The term correct behavior means 'working according to specification'. If it does not work according to specification then it's considered faulty. If the specification indicates that there would be no deadlocks then having a deadlock would be faulty. If the specification allows deadlocks then having a deadlock would be considered correct. If a database deadlock than the database is not faulty. A deadlock is permissible according to some specifications. However, if the application causes the database to deadlock the application would typically be incorrect, since the specification for the application would typically state that it must not cause the database to deadlock. arkin > > > The doc needs a spell check. > > --Jon > > Daniel_Austin@grainger.com wrote: > >> >> Greetings, >> >> The most recent draft of the requirements document has been >> uploaded to the archive list (still having problems uploading to >> W3C). It's here: >> >> http://lists.w3.org/Archives/Public/www-archive/2003Jul/0024.html >> >> This version is labeled 1.0, and is dated for July 30th, next >> Wednesday, for publication after our next call, based on the group's >> approval. >> >> Please review this document carefully. Much has changed since >> the last version. Here's a summary: >> * requirements (some 60+) have been added to the document. >> * the use cases have been largely rewritten >> * references are now available (though not yet footnoted) >> * many other changes >> >> I'd like to ask that the entire group carefully review this >> document with a view to publication on July 30th. The document is not >> entirely ready to be published, there is still some minor publication >> clean up to be done. Otherwise, it's not a bad first working draft of >> the group's requirements. >> >> On behalf of my fellow editors, >> >> D- >> >> >> ************************************************* >> Dr. Daniel Austin >> Sr. Technical Architect >> daniel_austin@grainger.com >> 847 793 5044 >> Visit http://www.grainger.com >> >> "If I get a little money, I buy books. If there is anything left >> over, I buy clothing and food." >> -Erasmus > > >
Received on Wednesday, 30 July 2003 15:37:56 UTC