BPMN Semantics "Vague" or Just Hard to Code?

My previous post on Reframing the BPEL vs BPMN Debate triggered a lively comment thread that somehow got wrapped up in the distinction between semantics and metamodels. It's mostly over my head. But in the midst of it, Marlon Dumas, one of a handful of BPM academics worth listening to, pushed one of my buttons when he repeated the familiar charge that the semantics of BPMN are "vague". He specifically referenced the OR-gateway used as a join. Now the semantics of that construct never seemed vague to me, so I asked him to elaborate.

He pointed me to this paper, and specifically the diagram shown below.


I am the first to admit that this diagram is a bit strange, and what I would call in my BPMessentials training bad BPMN practice. Looping back into the middle of a parallel split/join block is not a good idea. I wouldn't object if the BPMN spec said it was illegal to do so or even advised against it. But "vague"? No, it is not vague.

The behavior of the OR-gateway on the initial pass is clear. It waits for both parallel paths to complete. The issue is the possible iterated pass if the loopback occurs. Should the OR-gateway "wait" for the other path? Of course not. No one would think that it should. So in my view the execution semantics are not vague at all. That is to say there is no dispute over the intended behavior. The issue is how to translate it into executable code. The point of the paper, in my simplistic view, is that writing that code is tricky. It can't just translate a BPMN OR-gateway shape into some bit of code, but needs to consider the diagram as a whole. That's fair, and you could say the same about other parts of BPMN as well. This is why BPMN-BPEL roundtripping is so hard.

Will a UML-based metamodel in BPMN 2.0 make the semantics here any clearer? No, but they were never unclear to begin with. Will they make the executable code generator easier to write? I can't answer that.