Topic: wftk -- Process definition example -- open source project

<?xml version="1.0"?>

<workflow name="Open source change request" author="Michael: michael@vivtek.com">
  <role name="Analyst"></role>
  <role name="Developer"></role>
  <role name="Tester"></role>
  <role name="Documentor"></role>

  <data name="Change request number" type="sequence"></data>
  <data name="Description" type="text"></data>
  <data name="Supporting documentation">
    <list><data type="document"></data></list>
  </data>
  <data name="Mailing list"><list><data></data></list></data>
  <!-- The mailing list starts out with just the requester's name on it -->

  <sequence>
     <task label="Analyze" role="Analyst">
        <data name="action" type="choice(ok,merge,fork)">
           <!-- Aha!  Content of a data tag could be how to elicit it! -->
        </data>
     </task>
     <if expr="${action} == 'merge'">
        <situation name="merge"></situation>
        <elseif expr="${action} == 'fork'"/>
        <situation name="fork"></situation>
     </if>
     <task label="Develop" role="Developer">
        <data name="changes" type="collection(cvs)"></data>
     </task>
     <task label="Test" role="Tester">
        <data name="test plan" type="collection(cvs)"></data>
     </task>
     <task label="Document" role="Documentor">
        <data name="CR documentation" type="document"></data>
        <data name="Doc updates" type="collection(cvs)"></data>
     </task>
  </sequence>
  <handle situation="merge">
     <task label="Define merge" role="Analyst">
        <data name="mergee" type="workflow"></data>
        <data name="explanation" type="text"></data>
     </task>
     <alert type="foreign-role" to="${mergee}:Analyst">
        <data name="label" type="text" value="Change request merge"></data>
        <data name="explanation"></data>
        <data name="mailing list"></data>
     </alert>
  </handle>
  <handle situation="fork">
     <task label="Define fork" role="Analyst">
        <data name="description" type="text"></data>
        <data name="newdescription" type="text"></data>
        <data name="Supporting documentation" type="collection(document)"></data>
        <data name="New supporting documentation" type="collection(document)"></data>
     </task>
     <start name="Open source change request">
        <data name="description" value="${newdescription}"></data>
        <data name="Supporting documentation" value="${Supporting documentation}"></data>
        <data name="Mailing list" value="${Mailing list}"></data>
     </start>
     <resume/>
  </handle>
</workflow>

All those new data types
I'm starting to get excited about the idea of datatype adapters. Data type "sequence" is supported by many database systems: it's guaranteed to return a unique value for each instance. And I thought "collection()" just makes sense. Sure comes in handy for lists of mailing addresses, collections of documents (i.e. a folder), collections of things that don't get collected easily, like CVS entries for code changes. (One of the things I hate about CVS is that you can't collect changes into logical groups. A universal folder like this, though, can do that easily. And since the value sheet for the process is itself an XML document, the collection is very easy to implement.)

So I'm getting a little more creative with data types. I tossed in an "enum(<>)" just to see how it looked. I'm not overly enamored of enum data types, but it does give it a clean appearance.

<resume> tag, anyone?
I found that if I wanted to use a situation for the forking case (which seems natural to me) I can't, without a way to resume the sequence at the point at which the situation occurs. Which is a natural extension if you ask me, and cheap enough to handle. Anyone care to differ on this?

Workflow merge
Initially I was thinking of a <merge> tag to merge two processes, but when I started thinking about that, I realized that to merge two processes, you'd have to specify exactly what to do to merge existing values into one, and once I seriously thought about that, it was obvious that it's too complicated.

So instead I decided to see if it makes sense to handle this as a notification to a role in the other process, which I called a "foreign-role" type of alert. The recipient of this alert would have access to the necessary data in the current workflow (even after it's no longer active) to merge the information into the foreign workflow.

This would seem to create a sort of ad-hoc task in the foreign workflow, so we might want to think about treating it as a sort of task. The whole ad-hoc task question is wide open anyway.

Workflow start
As weird and complicated as merge is, though, "start" is pretty obvious. start a new process, give it the name of the definition, and give the named data values to use. This just plain makes sense. As you can see, I created a new tag <start>

Task specification with two collections
Wouldn't it be nice to be able to put up a form with two collections on it, and allow the user to drag and drop them back and forth? (Or something of that nature.) Actually, this isn't all that hard to do with DHTML, I've found. Just a pleasant thought. It'd be nice in this fork situation, where some of the supporting document supports one of the child processes, and other documents support the other.

Well, that's all I can think of at the moment. I'm sure this one will spark just as much debate as earlier installments in the XML series.