- From: Howard N Smith <howard.smith@ontology.org>
- Date: Fri, 05 Dec 2003 12:38:31 +0000
- To: public-ws-chor@w3.org
AA said in response to JJ >I do not understand why you imagine that our product is a pi-calculus engine equivalent to, say PICT, >and not a fully grown BPMS. It is, in fact a BPMS. And as such, it fulfills all the requirements of BPMS. >I don't think our expertise with pi-calculus has clouded our judgment, just like I don't believe our expertise with SQL or >TCP has prevented us from realizing a BPMS. I can confirm it is a full BPMS. One of the most complete I have seen, and I've seen a lot. >So to answer your questions: a) nope. you can have any arbitrary level of nesting that meets your needs, >and different levels of nesting at the same time. Yes you can. I know this from experience. >b) maybe pi-calc doesn't allow that, but our product does. True, and its how things like process calculi are used to create innovation products that makes the difference. >we do quite neatly express domains of controls, as you can see in the screenshots. Again, I can confirm this from experience. >If that was a conceptual question, I would agree with other pi-calculus experts. But I do have to take other considerations >into account, including interchange of definitions, modeling tool, management and deployment, etc. What we call real-life >requirements. In pi-calculus you don't need to label an action. In a process definition language you do need to label an >action, because it helps the designer and administrator, hence the @name attribute. It doesn't exist in pi-c, but it's absolutely >required in a process definition language. Similarly, there are many other additions that are introduced in order to meet >non-conceptual requirements. Yup. After this, I promise never to mention a real technology ever again on this list. Let's keep conceptual :-) H --- New Book - Business Process Management: The Third Wave www.bpm3.com Howard Smith/CSC/BPMI.org cell +44 7711 594 494 (operates worldwide, dial UK) office +44 20 8660 1963
Received on Friday, 5 December 2003 07:43:50 UTC