- From: Assaf Arkin <arkin@intalio.com>
- Date: Wed, 04 Jun 2003 22:42:04 -0700
- To: "Yaron Y. Goland" <ygoland@bea.com>
- CC: WS Chor Public <public-ws-chor@w3.org>
I like it. I do have a few minor comments, though, with suggested text where applicable. Yaron Y. Goland wrote: >I propose the following requirements be added to the requirements document: > >The WS-Chor choreography description format MUST provide mechanisms to >enable a choreography to specify that a process in a particular role MUST >send zero, one or more messages from a statically defined set of messages in >parallel, serial or any combination of the two. > > What about iterations? >The WS-Chor choreography description format MUST be able to describe >decision points where a process in a particular role MAY send zero, one or >more messages from a statically defined set of messages in parallel, serial >or any combination of the two. > > Not sure what the difference is from above. Whould it be just easier to say something like "parallel, serial, exclusively"? >The WS-Chor choreography description format MUST be able to describe who is >to receive a message by referencing their role. > > "By referencing their role" is too restrictive. Perhaps the role would reference the messages it expects to receive, or they would be listed in the same container, etc. Can we just say something like "identify the role that will receive a message"? >The WS-Chor choreography description format MUST NOT require that the logic >used by a sender in a decision point to decide how to act be exposed in the >choreography. > > Contrary to what may have been assumed, I +1 that. >The WS-Chor choreography description format MUST enable the annotation of >all actions with human readable descriptions. > I would also add that the choreography description format MUST enable the naming of all actions and decision points such that they could be referenced from other specifications (e.g. an RDF-based specification may say interesting things about them). >The WS-Chor choreography description format MUST provide an abstract >mechanism where by the logic used to make a decision at a decision point can >be expressed through reference to a WSBPEL abstract or executable process or >similar machine readable logic. > I'm not sure I understand this, or perhaps we're using the term decision point differently. More clarification would help. We should change the language such that the choreography doesn't have to reference the BPEL, but the BPEL can reference the choreography. That would allow me to come up with two different BPEL's for the same choreography. And, of course, this assumes we can even reference BPEL in a normative way. I suppose at some point we'll bite the bullet and take a vote on this. > >The WS-Chor choreography description format base specification MUST NOT >specify bindings for the abstract mechanism used to reference machine >readable logic, rather extension specifications on top of the base >specification MUST be used. > I am absolutely not clear what this last requirement says. What is an abstract mechanism used to reference machine readable logic? In fact, what is machine readable logic? The first requirement suggests machine readable logic. Also, I suggest the text say "specify concrete binding" and also allow referencing to be used as alternative to extension specifications (in the same way you can reference a WSDL and don't have to explicitly extend it just to say something about it). arkin > >I would appreciate it if objections to these requirements were stated in the >form of alternate proposals. It's easy to say why something is wrong, it's a >lot harder to spend the time to specify what is right. > > Yaron > >
Received on Thursday, 5 June 2003 01:42:35 UTC