Issue - 116 - <process> element should be optional

[ws-bpel issues list editor<peter.furniss@choreology.com>]

This issue has been added to the wsbpel issue list. The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent document with the title in the "Issues" folder of the WSBPEL TC document list - the next posting will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - 116 - <process> element should be optional

Status: open
Categories: Syntax and validation
Date added: 1 Apr 2004
Submitter: Peter Furniss
Date submitted: 01 April 2004
Description: At present, a BPEL script has to have a top-level <process> element as the container for all the
interesting activities and stuff. However, although there syntactically needs to a top-level xml element,
the idea that this should be a single defined process, with a single purpose, does not reflect common
business behaviour.

In older business processes (such as those entirely or predominantly operated by humans) it is very common for fragments of process to survive long after the circumstances that justified those fragments have ceased to be relevant. Long-lived "business" processes, such as procedures and customs of national legislatures are good examples of this.

Although BPEL is concerned with automated processes, it should be possible to re-implement human-implemented processes in BPEL, and similarly we should expect BPEL processes to evolve in a similar way, with relics of former requirements continuing to be defined in the script. Thus it would enhance the wide and long-term usefulness of BPEL if the top-level process element were made optional, allowing a BPEL script to contain a disconnected collection of process fragments.
Submitter's proposal: Allow alternative top-level element instead of <process>. The name <bag> might be appropriate.

It is not proposed, at this stage that a BPEL process or bag should be required to be dynamically self-modifying. Such behaviour is of course common in real processes, and could be considered in future BPEL work.
Changes: 1 Apr 2004 - new issue

---

To comment on this issue, please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 116 - [anything]" or is a reply to such a message.

To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).