Event Listeners without a defined Event (User or Timer) are concrete elements and can be added to CMMN models.
However, the execution semantics are not clear.
Is the listener immediately triggered since there is nothing to wait for? Or does it wait indefinitely since there is nothing to wait for?
[the former would be preferable]

There are modeling styles that would use empty Event Listeners and it should be made clear if this is valid for execution.

In spec text and meta-model the Diagram Interchange attributes fillColor, strokeColor and fontColor are spelled with a lowercase first letter. However, in the XML Schemal they are spelled with an uppercase first letter: FillColor, StrokeColor and FontColor.

Proposal:
Adjust spelling in text and MM, because XSD is already implemented and in use.

All initial transitions (create transitions) contain "create" trigger/event. It's illegal according to UML specification (State Machines).
We could use "/create" instead to specify what kind of behavior is executing while transiting from initial node to the first state e.g. Active.

I was wondering why the stage autocomplete doesn't take into account the event listeners. At some point in time, it might be possible that a stage has no active children, but an event is still waiting for something. So in this case, I would expect that the stage doesn't autocomplete until the event has happened.

Is there a reason why this is implemented otherwise?

Figure 7.4 'CMMN Shape' shows an attribute isExpanded instead of isCollapsed, which is described in spec text, tables and XML schema.

Proposal:
In Figure 7.4 on page 85 (PDF 101) replace attribute isExpanded with isCollapsed.

Problem Desciption

The condition expression of ManualActivationRules, RequiredRules and RepetitionRules is optional as shown in Figure 5.13 (PlanItemControl class diagram) on page 50 (PDF 66).
Therefore, CMMN has to define default behaviors for two cases:

1. A ManualActivationRule, RequiredRule and RepetitionRule is not present at all
2. A ManualActivationRule, RequiredRule or RepetitionRule is present, but has no condition expression defined.

The following sentences seem to define a default for case 2 in Table 5.49 (PlanItemControl attributes and model associations) on page 50 (PDF 66):

"A ManualActivationRule comprises of an Expression that MUST evaluate to boolean. If no ManualActivationRule is specified, then the default is considered “true.”"

However, instead of defining the behavior for a missing condition expression (case 2), it talks about the marker itself and thereby accidentally makes all tasks and stages manual by default if they don't have the manual activation marker (case 1).
This is completely contradicting the meaning of the manual activation marker: It would mean that a task can only be activated automatically, if it has a ManualActivationRule with a condition set to "false". By having a ManualActivationRule that task also gets the manual activation marker although it is activated automatically. On the other hand a task that has no ManualActivationRule would not get the manual activation marker although it is activated manually.

Similar sentences are correct for case 1, but fail to define a default for case 2 in Table 5.49 (PlanItemControl attributes and model associations) on page 51 (PDF 67):

"A RequiredRule comprises of an Expression that MUST evaluate to boolean. If no RequiredRule is specified, the default is “false.”"

"A RepetitionRule comprises of an Expression that MUST evaluate to boolean. If no RepetitionRule object is specified, the default is “false.”"

Furthermore, there is a cardinality mismatch between Tables 5.50, 5.51 & 5.52 and MM/XSD for conditions of ManualActivationRules, RequiredRules and RepetitionRules

Recomendation

This issue has been confirmed by people that worked in the CMMN specification. In particular: Mike Marin (IBM), Denis Gagné (Trisotech), Henk de Man (VDMbee), Ralf Mueller (Oracle) and Falko Menge (Camunda). They expect to see this issue fixed in the next CMMN version. In the meantime, they encourage all implementers and users of CMMN to read "false" instead of "true" in the description of attribute manualActivationRule in CMMN 1.1 Table 5.49 (PlanItemControl attributes and model associations), because the current specification text can lead to misinterpretations. Correct behavior is described in the following image:

Proposal for Specification Text

In Table 5.49 (PlanItemControl attributes and model associations) on page 50 (PDF 66):

replace the following sentence:

"If no ManualActivationRule is specified, then the default is considered “true.”"

with:

"If no ManualActivationRule is specified, then the default is considered “false.”"

In Table 5.50 (ManualActivationRule attributes) on page 52 (PDF 68):

Replace "Expression[1]" with "Expression[0..1]".
Add the following sentence to the description of the attribute condition:

"If no Expression is specified, then the default is considered “true.”"

In Table 5.51 (RequiredRule attributes) on page 52 (PDF 68):

Replace "Expression[1]" with "Expression[0..1]".
Add the following sentence to the description of the attribute condition:

"If no Expression is specified, then the default is considered “true.”"

In Table 5.52 (RepetitionRule attributes) on page 53 (PDF 69):

Replace "Expression[1]" with "Expression[0..1]".
Add the following sentence to the description of the attribute condition:

"If no Expression is specified, then the default is considered “true.”"

Meta Model and XML schema use condition with lowercase c whereas Table 5.51 uses an uppercase C.

Proposal:
In Table 5.51 - RequiredRule attributes on page 52 (PDF 68) replace "Condition" with "condition".

It may be useful to be able to define the Performer for task of type Process and Case

When visually modeling it is often desired to have a planItem react to multiple standard events (e.g. when a certain caseFileItem is created or update or addchild or removechild etc. do this).
Presently it is required to visually depict multiple copies of the caseFileItem with a separate onPart for each of the Standard events we want to react to because onPart can only have one standard event.
It is proposed to allow onPart to have multiple standard events defined all of them in a disjontion (e.g. created OR addchild OR removechild or etc.)

With repeating tasks (symbol *|||*) there are situations, where you want to restrict the number of task instances being "active" (or "not in a terminal status") at a given time.

Attached is a CMMN model example:
Whenever the entry Sentry is satisfied (e.g. data "Grundstücke" is updated) the model creates a new instance of task "Objektbewertung". Without a restriction every data change triggers the creation of a new task instance, which in this case you want to restrict.
The idea here is to have exactly one task which handles all last changes on the referenced data "Grundstücke".

Solution 1:
Would there be the need for an additional attribute like "multiplicity" (on repeating tasks only?), set to "exactlyOne" or similar, to implement the desired behaviour. (One can think of more complex restriction / settings here, but we leave it to that for now.)

Solution 2:
Or can this be handled in the RepetitionRule of "Objektbewertung" itself: with Introspection in the runtime model --> get "active" instances of task "Objektbewertung" and depending on that --> RepetitionRule evaluates to true or false --> control if further instances can be created

Harald

Re-evaluating the repetition rule every time the entry criteria of a repeating Task, Stage, or Milestone is satisfied

This proposal is to re-evaluate the repetition rule every time the entry criteria of a repeating Task, Stage, or Milestone is satisfied. This will allow people to control both the number of repetitions (by having a counter) and concurrent repetitions (by introspection of the runtime for concurrent instances – assuming implementers provide a way to do so). In both cases, race conditions can occur, and implementers must provide a way to deal with them (a potential implementation may want to serialized the evaluation of repetition rules).
Note that in this proposal several statements mix repetition rule and required rules. To avoid mixing proposals, the sentences with required rule were treated as if issue 23 and proposal 52 does not exist.

Relevant paragraphs in the specification:

Section 5.4.11.3 RepetitionRule, page 42. Add a third statement as follows as follows:

A RepetitionRule specifies under which conditions Tasks, Stages, and Milestones will have repetitions. Each repetition is a new instance of it. The first instantiation is not considered a repetition. The trigger for the repetition is a Sentry, that is referenced as entry criterion, being satisfied, whereby an OnPart of that Sentry occurs. For example: A Task might be repeated each time a certain document is created. The Task (as PlanItem) might have an entry criterion, referring to a Sentry, having on OnPart, whereby the onPart refers to the CaseFileItem that represents the type of document, and whereby the standardEvent of the OnPart is specified as “create.” When the RepetitionRule as contained in the PlanItemControl of the Task (as PlanItem) also evaluates to “true,” the Task is repeated upon creation of the document.

Section 5.4.11.3 RepetitionRule, Table 5.42 - RepetitionRule attributes, cell (2,4) condition : Expression[1], page 43, second paragraph. Reads:

An Expression that MUST evaluate to boolean. If the Expression evaluates to “true,” then the instance of the Task, Stage, or Milestone maybe repeated, otherwise it MUST NOT be repeated.

Leave alone.

Section 7.4.2 Stage and Task Lifecycle, Table 7.8 - Stage and Task instance transitions, cell (4, 2), page 72. The sentence that reads:

The RepetitionRule and the RequiredRule Boolean expressions MUST be evaluated in this transition, and its Boolean values SHOULD be maintained for the rest of the life of the Stage or Task instance.

Change as follows:

The RepetitionRule Boolean expression MUST be evaluated in this transition. and t The RequiredRule Boolean expression s MUST be evaluated in this transition, and their Boolean value s SHOULD be maintained for the rest of the life of the Stage or Task instance.

Section 7.4.3 EventListener and Milestone Lifecycle, Table 7.11 - EventListener and Milestone instance transitions, cell (4,2), page 77. The sentence that reads:

For a Milestone instance, the RepetitionRule and RequiredRule Boolean expression MUST be evaluated in this transition, and its Boolean value SHOULD be maintained for the rest of the life of the Milestone instance.

Change as follows:

For a Milestone instance, the RepetitionRule Boolean expression MUST be evaluated in this transition. and For a Milestone instance, RequiredRule Boolean expression MUST be evaluated in this transition, and their Boolean value SHOULD be maintained for the rest of the life of the Milestone instance.

Section 7.6.4 RepetitionRule, page 79. Reads:

This rule MUST be evaluated when the Milestone, Stage, or Task instance is instantiated and transitions to the Available state, and their Boolean value SHOULD be maintained for the rest of the life of the Milestone, Stage, or Task instance.

Stage and Task instances with a RepetitionRule evaluating to “true” will create an instance every time an entry criterion with an onPart is satisfied. Under that condition a new instance is created and because the entry criteria is satisfied it moves from the Available state to either Active or Enabled state depending on the ManualActivationRule.

Change as follows:

This rule MUST be evaluated when the Milestone, Stage, or Task instance is instantiated and transitions to the Available state , and their Boolean value SHOULD be maintained for the rest of the life of the Milestone, Stage, or Task instance . The first time, a Milestone, Stage, or Task instance is instantiated and transitions to the Available state, it is not considered a repetition, nevertheless the RepetitionRule MUST be evaluated and its result discarded.

Stage and Task instances with a RepetitionRule evaluating to “true” will create , will try to create an a new instance every time an entry criterion with an onPart is satisfied. Under that condition the RepetitionRule is re-evaluated and if the Expression evaluates to “true,” then a new instance is created and because the entry criteria is satisfied it moves from the Available state to either Active or Enabled state depending on the ManualActivationRule.

To account for other issues and proposals in this last ballot (CR74, CR131, and CR140 – proposals CR129, CR132, CR145), we need to make minor corrections and changes to the Diagram interchange proposal (issue CR21 proposal CR102) that was already approved. The main change is to fix the depictions to be consistent with proposals CR129, CR132, CR145 is this ballot.

New updated DI Chapter

Changes to the DI proposal approved in issue 21 are needed to reflect changes that came after.
For simplicity and convenience a new DI chapter is attached containing all these changes applied.

1. Given that Issue 74 (Proposal 129) was deferred, in “Table 7.9 Depiction for PlanItem and DiscretionaryItem” we removed the provided depictions for Discretionary Milestone, Discretionary EventListner, Discretionary UserEventListner and TimeEventListener and replaced them by N/A
2. With the introduction of Artifacts and Associations at Issue 131 (Proposal 132), many changes were done to the DI chapter. These changes are all applied in the attached convenience document. Namely:
   1. Section 7.4.6 CMMNShape. Second paragraph changed as per proposal 132
   2. Section 7.4.6 CMMNShape, Table 7.4 - CMMNShape attributes, cell (2, 3). Paragraph changed as per proposal 132
   3. Section 7.4.7 CMMNEdge. Figure 7.3 was replaced as per proposal 132
   4. Section 7.4.7 CMMNEdge. Second paragraph changed as per proposal 132
   5. Section 7.4.7 CMMNEdge. Paragraph after the fourth paragraph as per proposal 132
   6. Section 7.4.7 CMMNEdge, Table 7.5 - CMMNEdge attributes, cell (2, 3). First paragraph changed as per proposal 132
   7. Section 7.4.7 CMMNEdge, Table 7.5 - CMMNEdge attributes, cell (2, 4). First paragraph changed as per proposal 132
   8. Section 7.4.7 CMMNEdge, Table 7.5 - CMMNEdge attributes, cell (1, 5). Changed as per proposal 132
   9. Section 7.4.7 CMMNEdge, Table 7.5 - CMMNEdge attributes, cell (2, 5). New paragraph added before first paragraph as per proposal 132
   10. Section 7.5.2 CMMNShape Resolution. New sub-section: 7.5.2.9 Artifacts added as per proposal 132
   11. Section 7.5.3 CMMNEdge Resolution. New sub-section: 7.5.3.4 Association added as per proposal 132
3. Furthermore, with the introduction of Association, we wanted Association to be depicted as dotted line to be aligned with BPMN, thus we had to change the depiction of OnPart
   1. Figure 7.6 OnPart connector displaying the OnPart name and the Standard Event was changed for the new depiction
   2. Table 7.17 Depiction Resolution of OnPart connector referring to a CaseFileItemOnPart, cell(5,2) and cell (5,3), both changed for the new depictions
   3. Table 7.18 Depiction Resolution of OnPart connector referring to a PlanItemOnPart, cell(5,2) and cell (5,3), both changed for the new depictions

With the introduction of Association, we want Association to be depicted as dotted line to be aligned with BPMN, thus we have to change the depiction of OnPart

Change OnPart connector to a "dash-dot-dot" style

1. Update the text in section 6.11.1 (introduced by CR-95)
2. Update figures in chapter 6

We need to make changes to the approved proposal for Issue 20 (vendor extensions - proposal CR66). The revised text of the approved proposal 66 mention a figure that was not included in the proposal. There is no changes to the text of the approved proposal, just to the list of instructions on how to apply the proposal in the revised text.

Editorial to section 5.1.5

We need to make changes to the approved proposal in Issue 20 (vendor extension - proposal 66).
Item 7 of the proposal CR 66 states:

• 7. Figure of the meta model should be inserted at the end of section 5.1.5 just before talking about Relationship. Relationship is a new class that extends CMMNElement and is related to the Definition

There is no meta model figure to be inserted at the end of section 51.5.
The rest should be as proposed in proposal CR 66

CMMN lacks elements to hold modeler-provided annotations in the diagram. These help clarify the meaning of the model but otherwise have no operational semantics. In BPMN they are called "artifacts". See attached BPMN Meta Model figures for comparison.

Add artifacts textAnnotation and association (connector) to notation, metamodel and xsd

The proposed annotation elements are essentially copied from BPMN 2.0.

There are situations in which users may want to repeat a Task or Stage that has no entry criterion. Currently, the specification requires that a repetition rule can only be placed in a Task or Stage that has a entry criterion with an onPart.

Repeat Task/Stage without entry criteria upon completion of previous instance

This proposal extends the proposal CR-130 to allow repetition of Tasks or Stages without entry criteria. In this case, the evaluation of the repetition rule and creation of new instances happens, when the previous instance completes or terminates.

In a nutshell this scenario works like a do while loop in programming languages. Or speaking in terms of CMMN, one could think of it as an implicit onPart pointing to itself, which is ignored for the first instance.

All the relevant paragraphs in the specification

Section 5.4.11 PlanItemControl, Figure 5.12 - PlanItemControl attributes and associations, cell (2,4), page 41 (PDF 55)

Third paragraph can be deleted completely, as the alternative semantics do work for DiscretionaryItems:

A PlanItemControl that is the itemControl of a DiscretionaryItem, MUST NOT contain a RepetitionRule. (This is because the concept of “repetition” depends on the semantics of Sentries (see 5.4.11.3), and DiscretionaryItems are not associated with Sentries.)

Fifth paragraph:

A PlanItem that has a PlanItemControl that contains a RepetitionRule, MUST have either an entry criterion that refers to a Sentry that has at least one OnPart or no entry criteria at all. (This is because the concept of “repetition” depends on the semantics of Sentries with onParts (see 5.4.11.3)).

Section 5.4.11.3 RepetitionRule, page 42 (PDF 56)

The trigger for the repetition is a Sentry, that is referenced as entry criterion, being satisfied, whereby an OnPart of that Sentry occurs.

New text after first paragraph:

Alternatively, a RepetitionRule MAY be used on a Task or Stage that does not have any entry criteria. In that case, the RepetitionRule is evaluated when an instance of the Task or Stage completes or terminates. If it evaluates to "true", a new instance will be created.

Section 7.4.2 Stage and Task Lifecycle, Table 7.8 - Stage and Task instance transitions, transition complete, cell (4, 9), page 73 (PDF 87)

New text at the end:

If the Task or Stage has a RepetitionRule but no entry criteria, the RepetitionRule Boolean expression MUST be re-evaluated in this transition and if the expression evaluates to “true”, a new instance is created.

Section 7.4.2 Stage and Task Lifecycle, Table 7.8 - Stage and Task instance transitions, transition terminate, cell (4, 10), page 73 (PDF 87)

New text at the end:

If the Task or Stage has a RepetitionRule but no entry criteria, the RepetitionRule Boolean expression MUST be re-evaluated in this transition and if the expression evaluates to “true”, a new instance is created.

Section 7.6.4 RepetitionRule, page 79 (PDF 93)

text of CMMN 1.0:

This rule MUST be evaluated when the Milestone, Stage, or Task instance is instantiated and transitions to the Available state, and their Boolean value SHOULD be maintained for the rest of the life of the Milestone, Stage, or Task instance.

Stage and Task instances with a RepetitionRule evaluating to “true” will create an instance every time an entry criterion with an onPart is satisfied. Under that condition a new instance is created and because the entry criteria is satisfied it moves from the Available state to either Active or Enabled state depending on the ManualActivationRule .

revised text of CR-130:

This rule MUST be evaluated when the Milestone, Stage, or Task instance is instantiated and transitions to the Available state. The first time, a Milestone, Stage, or Task instance is instantiated and transitions to the Available state, it is not considered a repetition, nevertheless the RepetitionRule MUST be evaluated and its result discarded.

Stage and Task instances with a RepetitionRule, will try to create a new instance every time an entry criterion with an onPart is satisfied. Under that condition the RepetitionRule is re-evaluated and if the Expression evaluates to “true,” then the new instance is created and because the entry criteria is satisfied it moves from the Available state to either Active or Enabled state depending on the ManualActivationRule.

New text after second paragraph:

Stage and Task instances with a RepetitionRule that do not have any entry criteria, will try to create a new instance every time an instance transitions into the Complete or Terminate state. Under that condition the RepetitionRule is re-evaluated and if the Expression evaluates to “true,” a new instance is created.

With the approval of issues CR-20 Diagram interchange and CR-87 Decision Tasks (which added a new compatibility conformance) table 2.1 needs to be updated.
Table 2.1 needs to be updated as follows:

• add a DMN Compatibility Conformance column
• add sections 2.5, 6.8.4.1 and fill appropriate
• correct for the section shift after CR-20 added moved section 7 to 8

Update Table 2.1

Current table after approval of CR 20 and CR87 looks as follows:

It is currently not obvious to a modeler how to depict/express some desirable Task execution patterns such as Exclusive Choice, Inclusive Choice, etc. or even more advanced patterns such as Racing Conditions. We should ensure that CMMN provides the required expressiveness to a select set of such patterns both in the MM and via the Notation

defer Expressiveness of Task patterns

defer Expressiveness of Task patterns to next revision

It may be desirable for a modeler to be able to depict Inputs and Outputs to Task

Defer depict Inputs and Outputs to Task

Defer depict Inputs and Outputs to Task to next revision

It may be misleading to a modeler what the purpose of an Exit Criterion may be. Many may think these are conditions under which a Task may Complete when in fact these are conditions under which a Task be Terminated (interrupted)

Defer: Exit Criterion may be misleading

deferred

The following people were involved in the Case Diagram example on page 64, figure 6.63 of the spec:

• Torsten Winterberg (Opitz Consulting)
• Danilo Schmiedel (Opitz Consulting)
• Juergen Kress (Oracle)
  and hence should be mentioned in section 4.4 of the spec

Add contributors to section 4.4 of the spec

Add contributors to section 4.4 of spec

In section 5.4.9.2 you can read “A Stage MUST NOT be discretionary to itself or its nested Stages.” But no similar sentence can be found for Human Task.

Add sentence to prevent Human Task from being discretionary to itself

In section 5.4.9.2 after the sentence “A Stage MUST NOT be discretionary to a HumanTask that is PlanItemDefinition of a PlanItem that is contained by the Stage or its nested Stages.”, add the following paragrah:

A HumanTask MUST NOT be discretionary to itself.

Currently, entry and exit criteria are just a list of sentries references. Since these criteria are depicted in a CMMN diagram, it would be easier to refer them if they had their own ids. To do so, they should become first class citizen that inherited CMMNElement. This would also allow to use an exitcriterionRef in PlanItemOnPart instead of a Sentry ref (which was the original intention anyway.)

Create classes to hold entry and exit criterion references

1. Modify figure 5.6 to include Criterion, EntryCriterion and ExitCriterion classes
2. Modify table 5.18
3. Add section 5.4.5.1 Criterion
4. Add section 5.4.5.2 Entry Criterion
5. Add section 5.4.5.3 Exit Criterion
6. Modify figure 5.8
7. Modify table 5.26
8. Modify figure 5.7
9. Modifiy table 5.22
10. Modify XSD to add new elements entryCriterion and exitCriterion
11. Modify tPlanItem complexType in the XSD
12. Modify tStage complexType in the XSD
13. Modify tPlanItemOnPart in the XSD

Currently, OnPart only have an id and description. Since they can be depicted on a diagram with a connector, it would be useful to be able to name them and to potentially use that name on the label of the connector.

Add name attribute to OnPart

1. Modify Figure 5.7 to add “name” in the OnPart class
2. Modify section 5.4.6.1 to add a table with the name attribute after the text
3. Modify CMMN10CaseModel.xsd to add name to tOnPart

The meta-model specifies that the IfPart of a Sentry can have 0..1 condition. However, in the XSD, an IfPart can have 0…* condition.

Change cardinality of tIfPart

1. In tIfPart complex type, replace sequence with the following:
<xsd:sequence>
<xsd:element name="condition" type="tExpression" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>

In figure 5.10 representing the Task metamodel, the class Process has a “name” attribute. However, in table 5.37 listing the process attributes, name is not listed.

Add attribute “name” to the process attributes in table 5.37

1. Add this row to table 5.37

ProcessTask refers to a Process defined in the definitions. But this Process element doesn't have any field to relate to the external process.

Add externalRef to Process class

1. Modify figure 5.1
2. Modify table 5.37
3. Modify CMMN10CaseModel.xsd

Figure 6.43 and 6.47 were not changed by the original proposal.

Update figure 6.43 and 6.47

1. Replace figure 6.43
2. Replace figure 6.47

Section 5.4.9.2 DiscretionaryItem clearly states that DiscretionaryItem can have entry/exit criteria. However, those attributes are not part of tDiscretionaryItem complextType in CMMN10CaseModel.

Changes applied by CR-99 will fix this issue

Changes applied by CR-99 will fix this issue

The PlanningTable on HumanTask "Create Claims Notification" is confusing since it is shown expanded but the HumanTask doesn't have any DiscretionaryItem.

Change applied to CR-76 will resolve this issue

Resolution 106 solve this issue.

Currently, the same “connector” is used to depict a link between a Discretionary task and its User Task and OnParts. A new connector should be introduce so those two different meaning have a different representation.

Add a new discretionary association

1. Rename section 6.11 from “Connectors” to “Links”

2. Replace the first paragraph of section 6.11 with the following:
Certain dependencies between elements that are shown inside expanded Stages or PlanFragments are depicted using links. The shape of the connector object is a dotted line. The connector MUST not have arrowheads.

3. Remove figure 6.29

4. Modify the second paragraph of 6.11 to be the following:
One such depicted dependency is the onPart of a Sentry. Those dependencies are depicted using a connector. This connector is a dotted line. The connector MUST not have arrowheads. For example, the following diagram illustrates a situation where the entry criteria of Task B depends on the completion of Task A.

5. Place figure 6.29 after that paragraph

6. Before figure 6.30 and after figure 6.29 add the following paragraph:
For example, the following diagram illustrates a situation where the entry criteria of Task B depends on the completion of Task A.

7. Modify the third paragraph of 6.11
The other type of dependency that is visualized is the dependency between a HumanTask and DiscretionaryItems in its PlanningTable, when the HumanTask is shown with its PlanningTable expanded. These dependencies are also depicted by the same dotted line connector depicted with a discretionary association. A Discretionary Association is a dashed line. The line MUST not have arrowheads.

8. Add a new figure to show the new link

Figure 6.31 - Discretionary Association

9. Change actual figure 6.31 for the following

Figure 6.32 - Dependency between a blocking HumanTask and its associated Discretionary Tasks

In many cases involving case workers a decision support will be required to either establish a conclusion or make a decision.
We should add a Decision type task as in BPMN which could for example call a DMN decision.

Add Decision Task to model and schema

Model, XML-schema and spec text changes to support Decision Task

In figure 6..63 - Claims Management Example there should be a PlanningTable on the CasePLanModel in the expanded status as there are discretionary tasks showing in that CasePlanModel.

The Stage "Identify Responsibilities" has a planing table showing in the expanded state but that stage does not show discretionary task(s) which is questionable.

Replace figure 6.63

1. Replace figure 6.63

Stages and Tasks (generalizations of PlanItemDefinitions) have discretionary notations (dashed lines), but Milestones and EventListeners (also generalizations of PlanItemDefinitions) don't have discretionary notations.
Reading the specification seems like all PlanItemDefinitions can be discretionary, but there is no notation shown for Milestones and EventListeners.
There is no written limitation in the specification that prevents Milestones and EventListeners from being discretionary.
The ability to model discretionary milestones is important in situations where other discretionary items are added.

Add notational element for discretionary Milestones and discretionary EventListeners

Stages and Tasks (generalizations of PlanItemDefinitions) have discretionary notations (dashed lines), but Milestones and EventListeners (also generalizations of PlanItemDefinitions) don't have discretionary notations. Reading the specification seems like all PlanItemDefinitions can be discretionary, but there is no notation shown for Milestones and EventListeners. The ability to model discretionary milestones is important in situations where other discretionary items are added.

Section 5.4.7 Expressions (page 28). State that "Expressions specify String objects that are evaluated over information in the CaseFile." This sentence leaves out simple constant expressions like "true", "12", or "Mike".

The sentence in Section 5.4.7 also contradicts the description of timerExpression in table 5.13 (page 19) "An expression string that is conforming to the ISO-8601 format for date and time, duration, or interval representations."

The sentence in section 5.4.6 Sentry (page 24) states that " The IfPart specifies a condition, as Expression that evaluates over the CaseFile." That seems correct, but maybe over-specified.

Fix expression description to allow constant expressions

Section 5.4.7 Expressions (page 28). State that "Expressions specify String objects that are evaluated over information in the CaseFile." This sentence leaves out simple constant expressions like "true", "12", "Mike", or time expressions.

Change first sentence in Section 5.4.7 Expressions (page 28), as follows:

Expressions specify are String objects. Expressions operate over Properties and CaseFileItems that are evaluated over information in the CaseFile. In addition to CaseFile content, constant expressions are also allowed. Expressions do also specify the language in which the String objects MUST be specified.

To clearly reflect the intent of a case style application - it is essential to provide business context. Central to that context is who does (or is responsible for) what. The existing model definition does not facilitate a clear graphical context to roles / swimlanes.
The absence of this visual and execution definition will likely severely limit the clarity and ease of use of CMMN thereby restricting it's utility and adoption.

Swimlanes is a new feature and it is out of the scope for the RTF

The introduction of swim lanes is a complete new feature that will require more work that intended by an RTF, and so it is out of the scope of the RTF. However this feature should be considered during the next revision of the specification.

Note that it is possible for implementers to add swim lanes to a compliant CMMN implementation, because the specification is silent about swim lanes.

Task, as Case and Process, holds a list of input and a list of output. For Case an Process, input and output is used for every entry while Task use inputs and outputs, which is wrong.

Remove "s" to input/output of tTask in the XSD

1. In tTask complex type change

<xsd:element name="inputs" type="tCaseParameter" minOccurs="0" maxOccurs="unbounded" /> 
<xsd:element name="outputs" type="tCaseParameter" minOccurs="0" maxOccurs="unbounded" /> 

to

<xsd:element name="input" type="tCaseParameter" minOccurs="0" maxOccurs="unbounded" /> 
<xsd:element name="output" type="tCaseParameter" minOccurs="0" maxOccurs="unbounded" /> 

The Spec states that Applicability Rule have a "name" attribute but this attribute is missing in CMMN10CaseModel.xsd

Add attribute name to tApplicabilityRule

Add the following to tApplicabilityRule just before the contextRef attribute:

<xsd:attribute name="name" type="xsd:string"/>

The specification and the meta-model states that UserEvenListener have an authorizedRoleRefs attribute, but this attribute is missing in the CMMN10CasePlanModel.xsd

Add authorizedRoleRefs attribute to tUserEventListener

Add the following to tUserEventListener inside the extension block:

<xsd:attribute name="authorizedRoleRefs" type="xsd:IDREFS">
    <xsd:annotation>
        <xsd:documentation>authorizedRoleRefs refers zero or more "role" elements.</xsd:documentation> 
    </xsd:annotation>
</xsd:attribute>

CMMN needs to support Diagram Interchange

Given that a notion was provided a diagram interchange capability is missing

New chapter, MM, and Schema(s) providing CMMN Diagram Interchange Capability

1. Add Chapter 7
2. Update chapters numeration
3. Update CMMN1.0.xsd
4. Update Distribution Package
5. Update Normative References
6. Update figure 5.1
7. Update table 5.2
8. Update the CMMN Meta-Model

Suppose we have the following case definition, expressed in XML.
<definitions>
<case name="stages" xmlns="http://www.omg.org/spec/CMMN/20121031/MODEL">
<caseRoles />
<input />
<output />
<caseFileModel />
<casePlanModel name="casePlan">
<planItem name="Stage1" definitionRef="Stage" />
<planItem name="Stage2" definitionRef="Stage" />

<planItem name="Milestone1" definitionRef="Milestone" entryCriteriaRefs="Task1Completed" />
<sentry name="Task1Completed">
<planItemOnPart sourceRef="Task1">
<standardEvent>Complete</standardEvent>
</planItemOnPart>
</sentry>

<stage name="Stage">
<planItem name="Task1" definitionRef="Task" />
</stage>
<milestone name="Milestone" />
<humanTask name="Task" />
</casePlanModel>
</case>
</definitions>

Within this case, we have a Milestone1, with an entry criterion referring to Sentry called Task1Completed.
Task1 is a plan item within Stage, hence can be referenced from the sentry.

At runtime, however, there will be 2 instances of Task1: one in Stage1, and another within Stage2 (as both have the same stage definition).

The specification does not say anything as to which instance plan item the sentry refers, making it ambiguous. Well ... in page 26, at SentryRef, the specification says that the sentry ref must refer to a plan item within the same stage. However, this is conflicting with the image on page 64, as indicated in the issue logged as "CMMN spec inconsistent with respect to Sentry dependencies crossing Stage boundaries"

Duplicate of issue CR-7

Duplicate

Table 5.22 says, with respect to the sourceRef attribute: "SourceRef represents a PlanItem that MUST be contained by the same PlanFragment (or Stage) that also contains theSentry that contains the PlanItemOnPart."

This implies that sentry-based dependency cannot cross stage boundaries, which is in conflict with what is suggested by the claims management example in Figure 6.63.

The solution should be to remove the constraining text from Table 5.22.

A similar constraint is found (and must be removed) on page 32 in the section 5.4.9.2 DiscretionaryItem

"When entryCriteriaRefs or exitCriteriaRefs of a DiscretionaryItem have OnParts that are PlanItem
OnParts, these OnParts MUST have a sourceRef that is contained
• in the Stage that also contains the PlanningTable that contains the DiscretionaryItem, directly or recursively
through a hierarchy of PlanningTables, or
• in the Stage that also contains the HumanTask that has the PlanningTable that contains the DiscretionaryItem,
directly or recursively through a hierarchy of PlanningTables."

Allow Sentry to cross Stage boundaries for PlanItems only (not for Discretionary Items)

• We'd like to allow sentries to cross Stage boundaries

The statement "PlanItemDefinitions MUST NOT be contained by any
other Stage than the casePlanningModel of the Case." impose an undesired limitation of having all PlanItemDefinitions in the casePlanningModel.

This imposes all kind undesired references. Simply removing this sentence will allow for local definition of PlanItemDefinitions and reduce potential for referential integrity problems.

*Remove limitation on PlanItemDefinitions, add a constraint for scoping of PlanItem, and add an example of scoping *

1. In table 5.18 in the definition of defintionRef, add a sentence explaining constraints on PlanItem
2. Add a new section 5.4.5.1 containing an example explaining the constraints on PlanItem
3. Remove first bullet at top of page 29
4. In table 5.26, modify the description of planItemDefinition
5. In table 5.29 add a sentence to definitionRef description
6. Add example in section 5.4.9.2
7. Add paragraph at the end of section 5.4.1

In Table 7.8, Transition "create", the Description says: "The RepetitionRule and the RequiredRule Boolean expressions MUST be evaluated in this transition, and their Boolean values SHOULD be maintained for the rest of the life of the Stage or Task instance".

In this Issue we are interested in the usage of the RequiredRule only.

The first part is clear: "The [...] RequiredRule Boolean expression MUST be evaluated in this transition" - so far, so good.

The second part of the sentence needs clarification: "and the Boolean values SHOULD be maintained for the rest of the life of the Stage or Task instance".

Does this mean (1 OR 2):
1) The Boolean expression of the RequiredRule is evaluated ONLY ONCE (in the 'create' transition) and then gets 'frozen' for the rest of the life cycle of the Stage or Task

OR

2) The Boolean expression is evaluated in the 'create' transition AND can be updated by re-evaluating the same RequiredRule-expression at some point(s) during the rest of the life of the Stage or Task? (The re-evaluation might be triggered by any event or item-transition in the case)

Background:
We would like to model an optional Task, which CAN turn to a required Task, while in the state 'Available' or 'Enabled' (because the parent-stage of this (Discretionary) Task is already Active).
The change from optional to required is accomplished with a RequiredRule expression. In our case the change from an optional Task to a required Task should be triggered with an CaseFileItemTransition. Or put it simple: An optional Task changes "suddenly" to 'required' because somebody added a piece of data to the case.

We would appreciate the clarification of the execution semantics of the RequiredRule.

Fix termination criteria for stages

This issue touches in three areas:
First, RequiredRule is evaluated in the creation transition, but it is not clear if it is set only once.
Second, there is a desire to have RequiredRule to be set after creation.
Third, is that the termination criteria in table 7.8 (page 73) is inconsistent with page 79 section 7.6.1 Stage.autoComplete, table 7.12 Stage Instance termination criteria.

Note that to solve the second area, we have two options:
a- try to evaluate RequiredRule of all the milestones, stages, and tasks that are in available or in enabled, when the stage is going to complete. The problem here is that a stage may have a autoComplete false and so a human try to complete it and finds out it cannot be completed because a new required plan item is found. This does not seems right, in addition is expensive to evaluate
b- evaluate RequiredRule when entering Available or Enabled states. Note that after the plan item reaches Active it is required by default, so we only concerned with Available and Enabled states. Today, we do it when it enters Available, so we just need to consider adding this extra evaluation to Enabled state. In the case described in this issue, this will satisfy the situation. The task transition to Available and RequiredRule evaluates to false, but then a new case file item is added to the case, that can trigger the sentry transition to Enabled (or to Active) and we can then evaluate again the RequiredRule. This seems the best option.

Proposal

1- We certainly need to fix the second issue
2- We should also evaluate RequiredRule on entrance to Enabled state (if it is in "false")

Page 72, Table 7.8, column 4, row 2 (enable, Available, Enabled): Add the following sentence (at the end):

If the RequiredRule Boolean expression exists and the current value is "false", then it MUST be re-evaluated in this transition and its Boolean value SHOULD be maintained for the rest of the life of the Stage or Task instance.

Page 73, Table 7.8, column 4, row 8 (complete, Active, Completed): Rewrite as follows:

Transition when the Stage or Task instance completes normally. For a Stage instance, this means that all its child Task and Stage instances have reached a terminal or semi-terminal state (all child Task and Stage instances have reached disabled, terminated, completed, or fault). For a Stage instance the termination criteria described in table 7.12 "Stage instance termination criteria" must be satisfied. For a Task instance, this means its purpose has been accomplished (CaseTask instances have launched a new Case instance; ProcessTask instances have launched a Process instance and if output parameters are required, then the Case or Process instance has completed and returned the output parameters; HumanTask instances have been completed by a human; etc.)

Page 73, Table 7.8, column 4, row 13 last row (re-enable, Disabled, Enabled): Add the following sentence (at the end):

If the RequiredRule Boolean expression exists and the current value is "false", then it MUST be re-evaluated in this transition and its Boolean value SHOULD be maintained for the rest of the life of the Stage or Task instance.

I believe the example on page 64 is incorrect according to the specification. The example depicts sentries listening to events of plan items not contained inside the same stage.

On page 26 following requirement is specified:
'SourceRef represents a PlanItem that MUST be contained by the same PlanFragment (or Stage) that also contains the Sentry that contains the PlanItemOnPart'

e.g. the sentry placed on top of 'Create claim' is contained by 'Process claims' whereas the sourceref('Base information attached') is contained by 'Claims file'

Fixed by CR-106

Resolution is in CR-106

In the class diagram, body is a required element to hold the actual expression. But in the XML, the body is simply the content of the Expression element, no need for another nested element for it.

Remove body from tExpression in CMMN xsd

1)
<xsd:complexType name="tExpression" mixed="true">
<xsd:complexContent>
<xsd:extension base="tCmmnElementWithMixedContent">
<xsd:sequence>
<xsd:element name="body" type="xsd:string" minOccurs="0" maxOccurs="1" />
</xsd:sequence>
<xsd:attribute name="language" type="xsd:anyURI" use="optional" default="http://www.w3.org/1999/XPath" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

In the XSD, we have timerEvent, userEvent and event but in the meta-model, we have timerEventListener, userEventListener and eventListener.

Rename event, timerEvent, and userEvent to eventListener, timerEventListener and userEventListener in the XSD

In CMMN11CaseModel.xsd
1) Rename complexType tEvent to tEventListener
2) Rename element event to eventListener
3) Change the type of eventListener to tEventListener
4) Rename complexType tTimerEvent to tTimerEventListener
5) Change the extension base of tTimerEventListener to tEventListener
6) Rename element timerEvent to timerEventListener
7) Change the type of timerEvent to tTimerEventListener
8) Rename complexType tUserEvent to tUserEventListener
9) Change the extension base of tUserEventListener to tEventListener
10) Rename element userEvent to userEventListener
11) Change the type of userEventListener to tUserEventListener

In section 5.4.11.2 Required rule you can read the following sentence:
“A RequiredRule specifies under which conditions Tasks, Stages, EventListeners, and Milestones will be “required” to complete or terminate before their containing Stage can complete.”

But this is contradict in many places in the spec:
• in table 5.43, it is said that Required rule is N/A for EventListener,
• section 5.4.11 doesn’t apply RequiredRule to EventsListener
• in figure 5.12 you can read the following “A PlanItemControl that is the defaultControl of an EventListener, or that is the itemControl of a PlanItem or DiscretionaryItem that is defined by an EventListener, MUST NOT contain a RequiredRule.”
• table 6.1 listing decorator applicability doesn’t appliy required to Event Listener
• section 7.6.3 doesn’t apply RequiredRule to EventsListener

Remove EventListeners from section 5.4.11.2

In section 5.4.11.2 change the first sentence as followed:
“A RequiredRule specifies under which conditions Tasks, Stages, EventListeners, and Milestones will be “required” to complete or terminate before their containing Stage can complete.”

This is to reverse the resolution to issue CR-42 since we want to allow for underspecified models.
It was accidentally proposed and passed the ballot for issue CR-42

Modify XSD tCaseFileItem and make definitonRef optional

• Make attribute "definitionRef" of complex type "tCaseFileItem" optional again.

The current base class CMMNElement has an attribute "description" of type string. This should be replaced by a Documentation class with attributes text and textFormat to allow documentation of CMMN Elements in various formats (PDF, HTML etc.)

Introduction of Documentation class

• Add new class "Documentation"
• Add new diagram for CMMNElement

Many time the on part will on a file item particular state.
We should allow for the State of a file item to be placed in [Square] brackets making the intention of the modeler more explicit in a CMMN diagram

Solved within the CMMN DI

Nothing to be done solved in CR-21

In table 5.25 – Expression Attributes in CMMN 1.0 specification, it is mentioned that “The language attribute is optional.” But in the XSD, it has a default value of “http://www.w3.org/1999/XPath” so it is always set to something.

Remove default from complexType tExpression attribute "language"

• Remove default value from complexType "tExpression" attribute "language"
• This is identical to what is done in BPMN 2.0 "tFormalExpression"

In table 5.35, it is clearly stated that a HumanTask can have 0 or 1 Planning Table

But the XML XSD of tHumanTask allows 0 or many

minOccurs="0" maxOccurs="unbounded"

The class diagram is fine (0..1)

Modify XSD complextType tHumanTask to allow max. 1 planning table

• Modify complexType "tHumanTask" element "planninTable" to allow 0 or 1 planning table.

pg 16 text and table 5.11 (CaseFileItem attributes) describe how to create hierarchical structures (that could correspond to CMIS folders) using children and parent, but it is not clear the reason for targetRef and sourceRef. Clarification is needed, or they should be removed.
pg 67. getFileItemInstanceTarget and getFileItemInstanceChild have the same description with the only exception that Target or child is used. The same is true for operations getCaseFileItemInstanceSource and getCaseFileItemInstanceParent.

Clarify CaseFileItem containment and references

Clarify CaseFileItem parent child relationships. With the clarification of children/parent and targetRefs/sourceRef the table 7.3 on page 67 should become clear.

According to Chapter 5.4.10.5 ProcessTask, Table 5.36 - ProcessTask attributes, the attribute 'processRef' (a reference to a Process) is required.
The XSD in OMG Document dtc/14-01-01 does not reflect this:
<xsd:attribute name="processRef" type="xsd:QName">

In my opinion is must be:
<xsd:attribute name="processRef" type="xsd:QName" use="required">

The same applies to definitionRef of tCaseFileItem.

So one of the two must be corrected: either the XSD or the class diagram.

Also I am wondering why 'use="optional"' is used at the attributes level quite often. I thought this is the default setting anyway.

Add definitionRef use="required" in XSD definition of tCaseFileItem

1. We should leave processRef optional because of resolution to issue CR-12 (make CaseRef and ProcessRef an expression)

2. Modify the XSD and define attribute "definitionRef" for tCaseFileItem as follows:
<xsd:attribute name="definitionRef" type="xsd:QName" use="required">

Few problems,
a)- xsd has a DefinitionTypeEnum and table 5.4 refer to it as DefinitionType (should be DefinitionTypeEnum). Same is true for table 5.5
b) The specification does not describe how to extend the DefinitionTypeEnum in table 5.5
c) The specification does not describes how to extend the property types described in table 5.7.

Add XML-Schema PropertyType to CMMN10CaseModel.xsd

Proposal is to add a new PropertyTypeEnum XML-Schema enumeration and modify type tProperty

CMMN nees to provide a standard way for vendors to serialize extensions (Vendor Extensions)

It is proposed that a schema resembling what was done in BPMN be used

Add new extension capability to CMMN as per that of BPMN

1. Add two rows to table 5.1
-. Add a new figure of the meta model showing the relation between CMMNElement and extension in section 5.1.1 (This figure comes from resolution CR-71)
2. Add two rows to table 5.2 after imports line
3. Add a row at the end of table 5.2
4. Figure 5.1 – Definitions class diagram need to be updated with Extensions depiction.
5. A complete new section 5.1.5 Extesibility need to be added. This will have a ripple effect on table and figure numbering
6. Figure of the meta model should be inserted after first para of section 5.1.5, in the meta model we need to add the four classes described
7. Figure of the meta model should be inserted at the end of section 5.1.5 just before talking about Relationship. Relationship is a new class that extends CMMNElement and is related to the Definition
8. Some changes needed to CMMN.xsd
9. Some changes needed to CMMNCaseModel.xsd

According to the specification, a timereventlistener can have a timerexpression (ISO-8601 format) and a starttrigger (event).

What I seem to be missing here is the following:
In the data of a case, I can enter a date (e.g. in a certain task). I would like to set the timer to trigger at the date (or duration) specified in the data.

This does not seem possible when following the specification. Only a fixed time or duration can be entered.

*Modify table 5.13 attribute timerExpression to be of type Expression *

1. The timerExpression attribute in Figure 5.5 should be defined as follows

timerExpression : Expression
with the following text

"An expression that MUST evaluate to an ISO-8601 conforming representation for date, time, duration or interval."

2. We need to modify the metamodel and add an Expression class right to TimerEventListener and timerExpression becomes an association from TimerEventListener to Expression

In section 7.5 it is stated that if a sentry has only an IfPart, and it's condition evaluates to true, then the sentry is satisfied.

However, it is not specified WHEN the IfPart should be evaluated. Most logical seems when the plan item that refers to the sentry in an entry or exit criterion becomes Available.

Also, it will be great if it is stated that the outcome of the IfPart should be preserved during the rest of the lifecycle of the plan item.

I propose a text similar to what is said in section 7.6.4

"This condition MUST be evaluated when the Milestone, Stage, or Task instance is instantiated and transitions to the
Available state, and their Boolean value SHOULD be maintained for the rest of the life of the Milestone, Stage, or
Task instance."

Clarify sentry evaluation with ifPart only

The execution semantic for sentries is described in page 78, section 7.5 Sentry. However it is not clear on when are sentries evaluated. The onPart is easy, because it is clear that when an event happens it should be evaluated, however for sentries with no onPart it is unclear when that sentry should be evaluated. In addition the first paragraph does not mention milestones or CasePlanModel.

Page 78, Section 7.5 Sentry: Change first paragraph as follows:

When multiple entry criteria (sentries) are used only one is required to trigger the transition of the Stage , or Task , or Milestone instance out of Available state. The same is true for exit criteria. When multiple exit criteria (sentries) are used only one is required to trigger to transition the Stage , or Task , or CasePlanModel instance from Active to Terminated.

Page 78, Section 7.5 Sentry: Add to the end of the section:

Entry criterion sentries are considered ready for evaluation while the task, stage, or milestone is in Available state. Exit criterion sentries are considered ready for evaluation while the CasePlanModel, Stage, or Task is in Active state. Sentries are evaluated when events arrive to the system or when events are generated by the system. A single event may satisfy multiple sentries. Sentries with no onPart must have an ifPart, and that ifPart will be evaluated for all CaseFileItem events, because ifPart expressions are based on CaseFileItem properties.

There are several use cases with my current client where we do not know in advance what will be the actual case that is going to be invoked as a CaseTask. Broadly, the main case has 2 phases, each lasting for about 6 months. The second phase is implemented mostly by means of a subcase (plus some other things). We only know which specific subcase will be invoked right before the phase starts.
However, in the current CMMN spec, we must know the precise subcase at the time of modeling (through the caseref property). We need a mechanism to have some logic determine the subcase at the moment it becomes Active (i.e., not when it becomes Available). Preferably through some sort of expression.
Also at my previous employer we ran into various situations where we had a standard main case model (in COTS software) and then per customer implementation we could vary the specific subcases and subprocesses to be invoked, by means of an expression that would look into e.g. a lookup table.

Note: when we add this to the spec, we need obviously a fixed input/output contract to which the subcase must adhere in order to be able to do parameter binding.

Add "caseRefEpression" to CaseTask and "processRefExpression" to ProcessTask

Make the selection of a specific Case or Process task an expression so that a process or case can be selected at runtime and doesn't have to be specified at design-time.

Suppose we have a plan item A that has an entry criterion and the onPart refers to a Complete transition of a plan item B that is repeatable.
This referenced plan item B obviously has it's own lifecycle.

The plan item A remains Available until the entry criterion is satisfied.

But when is the entry criterion satisfied if multiple instances of B get added to the plan? Is it upon the first plan item A that is completed, or should all instance of A be completed?

This is especially intriguing if the referenced planitem is a milestone.
Evaluation of the RepetitionRule is clear, it should happen on create. Repeating the plan item is clear for Task and Stage, see 7.6.4: Whenever a Task or Stage becomes Active, a new instance of the plan item is added to the plan in state Available, triggering same cycle of evaluation of the repetition rule and potentially adding a new plan item if the plan item becomes Active.
However, for Milestones this behavior of adding the repeated plan item is not specified in 7.6.4. But it seems rather intuitive to do this when the milestone Occurs.
However, now comes the problem with sentries listening to this repeating milestone: when the sentry listens to the "Occur" of the milestone, then the entry criterion get's satisfied, and the listening plan item can go to Active ... However, at the time of the Occur transition of the milestone to Complete, a new plan item for the milestone is added to the plan, making immediately the transition Create (to have it go from Null to Available state) ... the listening sentry now immediately gets dissatisfied because of the new plan item's transition ...

I guess this is a place to reconsider or make more explicit what the intended execution semantics should be.

Clarify sentry behaviour under repetition rule

The question in here is what happens (what is the execution semantics) when a sentry is waiting in a plan item that has a repetition rule true.
This clarification should be added in page 79, section 7.6.4 RepetitionRule

A HumanTask can have a reference to a performer role. But why was this not done at the level of the PlanItem?
E.g., i could have the same human task to review, referred to from 2 different plan items. In the first occurrence the review must happen by the role "knowledge worker", and if we plan the second plan item, the review must happen by the role "expert". It is the same human task, but to be done by someone else.

Same counts for 5.4.2.2 UserEventListener reference to role, again, it would be better to have this on PlanItem level.

Perhaps the best would be to apply a concept similar to what is done with ItemControl, where a plan item can override the default item control of a task.

Better to keep performer role to Human Task only

Human Task instances can be planned based on Plan Items, as well as Discretionary Items. As Human Task as PlanItemDefinition provides the definition for both, it was logical to at least link the Role there. And not to both of the others. But even when we would do it in all three, similar to the way ItemControl is used (with default in the PlanItemDefinition), we would still have a problem with the use of Role in relation to TableItem, where Role reference is used to specify whether a user is authorized to plan. And it should be possible also, when the PlanningTable is owned by a the HumanTask, that the performerRole of the HumanTask would be one of the Roles that are authorized to plan. The ItemControl-like solution would not work in relation to TableItem. Hence it is best to link the Role to HumanTask (as PlanItemDefinition), and not to PlanItem etc.
And this “limitation” should not cause a problem, because when different “instances” of Tasks (as PlanItems) should be performed by different persons, this is possible, by assigning the Role to different organization roles or users. This assignment is outside the scope of CMMN. When it is really required that different Roles (functional and design-time Roles) perform the Tasks, then different Tasks (as PlanItemDefinitions) can be defined. This should not be a problem.
More-over, even when we would link Role to PlanItem, the model would be complicated further, as we would also have to specify constraints, as we cannot link Roles to any PlanItem, but only to PlanItems of the PlanItemDefinition kind of HumanTask and UserEventListener. And furthermore: for different types of PlanItems, the Role reference would be named differently, like performerRole versus roleRefs, etc. It would become more complicated, and we better want to avoid that.
And after all, the issue does not look like that important, as, based on what is suggested above, there are sufficient ways to use CMMN to achieve what you want here.

Currently PlanItems have a 'name' property. This is very handy to be able to distinguish a 2 planitems that refer to e.g. the same HumanTask. E.g., we have a Review Task, and we could have then 2 plan items, one to do InitialReview and the other to do SecondReview.

The 'name' property is missing on the DiscretionaryItem ... It must be added there too for the same reasons

Add "name" property to DiscretionaryItem

Part of that is solved as proposal from CR-1 j.)

Multiple inconsistencies between class diagram figures and attribute tables, as follows:

a) Inconsistence between Figure 5.1 (page 9), figure 5.3 (page 15) and table 5.4 (page 11). Note that CaseFileItemDefinition has “name” in the figures, but name does not appear in the table. It has name in the xsd.

b) Inconsistence between Figure 5.1 (page 9), figure 5.3 (page 15) and table 5.3 (page 11). Note that Import has “name” in the figure, but name does not appear in the table. Does not have name in xsd.

c) Inconsistence between Figure 5.1 (page 9), Figure 5.10 (page 34) and table 5.33 (page 38). Note that Process has “name” in the figure, but name does not appear in the table. It has name in the xsd.

d) Inconsistence between Figure 5.2 (page 13), Figure 5.6 (page 21) and table 5.26 (page 29). Note that Stage in the figures is missing autoComplete.

e) Inconsistence between Figure 5.4 (page 17) and table 5.31 (page 34). Note that Task in the figure is missing isBlocking.

f) Inconsistence between Figure 5.5 (page 19) and table 5.9 (page 14). Note that Role is missing “name” in the figure.

g) Figure 5.7 (page 24) has two copies of CaseFileItem, and they have different attributes.

h) Inconsistence between Figure 5.9 (page 30) and table 5.11 (page 16). Note that CaseFileItem is missing “name” and “multiplicity” in the figure.

i) Figure 5.10 (page 34) has two copies of Expression, and they have different attributes.

j) Inconsistence between Figure 5.11 (page 40), Figure 5.9 (page 30) and table 5.29 (page 32). Note that DiscretionaryItem has “name” in figure 5.11, but name does not appear in the table, or in figure 5.9. Does not have name in xsd.

k) Section 5.4.11 PlanItemControl, page 40, instead of having a table for PlanItemControl, it was labeled “Figure 5.12”, which is wrong. It should be a table.

*Fix inconsistencies in UML model diagrams and attribute tables in spec *

Fix the issues reported in the tables and diagrams.
The issue reported on DiscretionaryItem is handled separately as part of issue
CR-37

If you have a task contained by a stage, you cannot connect an entry criterion from the stage with an entry criterion from the task.

This could be handy if a task should only be available if the stage was entered through a specified entry criterion.

Only a exit criterion can be connected to an entry criterion based on this sentence on page 26:

SentryRef, if specified, MUST refer to a Sentry that is referenced by an exitCriteriaRef of the PlanItem that is referred to as the sourceRef of the PlanItemOnPart.

Do not remove constraints on sentryRef

You refer to the semantics of sentryRef in table 23.
This is a very specific, though useful situation. It is the CMMN counterpart of what is aka “state transition”: when an event comes, and one state (here stage) is exited, another state is entered, in one consistent (transition) transaction.
We should however not remove the constraints on sentryRef, and do as if any Sentry can then reference, via its OnPart, to another Sentry. Because that would not make good semantics.
What we provided with sentryRef is a specific, and therefore special (exceptional) situation. We should not make the exception the rule.

in page 40, the table is labelled as figure 5.12

Duplicate of issue CR-53

Duplicate of issue CR-53

In page 40 and 41, the table is labeled Figure 5.12 (should be Table 5.40).

Fix table label in pages 40 & 41

The table in page 40 (which continues in page 41) is labelled Figure 5.12 (instead of table 5.40).

Page 40, Figure 5.12 (which in reality is a table):

Figure 5.12 Table 5.40 - PlanItemControl attributes and model associations

page 39 has the sentence: "Under which conditions will Tasks, Stages, and Milestones be “required” to complete or terminate before their containing Stage can complete. This is specified by RequiredRules, as part of PlanItemControls (see 5.4.11.2)."

Note that RequiredRules does not affects Terminate.

fix usage of Terminated state as completion

Page 39, Section 5.4.11 PlanItemControl, second bullet: Change as follows:

Under which conditions will Tasks, Stages, and Milestones be “required” to complete or terminate before their containing Stage can complete. This is specified by RequiredRules, as part of PlanItemControls (see 5.4.11.2).

The last non-normative reference has an URL enclosed in squared brackets. None of the other references have that weird formating.

Fix missformated reference

The last reference in page 4 has extra squared brackets around the URL.

The last paragraph in page 18, reads as if CMMN will have in the future some extra event functionality.

fix future statement

Page 18, last sentence should be changed.

Page 18, last sentence. Change as follows:

This will enable enables CMMN, to handle any event in a uniform way, namely as “standard events” that denote transitions in CMMN-defined lifecycles. These standard events are handled via Sentries. Sentries and these “standard events” are specified in 5.4.6.

The text for section 5.1.4.1 Property states that "Property types are derived from the top-level built-in primitive types of XML Schema" and list most of the XML Schema types in table 5.7, but it is missing the "decimal" type. See http://www.w3.org/TR/xmlschema-2/#built-in-primitive-datatypes

Add decimal to table 5.7 (page 12)

Add decimal to table 5.7 as follows:
decimal | http://www.omg.org/spec/CMMN/PropertyType/decimal

CMIS is mentioned in several pages in the specification (for example, page 11 and 15), but it is not listed in section 3.2 Non-normative References.

Need to add CMIS to section 3.2

Add the CMIS specification as a non-normative reference in chapter 3.2

CMIS is mentioned in several pages in the specification (for example, page 11 and 15), but it is not listed in section 3 References.

Note that BPMN 2.0.2 only list as normative references (section 3.2) UML, MOF, and RFC-2119. All other references including XML Schema, WSDL, XPath, etc. are listed as non-normative (section 3.3).

Therefore the proposal is to list CMIS as non-normative reference in CMMN.

Add to section 3.2 Non-normative References, the following (reference) paragraph:

Business Process Model and Notation (BPMN) Version 2.0, OMG, January 2011, http://www.omg.org/spec/BPMN/2.0/PDF/

Content Management Interoperability Services (CMIS), Florian Müller, Ryan McVeigh, Jens Hübel, eds., OASIS, 23 May 2013. http://docs.oasis-open.org/cmis/CMIS/v1.1/os/CMIS-v1.1-os.html

Davenport, Th. H. and Nohria, N., Case Management and the Integration of Labor, Sloan Management Review, 1994.

Table 7.9 contains improper values for the transition propagation. E.g., when a state is active, and (parent)resume is triggered, then it says that the child state goes to "Suspended". Obviously this is wrong, as it ought to be that the child state goes from "Suspended" back to it's history state.

In addition a suggestion: instead of mentioning each state of each type of child, perhaps it is better to mention the transition that should be invoked on the child plan items. The state machine behavior of the child already sufficiently describes from/to state combinations per transition.

Fix table 7.9 page 74

There are errors in the rows 5 to 9 (last 5 rows on page 74).

Current page 74 table 7.9

Proposed changes to page 74 table 7.9 (five last rows in this page)

Add new note to the table as follows:

Notes:
(1) If the exception is fixed and the restart transition is taken to Active, then it should continue transition into Suspended state.
(2) Return the child to the state it has before the "parent suspend" or "suspend" transition to Suspended state.

Quote: "The difference between using a CaseTask and a Stage is that a CaseTask calls a Case that has its own context, i.e., it
is based on its own CaseFile, whereas a Stage represents behavior that shares the same context with the Stage, i.e., it
is based on the same CaseFile and is “embedded” in the same Case."

It says "... a Stage represents behavior that share the same context with the Stage ..." Perhaps the second occurrence of the word Stage should have been Case?

Clarify difference between case task and stage

Section 5.4.10.6 CaseTask (page 38), second paragraph reads,

The difference between using a CaseTask and a Stage is that a CaseTask calls a Case that has its own context, i.e. it is based on its own CaseFile, whereas a Stage represents behavior that shares the same context with the Stage, i.e. it is based on the same CaseFile and is “embedded” in the same Case.

Which is redundant.

5.4.10.6 CaseTask (page 38), second paragraph reads,

The difference between using a CaseTask and a Stage is that a CaseTask calls a Case that has its own context, i.e. it is based on its own CaseFile, whereas a Stage represents behavior that shares the same context with the Stage, i.e. it is based on the same CaseFile and is “embedded” in the same Case.

Rewrite as follows

The difference between using a CaseTask and a Stage is that a CaseTask calls a invokes a new Case that has its own context, i.e. it is based on its own CaseFile (implements reuse), whereas a Stage executes is in the context of the current case represents behavior that shares the same context with the Stage, i.e. it is based on the same CaseFile and is “embedded” in the same current current Case (implements composition).

Literal text on page 41:

"A PlanItemControl that is the itemControl of a DiscretionaryItem, MUST NOT contain a RepetitionRule. (This is because the concept of “repetition” depends on the semantics of Sentries (see 5.4.11.3), and DiscretionaryItems are not associated with Sentries.)"

However, discretionaries can also have sentries, hence this is an illogical rule, and it must be removed.

Clarify PlanItemControl of Discretionary items

With exception of one paragraph in the specification discretionary items are allow to have a repetition rule. In particular the notation shows an example (figure 6.55 page 61).

Page 41 repetionRule : RepetitionRule[0,1] explanation text read:

A PlanItemControl that is the itemControl of a DiscretionaryItem, MUST NOT contain a RepetitionRule. (This is because the concept of “repetition” depends on the semantics of Sentries (see 5.4.11.3), and DiscretionaryItems are not associated with Sentries.)

Remove that text, as follows:

A PlanItemControl that is the itemControl of a DiscretionaryItem, MUST NOT contain a RepetitionRule. (This is because the concept of “repetition” depends on the semantics of Sentries (see 5.4.11.3), and DiscretionaryItems are not associated with Sentries.)

The reference to the figure is wrong. It is figure 6.34 that denotes the stage transition ...

Duplicated with part of issue 18

duplicate with part of issue CR-18. The solution to issue CR-18 will fix this issue

The scope section should clarify the relationship between CMMN and BPMN. It is my impression that “CMMN is complementary to BPMN”, but it is not explicitly said in the specification. There is currently a debate on the relationship between CMMN and BPMN, and the specification is silent on this topic. It is important to note that CMPM RFP (Bmi/2009-09-23) request was to enhance BPMN with case management, and I believe CMMN does that, but it is not mentioned in the specification scope section.

Add text to the summary session

Add "This specification is intended to be consistent with and complementary to BPMN."

Current text in 1 Scope session (page 1):

This specification defines a common meta-model and notation for modeling and graphically expressing a Case, as well as an interchange format for exchanging Case models among different tools. The specification is intended to capture the common elements that Case management products use, while also taking into account current research contributions on Case management. It is to Case management products what the OMG Business Process Model and Notation (BPMN) specification is to business process management products.

BPMN has been adopted as a business process modeling standard. It addresses capabilities incorporated in a number of other business process modeling languages, where processes are described as the predefined sequences of activities with decisions (gateways) to direct the sequence along alternative paths or for iterations. These models are effective for predefined, fully specified, repeatable business processes.

For some time, there has been discussion of the need to model activities that are not so predefined and repeatable, but instead depend on evolving circumstances and ad hoc decisions by knowledge workers regarding a particular situation, a case (see Davenport 1994 and 2005; and Van der Aalst 2005). Applications of Case management include licensing and permitting in government, application and claim processing in insurance, patient care and medical diagnosis in healthcare, mortgage processing in banking, problem resolution in call centers, sales and operations planning, invoice discrepancy handling, maintenance and repair of machines and equipment, and engineering of made-to-order products.

Change first paragraph as follows:

This specification defines a common meta-model and notation for modeling and graphically expressing a Case, as well as an interchange format for exchanging Case models among different tools. The specification is intended to capture the common elements that Case management products use, while also taking into account current research contributions on Case management. It is to Case management products what the OMG Business Process Model and Notation (BPMN) specification is to business process management products. This specification is intended to be consistent and complementary to BPMN.

Chapter 3 References is missing references to XML Schema and XPath specifications.
XML Schema: That is important because section "5.1.4.1 Property" indicates that "Property types are derived from the top-level built-in primitive types of XML Schema". Furthermore, it indicates the reader should "see the description of the individual types in the XML Schema specification for an exact definition of the value space."
XPath: That is important because Table 5.2 describe the default expression language as “http://www.w3.org/1999/XPath.” and section 7.3 indicates that "An implementation that uses XPath as expression language (see 5.1.2), MIGHT use XPath Extension Functions to implement those operations."

Add the XML Schema and XPath specifications as a non-normative reference in chapter 3.2

CMMN section "5.1.4.1 Property" indicates that "Property types are derived from the top-level built-in primitive types of XML Schema". Furthermore, it indicates the reader should "see the description of the individual types in the XML Schema specification for an exact definition of the value space." Therefore, we should add XML Schema to chapter 3 references. in addition, Table 5.2 describe the default expression language as “http://www.w3.org/1999/XPath.” and section 7.3 indicates that "An implementation that uses XPath as expression language (see 5.1.2), MIGHT use XPath Extension Functions to implement those operations."

Note that BPMN 2.0.2 only list as normative references (section 3.2) UML, MOF, and RFC-2119. All other references including XML Schema, WSDL, XPath, etc. are listed as non-normative (section 3.3).

Therefore the proposal is to list XML Schema and XPath as non-normative in CMMN.

Add to section 3.2 Non-normative References, the following two (reference) paragraphs:

Man, H. de, Case Management: A Review of Modeling Approaches, BPTrends, January 2009. [http://www.bptrends.com/
publicationfiles/01-09-ART-%20Case%20Management-1-DeMan.%20doc--final.pdf ]

XML Schema Part 2: Datatypes, Paul V. Biron and Ashok Malhotra, eds., W3C, 28 October 2004. http://www.w3.org/TR/xmlschema-2/

XML Path Language (XPath) 1.0, James Clark and Steve DeRose, eds., W3C, 16 November 1999. http://www.w3.org/TR/xpath

In the XSD, CasePlanModel and CaseFileModel are top level elements. However, CaseRoles is a "multi" element at top level, leading to XML like

<case>
<casePlanModel> ... </casePlanModel>
<caseFileModel> ... </caseFileModel>
<caseRoles name="Employee" />
<caseRoles name="Admin" />
</case>

I would expect that caseRoles is also a single top level element, with <caseRole> elements inside it.

Add tCaseRoles to XSD and modify element caseRoles in tCase

1. Add a new complexType to the XSD

2. Modify element "caseRoles" in complexType "tCase" :

In the conformance matrix on page 2, following references should be fixed:
2.1 --> 2.2
2.2 --> 2.3
2.3 --> 2.4
2.4 --> 2.5
6.7.2.1 --> 6.8.2.1
6.7.2.2 --> 6.8.3.1

On page 55, following reference should be fixed: reference to picture 6.35 should be 6.34

Fix references in specification

a- In the conformance matrix (table 2.1) on page 2, fix following references (column 1):
2.1 --> 2.2
2.2 --> 2.3
2.3 --> 2.4
2.4 --> 2.5
6.7.2.1 --> 6.8.2.1
6.7.2.2 --> 6.8.3.1

Current conformance matrix (table 2.1) on page 2

New conformance matrix (table 2.1) on page 2

b- On page 55, change reference to picture 6.35 to 6.34

Current text in page 55

The construct in Figure 6.35 may be considered a “Stage transition,” triggered by a particular event. Stage B is enabled via its entry criterion (depicted on its boundary), the OnPart of which may specify as standardEvent the termination of Stage A, given that it terminates based on the exit criterion (as depicted on its boundary). That exit criterion may itself has an OnPart (not depicted as connector) that refers e.g., to the creation of a document (CaseFileItem instance). So, when an instance of the document is created, Stage A terminates, and Stage B is enabled upon termination of Stage A, given that it terminates based on that document creation event.

Change text in page 55, as follows:

The construct in Figure 6.35 6.34 may be considered a “Stage transition,” triggered by a particular event. Stage B is enabled via its entry criterion (depicted on its boundary), the OnPart of which may specify as standardEvent the termination of Stage A, given that it terminates based on the exit criterion (as depicted on its boundary). That exit criterion may itself has an OnPart (not depicted as connector) that refers e.g., to the creation of a document (CaseFileItem instance). So, when an instance of the document is created, Stage A terminates, and Stage B is enabled upon termination of Stage A, given that it terminates based on that document creation event.

A task can have zero or more inputs/outputs elements.

The naming convention seems a bit off here. Logically, it should be input instead of inputs and output instead of outputs.

Follow naming conventions of metamodel

I would propose to close this issue since the association names "inputs" and "outputs" follow the naming conventions we have in place in the metamodel.