${taskforce.name} Avatar
  1. OMG Task Force

CMMN 1.1 RTF — Open Issues

  • Key: CR
  • Issues Count: 9
Open Closed All
Issues not resolved

Issues Descriptions

Clarify semantics of None Event Listeners

  • Key: CR-154
  • Status: open   Implementation work Blocked
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    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.

  • Reported: CMMN 1.1 — Wed, 17 Oct 2018 18:10 GMT
  • Updated: Thu, 18 Oct 2018 20:03 GMT

Inconsistent spelling of color attributes in text, MM and XSD

  • Key: CR-153
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.

  • Reported: CMMN 1.1 — Mon, 16 Oct 2017 13:48 GMT
  • Updated: Tue, 17 Oct 2017 14:31 GMT

An Initial transition can't contain any trigger/event

  • Key: CR-152
  • Status: open  
  • Source: NobleProg ( Filip Stachecki)
  • Summary:

    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.

  • Reported: CMMN 1.1 — Tue, 27 Jun 2017 13:55 GMT
  • Updated: Tue, 27 Jun 2017 15:31 GMT

autoComplete doesn't take into account the event listeners

  • Key: CR-151
  • Status: open  
  • Source: Loqutus ( Stijn Beeckmans)
  • Summary:

    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?

  • Reported: CMMN 1.1 — Wed, 22 Feb 2017 10:06 GMT
  • Updated: Wed, 22 Feb 2017 15:27 GMT

Figure 7.4 'CMMN Shape' shows attribute isExpanded instead of isCollapsed

  • Key: CR-150
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.

  • Reported: CMMN 1.1 — Tue, 9 Aug 2016 11:16 GMT
  • Updated: Wed, 10 Aug 2016 14:13 GMT

Wrong manual activation default and missing defaults for ManualActivationRules, RequiredRules and RepetitionRules without condition

  • Key: CR-148
  • Status: open   Implementation work Blocked
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.”"

  • Reported: CMMN 1.1 — Mon, 4 Jul 2016 07:39 GMT
  • Updated: Wed, 13 Jul 2016 12:23 GMT

Name missmatch between Table 5.51 and MM/XSD for condition of RequiredRules

  • Key: CR-149
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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".

  • Reported: CMMN 1.1 — Thu, 30 Jun 2016 18:39 GMT
  • Updated: Tue, 5 Jul 2016 12:08 GMT

Process Task and Case Task should have performer defined

  • Key: CR-146
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: CMMN 1.1 — Wed, 25 May 2016 14:27 GMT
  • Updated: Wed, 29 Jun 2016 15:55 GMT

Allow the possibility to define multiple standard events for an onPart

  • Key: CR-147
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.)

  • Reported: CMMN 1.1 — Wed, 25 May 2016 14:40 GMT
  • Updated: Wed, 29 Jun 2016 15:53 GMT