Since tasks are arguably the whole point of workflow, it's not surprising that there's a
lot to do to define a task. But basically it boils down to these things:|
So an appropriate syntax would be something like this:
- The role: what class of entity is supposed to perform the task.
- Process-specific values which are part of the particular task.
- What values and deliverables are expected from the agent after the task is completed.
- (For human agents, anyway) an HTML presentation to use for the task.
- The label to attach to the task in lists.
<task label="The next thing to do" role="Secretary">
At this point I'm not going to waste time on how the formatting will be specified. I have
a couple of different ways that I often use, and I'll use one that feels right when I get
into coding. But the important things here are the
<expect type="file" name="incoming">...</data>
some way of formatting the page
data and the
data tag names values which are salient to this particular task, while
expect tags denote values which must be obtained from the agent when the
task is completed. The display of an active task must show both; in HTML format, the
task must show the data values, and supply data entry fields for the expect values.
If a task is completed by email, then (somehow) the expected values must be marked in the
email -- or more likely, email completion will only work for tasks with no expect values.
Again, we'll see what makes sense when we start coding.