Well Formedness Candidate Rules for 2.doc

ebxml-bp message

In the attachment, some (not all) well-formedness rules for BPSS instances are provided that restrict the kinds of elements that can be referred to by some of the attributes of type IDREF in the ebBP 2.0 schema.

Well-formedness rules are conditions beyond schema validity that BPSS instances must meet in order to be "well-formed" This does not mean that the instance will thereby be a sensible business choreography, of course.

Nearly all of the rules in the attachment are ones that constrain what can be referred to and where. While most schema validity checks will check to see that an attribute of type IDREF actually has a value of some attribute of type ID, this allows a reference to a Role to point off to a nameID value of a BusinessDocument, and other nonsensical combinations. So the WF rules just state the intent that the IDREF references are really "typed" to legitimately refer to certain kinds of elements.

Anyone with an interest in implementation should review these constraints and see whether they think they should be enforced as-is, strengthened, or weakened.

There are a couple of rules that I think need attention from all TC members, however. Please look at the rules about ToLink and FromLink references. The rules now strictly enforce linkages as between states only, and also restrict states to be elements of CollaborationActivity, BusinessTransactionActivity, and ComplexBusinessTransactionActivity (for nested states that are interpolated between request and response--that is, multi-swimland activities where some actions must be completed before responding and where multiple parties are involved). These rules mean that linkages from states to "pseudostates" are not allowed.

I don't think there are any use cases that can't be handled otherwise (and more clearly) for potential pseudostates like fork, join, decision, and transition.

However, it may be that people want to allow links to the special states such as Start or the completion "states" Success and Failure. For example, people might want to let a Join merge several From states to a Success or a Failure termination without going to a real state. While each of the forked paths could be specified as going to a completion state under specifiable conditions, we probably need to catch all the forks in joins if we want to enforce the "waitForAll" semantics (that is, "conjunctive" forks).

There may be other cases where allowing the Start, Success. or Failure pseduostates to be targets within FromLinks. Please consider these modelling issues, and we can loosen up the FromLink rule accordingingly. However, IMO, every "loosening" means that we get closer to allowing more complicated diagrams that may have no real modelling uses, and that move us away from a semi-structured approach to a wild-west, anarchistic, free-from approach.