Process XML Element Description: Tags and Attributes

NOTE: These are for now just HTML tags. They should be converted to XML tags, with less use of attribute fields, in order to take advantage of XML parsers. However, tagging text such as the in the Journal Review Process example may then be problematic as not all of the required information appears in plain text.

Not shown explicitly, but every PXML tag has a ProcessDefinition component with a value that is the URL of the process definition being referenced by the tag.

Role
  name - text | "to be assigned" | "@"<filename> | "to be assigned"
  email - text

This tag defines the roles of the participants. The role is defined by the text tagged. Each participant is identified by name and email address. These may be listed on a file - or noted to be assigned at process execution time.

Step
  step-name - text
  prior-step - step-name | list | "ENTRYPOINT"
  prior-action - text
  sender - role | list, one of
  receiver - role | list, one of | program
  [cc - role| list, all of]
  action - text | list, one of | "END"
  [content - "y" | "n" | text]
  [annotation - text]
  [super-process - process-name | step ]
  [autostart - program-name | time | initial-step ]

This tag defines a formal step in the process. In execution, there will be separate tasks each composed of combinations of steps, responses, and conditions as they occur.

Steps match on prior-steps and prior-actions.

The prior-action is not defined when the prior-step is "ENTRYPOINT". The sender and receiver lists possible roles. The action is a list of keywords of possibilities. Content indicates that the receiver should act on information within the body of the message. If the content is text other than "y" or "n", it is the name(s) of one or more XML type of document(s) (names separated by commas) included in the content. The annotation is an optional text to be included in any email message automatically.

The super-process field references a super-process of which this process is a sub-process. The ENTRYPOINT of the current process is associated with the "step" of the super process. This allows processes to be recursively nested. Process may be refered to by name - this allows processes to be shared but maintained in one place.

Notice that the server should hold the information about the two steps of the super process and that the user should not be allowed to change this information. Thus, having this information in the step is redundant, but could be useful for a completely distributed computation.

If the receiver field contains a program (with a "P" tag), it is an arbitrary program, perhaps acting on the XML document(s) in the content field, that generates a list of recipients.

If there is no other step for which a step is a prior-step, then it is assumed to "END", or this can be noted explicitly with the action. (But this should be noted as at least a warning in any process verification.

Parallelism: There is no explicit process forking. If more than one step applies to a prior step, then all are considered necessary for the process. That is, implicit forks are considered to be "ANDS". If there is an "OR" to be expressed, this is done with the lists in receiver and action.

Merging: There is no explicit kind of wait-until. This can be handled by the work automation rules. For instance, if the next step can not proceed until responses are gathered from an explicit set of people (notice that "all" is not generally computable), or by a certain time, this can be specified as a work automation rule rather than a process rule. And should be. The only kind of process definition control is whether the step should be performed by a certain time or completion of some other step. The tags as specified allow the PCC to know that it should collect all of the process and work documents from previous steps for use by the current participant.

Dynamicism: Again, this is addressed by the work automation rules. The user can define to whom the next documents should be sent and what sorts of actions are expected - new actions and output documents. It can be coporate policy whether or not this overrides pre-defined processes, but the PCC will issue a warning (to pre-defined administrators) in such cases.

Autostart: This specifies a program name and a time that this program may start a process. If the program name is the keyword "OPM", then OPM starts the process. The instance of the process is determned by the step values of the "initial-step" but the prior-action must be ENTRYPOINT. All values of the initial-step must be defined in the PXML prior to runtime. The "time" may either be a date and time or a frequency at which to start a new process instance.

Authority: We have not yet addressed authority issues apart from role definition. Some authority issues are best handled by work automation rules.

Response
  step-name - text
  prior-step - text | list
  time - <time> | <step-name>
  sender - text | list, one of
  receiver - text | list, one of
  cc - text | list, all of
  action - text | list
  [content - "y" | "n" | text]
  annotation - text

A response defines the exception action to be taken if a step is not taken within a certain time - every one on the receiver list is notified.

Condition
  step-name - text
  "illigal" "=" | "\="
              <role> | <name> | "*"<parameter>"*"
              <role> | "*"<parameter>"*"

This defines that for a given step-name, certain roles or parameter values may not be certain roles, parameter values, or names. For example, a particular role may not be the sender of a named step. These conditions are constraints on the process, not on the task data.

Assign
  step-name - text
  role - <role>
  assigned - <name> | "*"<parameter>"*" | program

This provides automatic assignment of a role based upon a step and a parameter in that step. A direct name assignment is also possible. If the role of a receiver corresponds to a "to be assigned" role in a step, then the name used in that step is assigned to that role.

Perform
  act-name - text
  prior-step - text | list
  prior-action - text
  action - text

This is a "dummy" step used to indicate that the actor of a certain step is expected to perform some action not involving anyone else - such as updating a database. A response may be associated with such a performance as well as a step. This is useful for checking the progress of a task on a web page. This tag could possibly be replaced with just "step", but omitting the message components: sender, receiver, cc, etc.



Agent-like Interaction Messages

These are not essential. But they are useful in a distributed transaction environment for implementing a notion of failure that would propagate. One does not have to explicitly define failure for each step of the process, but each participant should be able to express failure and decide what to do upon receiving such a message.

Sorry
  prior-step - text | list
  prior-action - text
  explanation - text

This is simply a response from the person or software agent that they are not able to respond appropriately to the previous step. This is not a step in the process.

Error
  prior-step - text | list
  prior-action - text
  explanation - text

This is a response from the person or software agent that the process information sent in the prior step is is considered in error and should be corrected and resent. This does not indicate anything about the task data. This is not a step in the process.



Messages About Task Data

These are also not essential. Such messages could be expresed using steps. However, they are so basic, that it might be good to build them in here. Doing it this way is more parsimonious.

Exception
  step-name - text
  prior-step - text | list
  sender - text | list, one of
  receiver - text | list, one of
  cc - text | list, all of
  action - text | list
  [content - "y" | "n" | text]
  annotation - text

An exception says that the task data from the prior step was not acceptable in some way and defines a new step in the process - every one on the receiver list is notified. A subprocess may result from this exception.

Conflict
  step-name - text
  prior-step - list
  sender - text | list, one of
  receiver - text | list, one of
  cc - text | list, all of
  action - text | list
  [content - "y" | "n" | text]
  annotation - text

A conflict says that the task data from a list of prior steps was not mutually acceptable in some way and defines a new step in the process - every one on the receiver list is notified. A subprocess may result from this conflict.

It may be that other tags would be good for resolving conflicts and/or for allowing previous steps to be changed or even revoked, but that can be an advanced version. But it would be good to give people that flexibility.



© 1998, 1999 Charles J. Petrie, Jr.
cjp
Last modified: Fri Jun 25 11:35:26 PDT 1999