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

CMMN 1.1 RTF — Closed Issues

  • Key: CR
  • Issues Count: 71
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
CR-89 Tasks with RepetitionRule: how to restrict the number of task instances (at a given time)? CMMN 1.1 CMMN 1.1 Resolved closed
CR-141 DI Chapter Editorials CMMN 1.0 CMMN 1.1 Resolved closed
CR-140 Change the Notation of the OnPart so it does not conflict with Association CMMN 1.0 CMMN 1.1 Resolved closed
CR-143 Editorial to section 5.1.5 CMMN 1.0 CMMN 1.1 Resolved closed
CR-131 Need for annotations and comments in CMMN CMMN 1.0 CMMN 1.1 Resolved closed
CR-133 Need the ability to have repetition rules in Tasks and Stages without entry criterion CMMN 1.0 CMMN 1.1 Resolved closed
CR-137 Editorial: Update Table 2.1 - Conformance matrix CMMN 1.0 CMMN 1.1 Resolved closed
CR-128 Expressiveness of Task patterns CMMN 1.0 CMMN 1.1 Deferred closed
CR-127 Depicting Inputs and Outputs to Tasks CMMN 1.0 CMMN 1.1 Deferred closed
CR-126 Exit Criterion may be misleading (as a name or concept) CMMN 1.0 CMMN 1.1 Deferred closed
CR-124 Need to add names to contributors CMMN 1.0 CMMN 1.1 Resolved closed
CR-118 Missing constraint to prevent Human Task from being discretionary to itself CMMN 1.0 CMMN 1.1 Resolved closed
CR-98 Create classes to hold entry and exit criterion references CMMN 1.0 CMMN 1.1 Resolved closed
CR-96 Add name attribute to OnPart CMMN 1.0 CMMN 1.1 Resolved closed
CR-92 Inconsistency between XSD and meta-model for condition on IfPart CMMN 1.0 CMMN 1.1 Resolved closed
CR-90 Missing attribute “name” for Process CMMN 1.0 CMMN 1.1 Resolved closed
CR-110 Missing "externalRef" in Process class CMMN 1.0 CMMN 1.1 Resolved closed
CR-104 Some figure in chapter 6 do not use the new Discretionary Association CMMN 1.0 CMMN 1.1 Resolved closed
CR-101 XSD Doesn't allow DiscretionaryItem to have entry/exit criteria CMMN 1.0 CMMN 1.1 Resolved closed
CR-107 Confusing Planning Table on figure 6.63 CMMN 1.0 CMMN 1.1 Resolved closed
CR-94 Add a new discretionary association CMMN 1.0 CMMN 1.1 Resolved closed
CR-87 We should add a Decision type task CMMN 1.0 CMMN 1.1 Resolved closed
CR-76 Missing PlanningTable on the CasePlanModel of figure 6.63 CMMN 1.0 CMMN 1.1 Resolved closed
CR-74 Missing notational element for discretionary Milestones and discretionary EventListeners CMMN 1.0 CMMN 1.1 Deferred closed
CR-67 Expression description prevent constant expressions CMMN 1.0 CMMN 1.1 Resolved closed
CR-69 CMMN does not include the notion of swim lanes CMMN 1.0 CMMN 1.1 Deferred closed
CR-120 Typo in the xsd: in Task we have inputs and outputs instead of input and output CMMN 1.0 CMMN 1.1 Resolved closed
CR-116 Missing attribute "name" in the XSD for ApplicabilityRule CMMN 1.0 CMMN 1.1 Resolved closed
CR-114 Missing authorizedRoleRefs in XSD for tUserEventListener CMMN 1.0 CMMN 1.1 Resolved closed
CR-21 CMMN needs to support Diagram Interchange CMMN 1.0 CMMN 1.1 Resolved closed
CR-14 Ambiguous OnPart references for cross-stage-boundary plan items CMMN 1.0 CMMN 1.1 Duplicate or Merged closed
CR-7 CMMN spec inconsistent with respect to Sentry dependencies crossing Stage boundaries CMMN 1.0 CMMN 1.1 Resolved closed
CR-3 Undesired limitation on PlanItemDefinitions CMMN 1.0 CMMN 1.1 Resolved closed
CR-23 Evaluation/Re-evaluation of RequiredRule unclear - what does "maintained" mean? CMMN 1.0 CMMN 1.1 Resolved closed
CR-19 Incorrect Example image CMMN 1.0 CMMN 1.1 Resolved closed
CR-82 Unrequired “body” element in expression in the XSD CMMN 1.0 CMMN 1.1 Resolved closed
CR-79 Terminology inconsistency between Metamodel and XSD CMMN 1.0 CMMN 1.1 Resolved closed
CR-78 EventListeners erroneously listed for RequiredRule CMMN 1.0 CMMN 1.1 Resolved closed
CR-72 XML-Schema tCaseFileItem definitionRef attribute must not be mandatory CMMN 1.0 CMMN 1.1 Resolved closed
CR-70 CMMNElement should have Documentation CMMN 1.0 CMMN 1.1 Resolved closed
CR-88 We should allow for the State of a file item to be placed in [Square] brackets CMMN 1.0 CMMN 1.1 Closed; No Change closed
CR-75 CMMN XSD - Inconsistent with the spec text CMMN 1.0 CMMN 1.1 Resolved closed
CR-77 Issue with Human Task XSD CMMN 1.0 CMMN 1.1 Resolved closed
CR-35 Unclear CasefileItem TargetRef and SourceRef and instance operations referring to them CMMN 1.0 CMMN 1.1 Resolved closed
CR-34 XSD attribute "processRef" MUST be required CMMN 1.0 CMMN 1.1 Resolved closed
CR-27 Extensibility of DefinitionTypeEnum and Property types CMMN 1.0 CMMN 1.1 Resolved closed
CR-20 CMMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions) CMMN 1.0 CMMN 1.1 Resolved closed
CR-15 Timerevent based on data not possible CMMN 1.0 CMMN 1.1 Resolved closed
CR-13 Unclear when an IfPart only sentry must be evaluated CMMN 1.0 CMMN 1.1 Resolved closed
CR-12 CaseTask.CaseRef should allow for expressions to support dynamic subcases CMMN 1.0 CMMN 1.1 Resolved closed
CR-11 Sentry behavior for OnParts referring to Repeating PlanItems is unclear CMMN 1.0 CMMN 1.1 Resolved closed
CR-8 PerformerRole should be applied to PlanItem rather than HumanTask CMMN 1.0 CMMN 1.1 Closed; No Change closed
CR-5 Discretionary Items should also have a Name property CMMN 1.0 CMMN 1.1 Resolved closed
CR-1 Inconsistencies between class diagram figures and attribute tables CMMN 1.0 CMMN 1.1 Resolved closed
CR-16 Two entry criteria cannot be connected CMMN 1.0 CMMN 1.1 Closed; No Change closed
CR-46 Mislabled table CMMN 1.0 CMMN 1.1 Duplicate or Merged closed
CR-53 Table labeled as a figure in page 40 CMMN 1.0 CMMN 1.1 Resolved closed
CR-59 Usage of Terminate state as Completion CMMN 1.0 CMMN 1.1 Resolved closed
CR-55 Reference missformated CMMN 1.0 CMMN 1.1 Resolved closed
CR-57 Future sentence in specification CMMN 1.0 CMMN 1.1 Resolved closed
CR-26 Missing "decimal" type in table 5.7 property types and their URIs CMMN 1.0 CMMN 1.1 Resolved closed
CR-22 Non-normative References do not include CMIS CMMN 1.0 CMMN 1.1 Resolved closed
CR-10 Table 7.9 contains invalid "To state" values for Resume transition CMMN 1.0 CMMN 1.1 Resolved closed
CR-9 Typo in specification, unclear what is intended here CMMN 1.0 CMMN 1.1 Resolved closed
CR-6 PlanItemControl of discretionaries should also allow repetitionrules CMMN 1.0 CMMN 1.1 Resolved closed
CR-4 "The construct in Figure 6.35" should be Figure 6.34 CMMN 1.0 CMMN 1.1 Duplicate or Merged closed
CR-2 The scope does not clarifies the relationship between CMMN and BPMN CMMN 1.0 CMMN 1.1 Resolved closed
CR-25 Missing reference to XML Schema and XPath specification CMMN 1.0 CMMN 1.1 Resolved closed
CR-24 CaseRoles have ugly definition in the XSD CMMN 1.0 CMMN 1.1 Resolved closed
CR-18 Incorrect References CMMN 1.0 CMMN 1.1 Resolved closed
CR-17 Inputs/outputs on task CMMN 1.0 CMMN 1.1 Closed; No Change closed

Issues Descriptions

Tasks with RepetitionRule: how to restrict the number of task instances (at a given time)?

  • Key: CR-89
  • Status: closed  
  • Source: Loydl Unternehmensberatung ( Harald Loydl)
  • Summary:

    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

  • Reported: CMMN 1.1 — Fri, 26 Jun 2015 15:25 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

DI Chapter Editorials

  • Key: CR-141
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Fri, 23 Oct 2015 15:30 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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
  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Change the Notation of the OnPart so it does not conflict with Association


Editorial to section 5.1.5

  • Key: CR-143
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Fri, 23 Oct 2015 19:54 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Need for annotations and comments in CMMN


Need the ability to have repetition rules in Tasks and Stages without entry criterion

  • Key: CR-133
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 20 Oct 2015 15:04 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Editorial: Update Table 2.1 - Conformance matrix

  • Key: CR-137
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    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
  • Reported: CMMN 1.0 — Wed, 21 Oct 2015 05:27 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Update Table 2.1

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

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Expressiveness of Task patterns

  • Key: CR-128
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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

  • Reported: CMMN 1.0 — Tue, 22 Sep 2015 16:53 GMT
  • Disposition: Deferred — CMMN 1.1
  • Disposition Summary:

    defer Expressiveness of Task patterns

    defer Expressiveness of Task patterns to next revision

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Depicting Inputs and Outputs to Tasks

  • Key: CR-127
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: CMMN 1.0 — Tue, 22 Sep 2015 15:41 GMT
  • Disposition: Deferred — CMMN 1.1
  • Disposition Summary:

    Defer depict Inputs and Outputs to Task

    Defer depict Inputs and Outputs to Task to next revision

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Exit Criterion may be misleading (as a name or concept)

  • Key: CR-126
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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)

  • Reported: CMMN 1.0 — Tue, 22 Sep 2015 15:39 GMT
  • Disposition: Deferred — CMMN 1.1
  • Disposition Summary:

    Defer: Exit Criterion may be misleading

    deferred

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Need to add names to contributors

  • Key: CR-124
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    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
  • Reported: CMMN 1.0 — Tue, 22 Sep 2015 11:55 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add contributors to section 4.4 of the spec

    Add contributors to section 4.4 of spec

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing constraint to prevent Human Task from being discretionary to itself

  • Key: CR-118
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 15 Sep 2015 20:45 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Create classes to hold entry and exit criterion references

  • Key: CR-98
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: CMMN 1.0 — Fri, 24 Jul 2015 14:01 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Add name attribute to OnPart

  • Key: CR-96
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Fri, 24 Jul 2015 13:45 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Inconsistency between XSD and meta-model for condition on IfPart

  • Key: CR-92
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Fri, 3 Jul 2015 19:27 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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>

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing attribute “name” for Process

  • Key: CR-90
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 30 Jun 2015 13:15 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

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

    1. Add this row to table 5.37

    name: String the name of the Process
  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing "externalRef" in Process class

  • Key: CR-110
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: CMMN 1.0 — Mon, 10 Aug 2015 15:20 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add externalRef to Process class

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

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Some figure in chapter 6 do not use the new Discretionary Association

  • Key: CR-104
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: CMMN 1.0 — Fri, 31 Jul 2015 19:26 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Update figure 6.43 and 6.47

    1. Replace figure 6.43
    2. Replace figure 6.47

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

XSD Doesn't allow DiscretionaryItem to have entry/exit criteria

  • Key: CR-101
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Fri, 31 Jul 2015 18:14 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Changes applied by CR-99 will fix this issue

    Changes applied by CR-99 will fix this issue

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Confusing Planning Table on figure 6.63

  • Key: CR-107
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: CMMN 1.0 — Fri, 31 Jul 2015 20:35 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Change applied to CR-76 will resolve this issue

    Resolution 106 solve this issue.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Add a new discretionary association

  • Key: CR-94
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Fri, 17 Jul 2015 12:40 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

We should add a Decision type task


Missing PlanningTable on the CasePlanModel of figure 6.63

  • Key: CR-76
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Wed, 27 May 2015 21:23 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Replace figure 6.63

    1. Replace figure 6.63

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Missing notational element for discretionary Milestones and discretionary EventListeners

  • Key: CR-74
  • Legacy Issue Number: 19761
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 19 May 2015 04:00 GMT
  • Disposition: Deferred — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Expression description prevent constant expressions

  • Key: CR-67
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 21 Apr 2015 19:09 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

CMMN does not include the notion of swim lanes

  • Key: CR-69
  • Legacy Issue Number: 19751
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 21 Apr 2015 04:00 GMT
  • Disposition: Deferred — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Typo in the xsd: in Task we have inputs and outputs instead of input and output

  • Key: CR-120
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Wed, 16 Sep 2015 13:25 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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" /> 
    
  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing attribute "name" in the XSD for ApplicabilityRule

  • Key: CR-116
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: CMMN 1.0 — Fri, 11 Sep 2015 14:34 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add attribute name to tApplicabilityRule

    Add the following to tApplicabilityRule just before the contextRef attribute:

    <xsd:attribute name="name" type="xsd:string"/>
    
  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing authorizedRoleRefs in XSD for tUserEventListener

  • Key: CR-114
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: CMMN 1.0 — Fri, 4 Sep 2015 23:28 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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>
    
  • Updated: Tue, 29 Mar 2016 15:06 GMT

CMMN needs to support Diagram Interchange

  • Key: CR-21
  • Legacy Issue Number: 19507
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    CMMN needs to support Diagram Interchange

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

  • Reported: CMMN 1.0 — Wed, 2 Jul 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Ambiguous OnPart references for cross-stage-boundary plan items

  • Key: CR-14
  • Legacy Issue Number: 19496
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    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"

  • Reported: CMMN 1.0 — Mon, 30 Jun 2014 04:00 GMT
  • Disposition: Duplicate or Merged — CMMN 1.1
  • Disposition Summary:

    Duplicate of issue CR-7

    Duplicate

  • Updated: Tue, 29 Mar 2016 15:06 GMT

CMMN spec inconsistent with respect to Sentry dependencies crossing Stage boundaries

  • Key: CR-7
  • Legacy Issue Number: 19477
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

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

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

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

    • We'd like to allow sentries to cross Stage boundaries
  • Updated: Tue, 29 Mar 2016 15:06 GMT

Undesired limitation on PlanItemDefinitions

  • Key: CR-3
  • Legacy Issue Number: 19444
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Mon, 2 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    *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

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Evaluation/Re-evaluation of RequiredRule unclear - what does "maintained" mean?

  • Key: CR-23
  • Legacy Issue Number: 19588
  • Status: closed  
  • Source: Loydl Unternehmensberatung ( Harald Loydl)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Thu, 28 Aug 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Incorrect Example image

  • Key: CR-19
  • Legacy Issue Number: 19504
  • Status: closed  
  • Source: LoQutus nv ( Jochen Firey)
  • Summary:

    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'

  • Reported: CMMN 1.0 — Tue, 1 Jul 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Fixed by CR-106

    Resolution is in CR-106

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Unrequired “body” element in expression in the XSD

  • Key: CR-82
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Thu, 4 Jun 2015 18:40 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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>

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Terminology inconsistency between Metamodel and XSD

  • Key: CR-79
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: CMMN 1.0 — Mon, 1 Jun 2015 14:09 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

EventListeners erroneously listed for RequiredRule

  • Key: CR-78
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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

  • Reported: CMMN 1.0 — Mon, 1 Jun 2015 14:06 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

XML-Schema tCaseFileItem definitionRef attribute must not be mandatory

  • Key: CR-72
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    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

  • Reported: CMMN 1.0 — Tue, 28 Apr 2015 14:27 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Modify XSD tCaseFileItem and make definitonRef optional

    • Make attribute "definitionRef" of complex type "tCaseFileItem" optional again.
  • Updated: Tue, 29 Mar 2016 15:06 GMT

CMMNElement should have Documentation

  • Key: CR-70
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

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

  • Reported: CMMN 1.0 — Tue, 28 Apr 2015 07:12 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Introduction of Documentation class

    • Add new class "Documentation"
    • Add new diagram for CMMNElement
  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

We should allow for the State of a file item to be placed in [Square] brackets

  • Key: CR-88
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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

  • Reported: CMMN 1.0 — Fri, 12 Jun 2015 12:02 GMT
  • Disposition: Closed; No Change — CMMN 1.1
  • Disposition Summary:

    Solved within the CMMN DI

    Nothing to be done solved in CR-21

  • Updated: Tue, 29 Mar 2016 15:06 GMT

CMMN XSD - Inconsistent with the spec text

  • Key: CR-75
  • Status: closed   Implementation work Blocked
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Thu, 21 May 2015 21:58 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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"
  • Updated: Tue, 29 Mar 2016 15:06 GMT

Issue with Human Task XSD

  • Key: CR-77
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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)

  • Reported: CMMN 1.0 — Wed, 27 May 2015 21:25 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Modify XSD complextType tHumanTask to allow max. 1 planning table

    • Modify complexType "tHumanTask" element "planninTable" to allow 0 or 1 planning table.
  • Updated: Tue, 29 Mar 2016 15:06 GMT

Unclear CasefileItem TargetRef and SourceRef and instance operations referring to them

  • Key: CR-35
  • Legacy Issue Number: 19701
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 30 Dec 2014 05:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

XSD attribute "processRef" MUST be required

  • Key: CR-34
  • Legacy Issue Number: 19670
  • Status: closed  
  • Source: Loydl Unternehmensberatung ( Harald Loydl)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 25 Nov 2014 05:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Extensibility of DefinitionTypeEnum and Property types

  • Key: CR-27
  • Legacy Issue Number: 19642
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Wed, 15 Oct 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add XML-Schema PropertyType to CMMN10CaseModel.xsd

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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

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

  • Key: CR-20
  • Legacy Issue Number: 19506
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    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

  • Reported: CMMN 1.0 — Wed, 2 Jul 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Timerevent based on data not possible

  • Key: CR-15
  • Legacy Issue Number: 19500
  • Status: closed  
  • Source: LoQutus nv ( Jochen Firey)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Mon, 7 Jul 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    *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

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Unclear when an IfPart only sentry must be evaluated

  • Key: CR-13
  • Legacy Issue Number: 19495
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

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

  • Reported: CMMN 1.0 — Mon, 30 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

CaseTask.CaseRef should allow for expressions to support dynamic subcases

  • Key: CR-12
  • Legacy Issue Number: 19487
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 24 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Sentry behavior for OnParts referring to Repeating PlanItems is unclear

  • Key: CR-11
  • Legacy Issue Number: 19481
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

PerformerRole should be applied to PlanItem rather than HumanTask

  • Key: CR-8
  • Legacy Issue Number: 19478
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Closed; No Change — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Discretionary Items should also have a Name property

  • Key: CR-5
  • Legacy Issue Number: 19475
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    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

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add "name" property to DiscretionaryItem

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

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Inconsistencies between class diagram figures and attribute tables

  • Key: CR-1
  • Legacy Issue Number: 19440
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Sun, 1 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    *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

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Two entry criteria cannot be connected

  • Key: CR-16
  • Legacy Issue Number: 19501
  • Status: closed  
  • Source: LoQutus nv ( Jochen Firey)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Mon, 7 Jul 2014 04:00 GMT
  • Disposition: Closed; No Change — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Mislabled table

  • Key: CR-46
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    in page 40, the table is labelled as figure 5.12

  • Reported: CMMN 1.0 — Fri, 6 Feb 2015 01:33 GMT
  • Disposition: Duplicate or Merged — CMMN 1.1
  • Disposition Summary:

    Duplicate of issue CR-53

    Duplicate of issue CR-53

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Table labeled as a figure in page 40

  • Key: CR-53
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

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

  • Reported: CMMN 1.0 — Tue, 17 Feb 2015 01:21 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Usage of Terminate state as Completion

  • Key: CR-59
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 17 Feb 2015 01:46 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Reference missformated

  • Key: CR-55
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

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

  • Reported: CMMN 1.0 — Tue, 17 Feb 2015 01:28 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Fix missformated reference

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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Future sentence in specification

  • Key: CR-57
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

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

  • Reported: CMMN 1.0 — Tue, 17 Feb 2015 01:34 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing "decimal" type in table 5.7 property types and their URIs


Non-normative References do not include CMIS

  • Key: CR-22
  • Legacy Issue Number: 19515
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    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

  • Reported: CMMN 1.0 — Fri, 11 Jul 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Table 7.9 contains invalid "To state" values for Resume transition

  • Key: CR-10
  • Legacy Issue Number: 19480
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Typo in specification, unclear what is intended here

  • Key: CR-9
  • Legacy Issue Number: 19479
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    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?

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

PlanItemControl of discretionaries should also allow repetitionrules

  • Key: CR-6
  • Legacy Issue Number: 19476
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

"The construct in Figure 6.35" should be Figure 6.34

  • Key: CR-4
  • Legacy Issue Number: 19474
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

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

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Duplicate or Merged — CMMN 1.1
  • Disposition Summary:

    Duplicated with part of issue 18

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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

The scope does not clarifies the relationship between CMMN and BPMN

  • Key: CR-2
  • Legacy Issue Number: 19441
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Mon, 2 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing reference to XML Schema and XPath specification

  • Key: CR-25
  • Legacy Issue Number: 19638
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

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

  • Reported: CMMN 1.0 — Mon, 13 Oct 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

CaseRoles have ugly definition in the XSD

  • Key: CR-24
  • Legacy Issue Number: 19624
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Mon, 29 Sep 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

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

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Incorrect References

  • Key: CR-18
  • Legacy Issue Number: 19503
  • Status: closed  
  • Source: LoQutus nv ( Jochen Firey)
  • Summary:

    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

  • Reported: CMMN 1.0 — Mon, 7 Jul 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Inputs/outputs on task

  • Key: CR-17
  • Legacy Issue Number: 19502
  • Status: closed  
  • Source: LoQutus nv ( Jochen Firey)
  • Summary:

    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.

  • Reported: CMMN 1.0 — Mon, 7 Jul 2014 04:00 GMT
  • Disposition: Closed; No Change — CMMN 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Mar 2016 15:06 GMT