Tim.Churches wrote: > Thomas Beale wrote: > > > > > I agree with Dave that this area is interesting and important to sort > > out. I'll put the PhD thesis links on openEHR.org - they are all a > > great read. > > > > my 5c > > Any opinion on YAWL ( http://www.yawl.fit.qut.edu.au/ )? I'll warn you that I am a relative beginner in this workflow area, so my opinion won't count for much. YAWL is another "object model" approach to the workflow formalism problem. It's a modified Petri-net approach, which means it may have some inherent limitations (see Robert Müller's comments below). I have not studied it enough to know. Both Müller and Eric Browne did work on adaptive workflows (based on the real concern that what you planned to be done might have to be changed partway through due to unexpected events); they both imply that Petri-nets are too limited in this area.
From my point of view, YAWL looks like good work; the graphical language contains many of the operators that seem to be needed (and there are a lot of similarities with Müller's own graphical workflow language, AgentWork). My issue with it is only what I stated before - these graphical languages look great (they really do - I have spent days playing with them; thay have a lot of expressive power and are very enticing) - it is only when you have a look at 3+ experts' ideas on what the language should be that you realise that there is no common (i.e. interoperable) language for this purpose, and that none of the languages has exactly the same semantics (making the development of a shared language a real challenge). See http://www.yawl.fit.qut.edu.au/about/tour/diagram.jsp for an example YAWL diagram; you can get a feel for some of the operators (various kinds of splitters and joiners etc). On page 14 of http://www.yawl.fit.qut.edu.au/yawldocs/yawl.pdf you can see the elements of the language. We do need a language like this; but each research group has their own version, and it is not just a case of minor syntax/naming differences. This tells me that it is too soon in the research history of this subject to commit to a graphical language. The reason is this: when you have a graphical language, any particular workflow that you write has to be a serialised expression of these graphical elements. If you decide for any reason to change the semantics or naming of the elements, all previous workflows risk being invalidated; they probably have to be converted. Whereas if you start from a parsable language, it is much easier to ensure that previously written instances still not only compile, but have the correct semantics according to later thinking. That is because the parser contains the transformation rules from the language expression into the objects. Starting with the objects locks you in, at least to some extent in my mind. The syntax approach also means that workflows are just text files; in the object form, they will typically be serilialised to XML files whose contents must conform to a particular schema (they might conform to a different one, but the differences can't be great). The flexibility of the parsing approach is what is needed when a domain is working out its solutions. I don't know how big this problem is, but I do know that attempts to have universal graphical languages so far have only succeeded in specialist areas after many years. They haven't worked in programming - else we would all be using UML to program with. - thomas beale ********** Comments by R Müller on petri-net approaches to workflow, in his 2003 PhD thesis. [AALST 1997, VOORHOEVE & AALST 1997] describe an approach where - in contrast to [ELLIS ET AL. 1995] - every workflow instance is controlled by exactly one so-called workflow net, which is a workflow-oriented petri net subtype. Thus, ad hoc adaptation of single instances becomes possible. For this, a number of predefined transformation rules is provided, e.g., to refine an activity with a subworkflow, or to split up sequences to several paths executed in parallel or conditional, and to join them again. However, the limitation of this approach is that data flow aspects are neglected, and that the handling of loops remains unclear. Furthermore, structural ad hoc adaptations of petri nets usually require the reconfiguration of the net state (or marking), i.e., of the token distribution [BAUMGARTEN 1996] within the net. However, many petri net-based adaptation approaches (e.g., [ELLIS ET AL. 1995, VOORHOEVE & AALST 1997]) assume that users are familiar with the petri net modeling language or with a graphical petri net tool. However, one cannot expect that for example physicians or nurses during clinical routine are able to change a token distribution of a petri net manually and to overlook all implications. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/openhealth/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
