Issues for Decision Modeling and Notation 1.1 Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 19688: DMN issue: typo in introduction of "Relating Logic to Decision Requirements" Jira Issue DMN11-4
Issue 19689: DMN issue: InformationItem is not a specialization of Expression Jira Issue DMN11-5
Issue 19690: DMN Issue: typo in 3rd well-formed requirement of KnowledgeRequirement Jira Issue DMN11-6
Issue 19691: DMN issue: date syntax in table 29 Jira Issue DMN11-7
Issue 19692: DMN Issue: Boxed context example of XML data is wrong Jira Issue DMN11-8
Issue 19724: XSD internally inconsistent, does not match the spec Jira Issue DMN11-9
Issue 19731: DMN 1.1 RTF Issue: Negative numerics in decision tables Jira Issue DMN11-13
Issue 19746: output data symbol & comment symbol missing in DRDs Jira Issue DMN11-42
Issue 19754: Define decision service Jira Issue DMN11-45
Issue 19755: Consider date and time datatype in S-FEEL Jira Issue DMN11-46
Issue 19843: Typo error on Business Knowledge Model Jira Issue DMN11-179
Issue 19844: Wrong DecisionTable class diagram (metamodel) Jira Issue DMN11-180

Issue 19688: DMN issue: typo in introduction of "Relating Logic to Decision Requirements" (dmn-rtf)

reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36         The bullet at the top of page 64, in clause 7.1, contains the following garbled sentence: �The variables that are used in the body of the function defined by a business knowledge model element in the DRG must be bound to the information sources each of the requiring decision.�         

reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36         On page 75, in clause 7.3.4, the 6th paragraph starts �As a concrete specialization of Expression, an InformationItem element �.�  However, none of the UML diagrams show a generalization relationship between InformationItem and Expression.     

Reference the DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG document number dtc/14-11-36         On page 61, clause 6.3.12 describes the �Knowledge Requirement metamodel�.  In the section on well-formed KnowledgeRequirements, the third bullet beginning �if the InformationRequirement element �� should instead read �if the KnowledgeRequirement element �.�    

reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36         On page 116, in clause 10.2.2.1, the Beta 2 document introduces Table 29, �String, date, time and duration comparisons, which shows one FEEL Expression: �2012-12-31 in (2012-12-25..2013-02-14)�.  The example is invalid because FEEL has no literal syntax for dates.  This example should use the date() built-in function.         Also, this table should be combined with Table 28, immediately above since they both give examples of the same kind.    

reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36         Clause 10.3.3.3.3 on page 144 shows a boxed context that is supposed to be the equivalent of the XML example shown in clauses 10.3.3.3.1 and 10.3.3.3.2.  This boxed content is missing a horizontal line immediately below the row that contains �tns$Employee�.         

I believe the XSDs are seriously messed up.  On the surface, this would be apparent to anyone who tried to open the level 3 xsd in an XML editor, since the �include� fails right off the bat and the tool goes ding ding ding.  Not only does it point to the wrong filename, but the namespace is different, not allowed with include.  You can fix those things by making the namespaces match and fixing the filespec.  Actually I don�t care that much about the level 3.  I am more concerned with the 14-08-19.xsd, the Level 1 and 2.     That one has an element named ItemDefinition and another one named itemDefinition with different datatype, which is confusing.  I believe that the latter is a pointer to the former.  If so, you will have a lot less confusion by renaming the latter itemDefinitionRef.       But the problem with the XSD goes a lot deeper.  Maybe it is my lack of understanding of the spec, I don�t know.  I think the central problem is that tExpression (the datatype for inputExpression, inputEntry, outputEntry, range of allowed values, and many other elements) is just a list of inputVariables and possibly a single itemDefinition(Ref).  It is NOT an expression, in natural language, S-FEEL, or anything else.  Maybe the intent was to allow literal expressions, but the XSD does not reference tLiteralExpression, just tExpression. Or maybe the intent was to do like BPMN and make tExpression a mixed-content type, where the expression string is the direct content of the element, but the XSD does not say that, either.  Or maybe the intent is to put the expression in the any ##other element or attribute?  That would work but be very weird.  Anyway, without that I think it would be an impossible challenge to serialize even the simplest decision table per the XSD.  And maybe that is why there are no serialization examples in the spec.

The syntaxes defined in 9.1 (S-FEEL grammar) and 10.3.1.2 (FEEL grammar) do not permit decision table input entries to contain negative numeric values.         9.4.3:  An input entry is a simple unary tests, defined using:    14:  simple unary tests    13:  simple positive unary tests    7:  simple positive unary test    8:  interval    18:  endpoint    19:  simple value    33:  simple literal    36:  numeric literal:  [0-9] & �.�         I suggest a numeric literal should be allowed to start with a minus sign.    

    Please add an optional output data symbol and a comment symbol, which I both urgently miss, as discussed in the LinkedIn DMN group at  https://www.linkedin.com/groups/Why-no-output-data-symbol-4225568.S.5976658175284244483      Summary: Why is there no output data symbol in DMN 1.0's DRDs?  Decisions have results, which may be complex, and currently their output data may only be indicated by the decision's name (e.g. "determine X": output is X; "check X": result is Boolean). That is not very clear.       An optional output data symbol would make decision output graphically explicit, and provides for symmetry.    DMN also lacks a comment symbol which could otherwise be used for this on DRDs.

Allow DMN to specify and interchange definitions of decision services, along the lines proposed in Annex B.

a.  In clause 9.2, para 5, first sentence, "date and time" should be in italics.  b.  Why is date and time type excluded from S-FEEL?  This restriction makes XSD mapping problematic.

Here is a slight one (typo error) table 6.1, first row: an � e � is missing into � Knowledge �.    N.B. It is more elegant to not cut a table on several pages, as it was done before, but it is another matter.

The figure 8.18 is NOT the figure of the DecisionTable class diagram (i.e. metamodel).  This diagram was good into the previous beta versions of DMN specification.  This "wrong" diagram was already used as figure 6.8 on page 32 (Decision class diagram i.e. metamodel).