Line 381: content types of base type 'tCmmnElementWithMixedContent' and derived type 'tExpression' must both be mixed or element-only.

Presumably tExpression should be declared to be mixed: this is not implicit through inheritance

Agreed on the issue, modify CMMN XML-Schema file CMMN10CaseModel.xsd
Old specification of type "tExpression":
<xsd:complexType name="tExpression">
<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>

New specification of type "tExpression":
<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>

The composite end of the association between ParameterMapping and Expression, as shown in Figure 11, has multiplicity 0..*, which is technically wrong. It should have multiplicity 0..1.

Change the multiplicity of the composite end of the association between ParameterMapping and Expression to 0..1.

Compliance section should explicitly demand compliance with total spec.

Most likely a section has to be added for this purpose.

Note that this was a remark from the AB, back in December 2012, from the meeting in which the spec was adopted.

Agreed on the issue, modify section 2 of the spec

Description: The XML-Schema for CMMN has the following issues:
1. CaseFileItemTransition restriction missing attribute 'base="xsd:string"'
2. Attribute "id" of complex type "tDefinitions" MUST be of type "xsd:ID" (and not "xsd:IDREF")
3. Complex Types "tTask" and "tEvent" MUST NOT be abstract

Attached are the new XML-Schema files that fixes above issues.

Agreed on the issue, modify CMMN XML-Schema files CMMN10.xsd and CMMN10CaseModel.xsd

It is desirable to add a CMMN logo to the front page of the spec.

((The team had reached agreement on that already, based on a graphical proposal from Denis Gagne))

Agreed on the issue, add CMMN logo designed by Denis to front page

As figure 12 shows, Expression is contained in three classes, all three with multiplicity 1. This is wrong, and should be 0..1.

Agreed on the issue, modify PlanItemControl metamodel in Figure 12, section 5.4.11

Figure 11 shows how Process Parameter is contained twice in Process, both with mutiplicity 1. This is wrong. It should be 0..1

Agreed on the issue, modify metamodel for Task in section 5.4.10

It has turned out that many of our potential users of CMMN 1.0 naturally model
discretionary items with Sentries associated to PlanItem's in the Stage and there are multiple
use cases that would benefit from allowing Sentries on Discretionary Items.

So we'd propose to allow Sentries on DiscretionaryItem's in a Planning Table with the restriction
that those Sentries MUST refer PlanItem elements of the Planning Table Stage.

Agreed on the issue, modify PlanningTable metamodel (Figure 10) in section 5.4.9 and associated text in section 5.4.9.2 (DiscretionaryItem class)

The example case model in Figure 72 shows several Discretionary Plan Items with a Sentry on the boundary. Per specification, those items MUST NOT have sentries.

Agreed on the issue, provide new example

The following statement is used for motivating the introduction of the class EventListener:
"However, elapse of time cannot be captured via these 'standard events', and it will often lead to very indirect modeling, when any user event..."
Suggestion: To improve readability, change the text to:
"However, elapse of time cannot be captured via these 'standard events'. Also, it will often lead to very indirect modeling..."
When reading the current sentence, the reader might (at least initially) assume that the indirect modeling refers to elapse of time.

Agreed on the issue, modify text in section 5.4.2

n the visual notation, a shallow and a solid diamond symbol are used for depicting entry and exit criterion.
Both symbols are not intuitively understandable. Someone who learns the CMMN notation must explicitly learn the difference between shallow and solid symbol. It is likely that inexperienced modelers will mistake one symbol for the other.

Suggestion: Use an incoming arrow symbol (similar to the UNICODE symbol 21E8) for a Sentry serving as entry criterion and analogously an outgoing arrow symbol for a Sentry serving as exit criterion. This notation will be understood intuitively.

Note: I am aware of the fact that the currently suggested symbols are already used in the scientific works on the GSM approach. However, the CMMN standard is aimed to be used by a large number of people, including business people who do not have too much time to learn the notation (see the description of target users in section 4.3.). It would be simple for the few scholars who read the work on GSM to learn the new symbols. For inexperienced modelers, easy-to-lern symbols are a great help for adapting the language.

Reject issue.
Revised Text:

Disposition: Closed, no change

While on page 32 it is stated that a Sentry does not have to have an On-part, the text on page 33 says that a Sentry may consist of one or more OnParts.
This can be read as a contradiction; the meaning of "may" is not clear enough.

Agree with problematic statement, text in section 5.4.6 has been modified

For timeExpression, a string conforming to the ISO-8601 format is allowed.
While this format would allow time events occurring at a given point of time, it is impossible to specify time events that occur after a given period of time that starts with a state change of an instance.
For example, it would be impossible to specify that a time event occurs five days after an incoming invoice arrived.
Suggestion: TimerEventListener should contain another attribute that allows to specify a point of time when the duration given in timerExpression starts. This point of time should correspond to a state change of an instance.

Modify TimerEventListener Metamodel (Figure 6, section 5.4.2) to include references to PlanItem and CaseFileItem lifecycle state changes that triggers the start of a TimerEventListener

Nature: Revision
Severity: Significant
Chapter/Section: 6.7.2 (Case task) and 6.7.3 (Process Task)
Page Number(s): 59 - 80

Description: Process and Case Tasks are semantically similar to BPMN call activity, but do not have thick border lines. In addition, this proposal suggest that some markers should be optional markers for tool sets that combine both CMMN and BPMN.

Agreed on the issue, added sub-sections 6.7.2.1 and 6.7.3.1

Chapter/Section: Chapter 6.12.2 (AutomaticActivation Decorator) and 6.12.4 (Repetition Decorator)
Page Number(s): 68

Description: There are inconsistencies in AutomaticActivation and Repetition decorators between CMMN and BPMN that makes it difficult for implementors to use both CMMN and BPMN in the same tool set. A goal of CMMN was consistency with BPMN, and so, we are proposing changes to CMMN to solve the decorator inconsistencies.

Agreed on the issue, modify section 5.4.11 on PlanItemControl and modify decorators in section 6.12.2 and 6.12.4

Case file item is contained in both itself (0..1) and case file (1).
The containment in case file cannot be mandatory therefore, and hence has to be 0..1 as well.

This also requires change of figure 4.

Agreed on the issue, modify CaseFile metamodel in Figure 4, section 5.3

Nature: Revision
Severity: Significant
Chapter/Section: 6.12.3 (Required Decorator) and 6.7 (Tasks), 6.6 (Plan Fragments)
Page Number(s): 57 - 60; 68 - 69

Description: The required/optional decorator introduces an inconsistency between CMMN and BPMN. In addition, discretionary tasks can be confused with event sub-processes. The concepts of optional and discretionary have some similitude, and so, they should have similar icons.

Reject issue
Revised Text:

Disposition: Closed, no change

In Table 50, the description of the "Active" state contains two cases, separated by "and/or".
It is obvious that "and" cannot happen, therefore "and/or" should be replaced by "or".

Agree with problematic statement, text in section 7.3.2 has been modified

The reference from Section 5.4.10.5 in the first sentence should be "see 5.4.10.5.1"

Agreed on the issue, modify reference in section 5.4.10.5