In a recent post I discussed the utility of allowing the calledElement attribute of a BPMN Call Activity to be an expression that evaluates to a QName (in BPMN's special usage, a prefixed id) rather than a literal QName value. Tom Debevoise asked what that might look like in the XML and I offered something off the top of my head. But on further reflection, I don't think that would work. Here is something that has a better chance.
The BPMN xsd defines the tFormalExpression datatype as a mixed complex type, so it cannot be used for an attribute; it must be a child element, and, until the BPMN 2.0 schema changes, it would have to be an extension element in a separate namespace. Fortunately, the calledElement attribute is optional in the schema, so we can omit it. Let's call the extension element e:calledElement, where the prefix e: means the extension namespace.
Assume we want to call some variant of the process Handle Compliance identified by a data object in the calling process named code. We'll assume all the variants are defined in the same target namespace as the calling process. Prior to the call, the calling process needs to populate the data object with the code value. The simplest way to do it is to make the code value the id of the called process variant. In that case, serialization of the indirect call activity would then look something like this:
<callActivity id="myIndirectCall" name="Handle Compliance"> <extensionElements xmlns:e="http://example.org"> <e:calledElement language="http://www.w3.org/TR/xpath/" evaluatesToTypeRef="xsd:QName"> concat("tns:",getDataObject("code")) </e:calledElement> </extensionElements> </callActivity>where tns designates the targetNamespace. getDataObject is a special XPath function, discussed in the BPMN spec, that returns the value of a data object referenced by name.
This should be schema-valid, but of course the BPMN engine would have to understand the intended behavior.