<snip>
I think it would be a good idea to talk about these two -a user-oriented workflow tool with a modeling UI and a well defined limited context -and a more flexible development tool
as separate implementations sharing the same interface.
I don't see any reason to limit the user oriented tool? Start from a flexible underlying model, be aware that it should be possible to generate the model form some GUI....
Workflow modeling is very complex by the user is very complex. The user is programming (creating objects, defining conditions, etc.) but must not be aware of it. Its usefulness lies with designing/implementing regularly-changing business processes.
When starting this thread my focus was on workflow for a single object, which is much simpler. Also we at Hippo have no requirements for users modifying the workflow. We expect a limited number of workflow definitions and few changes.
As a developer I still want to express state machines as tersely as possible. A graphical tool would be great (anyone for writing XSLT to transform XMI documents?), but a well-structured XML document will do fine.
-- Johan Stuyts
