Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — All Issues

  • Acronym: DMN
  • Issues Count: 98
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN12-1 cannot interchange input data style DMN 1.0b1 DMN 1.2 Duplicate or Merged closed
DMN11-3 XMI issues from Pete Rivett DMN 1.0b1 DMN 1.1 Closed; No Change closed
DMN11-1 Change Tracking Document DMN 1.0b1 DMN 1.1 Closed; No Change closed
DMN11-2 Incorporate AB feedback into the FTF Report, the marked-up specification, and the clean specification DMN 1.0b1 DMN 1.1 Closed; No Change closed
DMN11-10 cannot interchange input data style DMN 1.0b1 DMN 1.1 Deferred closed
DMNFTF-149 missing aggregation: BuiltinAggregator attribute type on figure DMN 1.0b1 DMN 1.0 Duplicate or Merged closed
DMNFTF-2 In the metamodel XMI file I found the following with the help of the NIST Validator DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-1 13-08-03.xsd file: DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-4 Stick with own definition of terms in all cases DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-3 Authority Requirement DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-144 We need a beta 2 spec to consolidate Ballots 1-4 DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-143 use round brackets instead of square for IN DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-15 metamodel for structured ItemDefinitions doesn't work DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-14 Improve FEEL specification of decision tables in Chapter 10 DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-13 boxed (tabular) expressions should be encouraged DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-6 boxed function examples lack mandatory parameter lists DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-5 Figure 67 is ambiguous DMN 1.0b1 DMN 1.0 Duplicate or Merged closed
DMNFTF-17 some examples of null handling in section 10.3.4.4. are wrong DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-16 Extend Priority hit policy to multiple-output tables DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-19 Need floor and ceiling builtins DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-18 Add extended timezone specification, as forshadowed in 10.3.4.1 DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-12 Propose to change OrganizationalUnit to OrganizationUnit DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-11 No way to write a date/time literal in simple FEEL DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-8 locationURI, in Import MUST be in URI format DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-7 Figure 2 is misleading DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-10 Propose to remove "type" from KnowledgeSource DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-9 What is DMN namespace? DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-239 8.3.2 accidentally mandates horizontal orientation DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-238 Editorial corrections followup to Issue 99 DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-233 Minor issues DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-232 Beta 5 with attachments DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-54 Decision Table Clause metamodel needs clarification DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-53 Shorthand notation for vertical tables needs clarification/correction DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-55 Decision Table input and output values not labeled consistently and should not be italicized DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-58 7.1 contains mistaken reference to 8.3 DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-56 The tables in 10.3.4.2 - 10.3.4.4 need heading row as in 10.3.4.1 DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-25 Semantics of equality should be clarified DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-24 No builtin or operator for string concatenation. DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-27 Definition of Authority Requirement DMN 1.0b1 DMN 1.0 Duplicate or Merged closed
DMNFTF-26 MM in figure 26 does not share InformationItems for shared InputData and Decisions DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-34 variable should be optional in InformationRequirement DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-36 inconsistent use of term 'average' and 'mean' DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-35 No way to associate to a Decision the ItemDefinition of its outcome without defining decisionLogic DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-29 FEEL filter should not result in singleton list DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-28 Tools may support only a subset of hit policies DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-31 cannot interchange input data style DMN 1.0b1 DMN 1.0 Deferred closed
DMNFTF-32 Beta 1 specification DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-30 Unary builtins with a list argument (e.g. minimum) should be n-ary. DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-61 RFC-2119 language DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-60 Normative References section incomplete DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-49 FEEL grammar should define precedence of boxed expressions DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-52 unary test is not a legal standalone FEEL expression DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-51 remove "smartquotes" from grammar rule 17 b,c DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-50 Grammar rule 51c should require parentheses around multiple tests DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-40 Does DMN support DRDs, Decision Tables, and Expressions independently or in combination? DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-37 All tables and figures should be numbered DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-41 cannot parse date/time/duration ranges DMN 1.0b1 DMN 1.0 Duplicate or Merged closed
DMNFTF-21 Revise Level 1 Conformance DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-20 lexical structure of FEEL is underspecified DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-23 give execution semantics to InputData DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-22 in the DMN Example in 11.3, Application Risk Score is poorly named and pre/post bureau risk category logic is implausible DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-89 No Knowledge Sources in example DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-88 All Decisions have BKMs though this is not necessary DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-74 Overlapping input entries DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-73 Hit policy summarised in one character DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-72 "Evaluation of the expressions in a decision table does not produce side-effects." DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-78 preferedOrientation behaviour DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-77 Aggregation DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-82 Interval rules DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-81 Exponentiation rule DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-76 Output priorities DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-75 Meaning of "same" DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-84 Only comparing named dates - why? DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-83 Grammar rule 9 reference DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-85 Sum weights of recent credit history example DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-80 "as many time" Typo DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-79 S-FEEL open interval syntax DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-71 "Should not conflict with FEEL Syntax" DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-70 "HC" meaning DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-69 Rule numbering DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-68 Decision table example figures DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-67 Decision table introduction DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-66 Decision table examples DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-62 Section 5.2 & 5.3 order DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-65 "value expression of type invocation" point unclear DMN 1.0b1 DMN 1.0 Duplicate or Merged closed
DMNFTF-64 "HIGH DECLINE" example DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-63 Dottedness of dotted lines DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-99 Reference to DMN elements in XML files may be ambiguous DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-102 Decisions are said to have "inputs" and "outputs", however only the "inputs" are shown in the diagrams DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-101 DMN Example should not be limited to automated decisions DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-92 Clarify Authority Requirement notation DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-91 DRD connection rules have no graphical key DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-94 Data Input notation specification and useage DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-93 Boxed Invocation has sparse references after definition DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-95 Can decision tables have zero inputs? DMN 1.0b1 DMN 1.0 Duplicate or Merged closed
DMNFTF-248 Some editorial changes DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-247 Change Tracking Document DMN 1.0b1 DMN 1.0 Deferred closed
DMNFTF-245 Incorporate AB feedback into the FTF Report, the marked-up specification, and the clean specification DMN 1.0b1 DMN 1.0 Deferred closed

Issues Descriptions

cannot interchange input data style

  • Key: DMN12-1
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    We have 2 notations for input data

    1. an oval shape

    2. the name of input data in the requiring decision (so-called Listed Input Data)

    As far as I see, there is nothing in the MM to distinguish these cases,

    so there is no way to interchange the intended notation.

    Proposed: add a new attribute to Decision named listedInputData of type boolean.

  • Reported: DMN 1.0b1 — Sat, 9 Nov 2013 00:33 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    DI supports interchange of listed input data on diagrams

    this issue subsumed and resolved by diagram interchange (DMN12-20)

  • Updated: Wed, 3 Oct 2018 14:17 GMT

XMI issues from Pete Rivett

  • Key: DMN11-3
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    There are some issues with the XMI:

    • The top level element should be a uml:Package not a uml:Model
    • There is a proprietary namespace at the top of the file which should just be deleted: there is no longer any need for such a profile and it should be removed from the original MagicDraw model xmlns:cmof_Profile="http://www.magicdraw.com/schemas/cmof_Profile.xmi">
    • Likewise you don’t need the UML StandardProfileL3.
    • On the other hand you do need a MOF tag to declare the namespace prefix
    • The default value which is an enumeration should have a “type” property referencing the enumeration

    Attached is the updated file.

  • Reported: DMN 1.0b1 — Tue, 19 Aug 2014 07:15 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    these are issues with 1.0 - will try to incorporate into 1.1

    these are issues with the XMI produced for 1.0. We are not changing 1.0.
    I have tried to avoid these issues in 1.1

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

Change Tracking Document

  • Key: DMN11-1
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Map all DMNFTF issues to editing instructions expressed as
    change <snippet from beta 1> to <snippet from change bar document>
    Cover all changes in the cbar document, and comment on changes resulting from multiple issues.

  • Reported: DMN 1.0b1 — Tue, 21 Oct 2014 06:32 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    transferred automatically from FTF

    transferred automatically from FTF

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

Incorporate AB feedback into the FTF Report, the marked-up specification, and the clean specification

  • Key: DMN11-2
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In the FTF Report,
    for DMNFTF-6 and DMNFTF-17, use the format Replace <old text> with <new text>,
    for DMNFTF-93, also use Replace/with, and identify the old text as all occurrences of invokes in 11.3, and
    for DMNFTF-221, describe the change as a restoration of the relative text positions that were unintentionally changed by a prior edit.

    In the specification,
    make changes to mark-up and comments as described in the subtask (issue 246).

  • Reported: DMN 1.0b1 — Sat, 13 Sep 2014 20:37 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    automatically transferred from FTF

    nothing to do in RTF

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

cannot interchange input data style

  • Key: DMN11-10
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    We have 2 notations for input data

    1. an oval shape

    2. the name of input data in the requiring decision (so-called Listed Input Data)

    As far as I see, there is nothing in the MM to distinguish these cases,

    so there is no way to interchange the intended notation.

    Proposed: add a new attribute to Decision named listedInputData of type boolean.

  • Reported: DMN 1.0b1 — Sat, 9 Nov 2013 00:33 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    defer to 1.2

    no proposal submitted for 1.1

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

missing aggregation: BuiltinAggregator attribute type on figure

  • Key: DMNFTF-149
  • Legacy Issue Number: 19469
  • Status: closed  
  • Source: gmail.com ( Remigiusz Wasilewski)
  • Summary:

    Figure 37 DecissionTable class diagram

    Class DecissionTable
    Attribute aggregation
    missing
    DataType - BuiltinAggregator
    Default - COLLECT.

  • Reported: DMN 1.0b1 — Fri, 13 Jun 2014 04:00 GMT
  • Disposition: Duplicate or Merged — DMN 1.0
  • Disposition Summary:

    small DT MM change combined w/ other issue

  • Updated: Tue, 21 Apr 2015 01:19 GMT

In the metamodel XMI file I found the following with the help of the NIST Validator

  • Key: DMNFTF-2
  • Legacy Issue Number: 18967
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There is the unsatisfied href to 08-11-13.xmi. If you really want to extend BMM it should use the proper OMG URI for Objective within BMM. This is just completing BMM 1.2

    • DecisionTable::aggregation has no datatype: I assume it should be BuiltInAggregator
    • DecisionTable::aggregation property’s default value of COLLECT is not validly specified. Easy once you set the type
    • The default value of DecisionTable::hitPolicy of UNIQUE is differently but also not validly specified. In MD I was easily able to delete the Opaque Expression by right-clicking the default value; and then it gave me the correct list from the enumeration
    • The association outputClause2outputEntry has an owned constraint with body of “ordered”. Ordering should be specified at the property level (which is what you have done) so the constraint should just be deleted. BTW by convention association names should start with a capital.
    • The association DecisionTable2rule has an owned constraint with body of “ordered”. Ordering should be specified at the property level (which is what you have done) so the constraint should just be deleted. BTW by convention association names should start with a capital.
    • There is an association end property on class Import of type Definitions that is not named
    • There should be a MOF Tag for the namespace Prefix (and optionally the nsURI)
  • Reported: DMN 1.0b1 — Mon, 23 Sep 2013 04:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    XMI has been corrected of the errors listed in the issue, and modified to account for the resolutions of other issues when relevant. The final XMI document passes NIST validator (except for the references to the BMM and BPMN metamodels, wihch ar enot loaded in the validator).

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

13-08-03.xsd file:

  • Key: DMNFTF-1
  • Legacy Issue Number: 18966
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There is inconsistency in the values for BuiltInAggregator – the model (and section 7.2.13 of the spec) includes AVERAGE, the XSD instead has ANY.

    • The following attributes are inconsistent: they declare a type of anyURI but then provide a default value that is not a URI:
    • <xsd:attribute name="expressionLanguage" type="xsd:anyURI" use="optional" default="FEEL" />
      <xsd:attribute name="typeLanguage" type="xsd:anyURI" use="optional" default="FEEL" />
    • I’m concerned about the many definitions which use xsd:qName as the type of elements. I don’t like the very non-standard use of qNames described in 11.3.2 of the spec: I don’t see why normal hrefs cannot be used for external files
    • <xsd:element name="drgElement" type="xsd:QName" minOccurs="0" maxOccurs="unbounded" />
  • Reported: DMN 1.0b1 — Mon, 23 Sep 2013 04:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    1. There is inconsistency in the values for BuiltInAggregator – the model (and section 7.2.13 of the spec) includes AVERAGE, the XSD instead has ANY

    --> corrected in bmi-13-08-03 (corrected issue 1).xsd (also replacing FIRST with COUNT) [attached]

    2. The following attributes are inconsistent: they declare a type of anyURI but then provide a default value that is not a URI:
    a. <xsd:attribute name="expressionLanguage" type="xsd:anyURI" use="optional" default="FEEL" />
    b. <xsd:attribute name="typeLanguage" type="xsd:anyURI" use="optional" default="FEEL" />

    --> Change target namespace for level 3 (FEEL) XSD to http://www.omg.org/spec/FEEL/20140401 and use that URI for FEEL. No URI specific to Simple FEEL. Corrected in bmi-13-08-03 (corrected for issue 1).xsd [attached]

    3. I’m concerned about the many definitions which use xsd:qName as the type of elements. I don’t like the very non-standard use of qNames described in 11.3.2 of the spec: I don’t see why normal hrefs cannot be used for external files: <xsd:element name="drgElement" type="xsd:QName" minOccurs="0" maxOccurs="unbounded" />

    --> move to new issue DMNFTF-99

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Stick with own definition of terms in all cases

  • Key: DMNFTF-4
  • Legacy Issue Number: 19098
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Since DMN is a standard (and in particular claims to be a business standard), then it must stick with its own definition of terms in all cases. Otherwise, in what sense is it a standard (especially a business standard)?

    In defining “decision” DMN had two fundamental choices (from Merriam-Webster Unabridged dictionary):

    1. a : the act of deciding; specifically : the act of settling or terminating (as a contest or controversy) by giving judgment

    1. b : a determination arrived at after consideration : SETTLEMENT, CONCLUSION

    DMN explicitly chose the first meaning. I strongly prefer the second, but then I’m a big fan of all things declarative. So in BRS TableSpeak an outcome by definition is a decision.

    Since DMN explicitly chose the first meaning, however, an outcome (conclusion) is by definition not a decision. A decision is an act, never the result of the act.

    If DMN somehow allows ‘overloading’ of the term “decision” – the central term in the standard – all bets are off. For example I have read elsewhere that the 'output' of a decision can be treated as a decision in DMN.

    A term that you can use any way you want when it happens to suit you is a term that has not been standardized at all.

  • Reported: DMN 1.0b1 — Tue, 19 Nov 2013 05:00 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    This comment appears to have been made against an earlier draft.
    After review of the current beta draft, the task force believes the definition of decision as an act of choosing among possible options is the correct definition, and is consistent with the current text. This captures the notion of applying decision logic in the making of a decision.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Authority Requirement

  • Key: DMNFTF-3
  • Legacy Issue Number: 19067
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    In the glossary (p. 166), the definition of "Authority Requirement" reads "The dependency of a decision or business knowledge model on a knowledge source which provides a source of authority for the decision logic.".

    Figure 13, however, shows two Authority Requirement dependencies in which knowledge source is the dependent item. So Input Data and Decision can provide a source of authority for the knowledge source. This seems confirmed by the text under "b" at the bottom of p. 34.

    Point 1. The definition appears to need revision.

    Point 2. To say "Input Data and Decisions can provide sources of authority for analytic models." seems to me to be really stretching the English language. I've never heard anyone in either business or IT say something like that. Perhaps this is aimed at some Community I'm not familiar with? It seems like over reduction, or over abstraction, or over something, to me.

  • Reported: DMN 1.0b1 — Tue, 5 Nov 2013 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    I have proposed a number of edits to resolve this issue and create a consistent definition that handles the various uses.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

We need a beta 2 spec to consolidate Ballots 1-4

  • Key: DMNFTF-144
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    We need a beta 2 spec to consolidate Ballots 1-4, making it easier to propose further document changes that incorporate agreed-upon changes.

  • Reported: DMN 1.0b1 — Fri, 23 May 2014 19:45 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Consolidate resolutions from Ballots 1-4 into a beta 2 specification.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

use round brackets instead of square for IN

  • Key: DMNFTF-143
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    change maritalStatus in ["M","S"] to maritalStatus in ("M","S")

  • Reported: DMN 1.0b1 — Fri, 23 May 2014 18:28 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    change in ["M","S"] to in ("M","S")

  • Updated: Tue, 21 Apr 2015 01:19 GMT

metamodel for structured ItemDefinitions doesn't work

  • Key: DMNFTF-15
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Consider an ItemDefinition (ID) for an Invoice that contains 2 sub-items, shippingAddress and billingAddress, both of type Address, containing sub-items street and city, both strings, etc.

    Clearly, Invoice, Address, and string are all IDs. But shippingAddress, billingAddress, street, and city are not IDs. Rather, they are InformationItems. The MM in Figure 26 of the spec has an itemComponentRef from ID to ID. This is an attempt to model a compound ID like Invoice as a collection of sub-IDs. This incorrect. Invoice is a collection of 2 sub-InformationItems, shippingAddress and billingAddress. Both these IIs refer to the Address ID. The Address ID in turn is a collection of IIs for street, city, etc. These have an ID of string.

    Proposal: replace itemComponentRef (in Figure 26) with a composition from ID to II named itemComponent.

    The ID (e.g. Invoice) owns its itemComponents (e.g. shippingAddress and billingAddress).

  • Reported: DMN 1.0b1 — Tue, 12 Nov 2013 19:47 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Removed the ItemComponentRef attribute and added an ItemComponent class

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Improve FEEL specification of decision tables in Chapter 10

  • Key: DMNFTF-14
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    section 10.3.2.7 should be removed, and 10.3.4.5 should refer to figures in section 8.2, and the formal semantics should be aligned with the informal semantics. Replace all refs to 'rule test (cell)' with 'input entry'.

  • Reported: DMN 1.0b1 — Wed, 20 Nov 2013 17:55 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    replace clauses 10.3.2.7 and 10.3.4.5 with the attached

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:
    • DT.doc 47 kB (application/msword)

boxed (tabular) expressions should be encouraged

  • Key: DMNFTF-13
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    last paragraph of 6.1 of the alpha spec says:

    Using a value expression of type invocation is never required, even when possible: FEEL specifies its own invocation mechanism for more complex usages, and a FEEL literal expression can always be used instead of a value expression of type invocation.

    I would like this to say instead:

    A boxed invocation SHOULD be used instead of a literal FEEL invocation when possible. In general, a boxed expression SHOULD be used instead of a literal FEEL expression when possible. Note that Conformance Level 3 specifies additional boxed expressions.

    Because 'boxed expression' isn't defined until 6.2, the rewritten para should be moved to the end of 6.2 (or even 6.3)

    Also, I notice that 6.1 defines a decision table to be a tabular representation of decision logic. Would it be a good idea to do a global replace of 'boxed expression' with 'tabular expression'?

  • Reported: DMN 1.0b1 — Wed, 7 Aug 2013 22:36 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Define boxed expressions available at each conformance level, and recommend their use over equivalent literal expressions.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

boxed function examples lack mandatory parameter lists

  • Key: DMNFTF-6
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    According to alpha version section 9.2.1.7, a boxed function (decision logic for a BKM) must have a parameters box and a body box.
    Figure 8 is misleading or wrong, the boxed expression for Business knowledge 1 should be a boxed function (have a parameters box and body box instead of 'value expression' box.
    All these examples - Figures 59, 61, 63, 65, 67, 69, 71, 74, 75, 77, need a parameters box beneath the name box. That is because these examples must be boxed functions, because they are invoked by the boxed invocations in Figures 58, 60, etc.

    The consistency of the invocation logic, e.g. Figures 58, 60, etc. may be misleading. The actual parameters and formal parameters just happen to always be the same identifier. This is not required, and in fact is why it is important to list the formal parameters in the boxed function, so that the actual parameters can be substituted properly. For example, valid alternatives to Figure 66 include the following expression text in a box:

    Application risk score model (Applicant Data . Age, Applicant Data . Marital Status, Applicant Data . Employment Status)

    or the following:

    Application risk score model (Marital Status: Applicant Data . Marital Status, Employment Status: Applicant Data . Employment Status, Age: Applicant Data . Age)

    Note that Figures 74 and 77 desperately need parameter lists in order to know how to match actuals to formals in invocations.

    One last example - a decision table dt1 with input x-y and some rules. There would be at least 2 ways to invoke dt1. E.g. dt1(x: 1, y: 2) and dt1(x-y: -1).The different invocations would result in different parses of the target function. In the first, x-y is a subtraction whereas in the second, x-y is a name. To avoid this problem,
    you need a context, independent from any invocation, to indicate whether x-y is a name, or whether x and y are the names. Explicit parameter names attached to the boxed function definition provides such a context. Thus, the decision table needs to be the body in a boxed function definition, which is to say, there needs to be both the DT and the parameter list. The parameter list is a box containing (x,y) or (x-y). These are the parameters for all invocations.

  • Reported: DMN 1.0b1 — Fri, 24 May 2013 19:12 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Allow decision table notation to serve as a boxed function, i.e., not require parameter lists, if the input expressions are simple and can be interpreted as parameter names.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Figure 67 is ambiguous

  • Key: DMNFTF-5
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The Figure can be interpreted as a boxed context, with 2 entries. First entry is the DT named partial score, and the second entry is the unnamed result, containing 'Aggregate = sum', which looks like valid FEEL, but is not intended to be. BTW, the valid FEEL is 'sum(partial score)'. Isn't this as clear as 'Aggregate = sum' ?

  • Reported: DMN 1.0b1 — Sat, 25 May 2013 05:27 GMT
  • Disposition: Duplicate or Merged — DMN 1.0
  • Disposition Summary:

    This is a duplicate of the Aggregation issue.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

some examples of null handling in section 10.3.4.4. are wrong

  • Key: DMNFTF-17
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    and(true,null,true) should be null.

    A better example is

    and(false,null,true) = false

    Also,

    and(0)=or(0)=and(null)=or(null)=null

    We get to define the truth values of and([]), or([]) (0-ary and/or). RIF says and()=true and or()=false, so we'll go with that.

  • Reported: DMN 1.0b1 — Mon, 28 Oct 2013 23:01 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Revise examples as indicated.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Extend Priority hit policy to multiple-output tables

  • Key: DMNFTF-16
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    Priority and Output order hit policies are not supported for compound output tables.

    Jacob Feldman commented in the LinkedIn DMN group:

    "Building real-world decision models, practitioners always face complex issues related to diagnostic and resolution of rule conflicts. Some systems can effectively verify decision model consistency and diagnose rule conflicts. But until recently there were no practically used BR products that claim that they may automatically resolve rule conflicts.

    "While we did not had an update about the current state of the DMN for a while, it does not seem that the first version will include any means to define superiority relations among contradictory rules. I believe at some point DMN may and should be extended in this direction."

    (This was functionality I originally wanted, too, but for some reason we did not cover it in v1.)

    The example he provides could be handled by a very simple extension to DMN (see attached file). I propose we extend the Priority and Output order hit policies to compound output decision tables, by making the first output column the Priority marker regardless of how many columns there are.

  • Reported: DMN 1.0b1 — Mon, 4 Nov 2013 14:47 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    In clause 8.2.11, replace:

    "To reduce complexity, decision tables with compound outputs support only the following hit policies: Unique, Any, First, Rule order and Collect without operator, because the priority schema or collect operator over multiple outputs are undefined."

    with the attached.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Need floor and ceiling builtins

  • Key: DMNFTF-19
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    FEEL has but one kind of number. There is no integer type.

    Sometimes, it is required to convert a number such as 1.7 to the number 1.

    This is not easy with the existing set of builtins. Note that decimal(1.7, 0) = 2.

    Proposed:

    floor(1.7) = 1

    ceiling(1.1) = 2

    x[i] = x[floor(i)]

  • Reported: DMN 1.0b1 — Mon, 28 Oct 2013 22:32 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Add floor and ceiling builtins

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Add extended timezone specification, as forshadowed in 10.3.4.1

  • Key: DMNFTF-18
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    At the end of 10.3.4.1, we have the text:

    Issues:

    1. Extended time zone, e.g. 23:59:00@America/Los_Angeles

    As the SBVR date/time spec notes, the timezone offset from XML date-times (referenced by FEEL)
    is insufficient for most business uses, because it does not handle daylight savings time well.
    Unfortunately, the SBVR spec gives a complex metamodel but no usable syntax.

    I propose that we make the minor extension suggested by the current spec text. Wherever a timezone offset (i.e. +/-HH:MM) can appear in the lexical space of a date/time, an 'extended timezone' can be used. E.g.
    2014-02-06T23:59:00@America/Los_Angeles instead of 2014-02-06T23:59:00-08:00.

    The timezone IDs and associated time zone offsets (which change due to DST and other legal decrees) are maintained at http://www.iana.org/time-zones

  • Reported: DMN 1.0b1 — Mon, 28 Oct 2013 22:58 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Because the IANA tz form is commonly used in Java, Python and other implementation languages, implementers consider it desirable to support it, even though it extends the XML Schema standard forms in a way that has no formal designation. The specification of FEEL conversion operators in clause 10.3.4 is therefore modified to support the IANA form as a valid alternative.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Propose to change OrganizationalUnit to OrganizationUnit

  • Key: DMNFTF-12
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    The BMM metamodel has an OrganizationUnit class, that is referenced from BMM::BMM::Objective, which is itself associated with DMN::Decision

    The DMN metamodel has an OrganizationalUnit placeholder class. Although the two classes do not play the same role in BMM and DMN, obviously, it might be a good idea, from an adoption and implementation viewpoint, as well as from the future evolution viewpoint, to give them the same name...

  • Reported: DMN 1.0b1 — Tue, 6 Aug 2013 17:27 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    Changing the name will not help much if future versions of DMN need to share the same class as is used in BMM to represent organisational units. On the other hand, using the class BMM::OrganisationUnit in DMN would require extending it (i.a. to make it a subclass of BusinesContextElement, and thus of DMNElement),which does not make much sense, since BMM;;OrganisationUnit, like DMN::OrganisationalUnit, is a placeholder, "anticipating a defnition to be adopted from other OMG meta-models, such as OMG OSM when it is further developed".
    So that neither change is worth the effort.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

No way to write a date/time literal in simple FEEL

  • Key: DMNFTF-11
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    one must write something like date("2001-09-11") but this is technically an invocation of a builtin (not a BKM) which is not allowed at level 2

  • Reported: DMN 1.0b1 — Thu, 1 Aug 2013 16:37 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    We need to allow an invocation with a string literal argument to be a simple literal. This will allow typographical date/time literals to be used in S-FEEL and in FEEL range expressions.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

locationURI, in Import MUST be in URI format

  • Key: DMNFTF-8
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    Update 10 says only that it is a string.

  • Reported: DMN 1.0b1 — Thu, 1 Aug 2013 14:30 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    already applied to alpha/beta specs

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Figure 2 is misleading

  • Key: DMNFTF-7
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The figure shows 3 levels:
    1. DRD
    2. boxed expressions
    3. FEEL

    and groups 1&2 as notation.

    The problem is, FEEL is both notation and semantics.

    The figure shows the FEEL semantic function, and thus is highlighting the semantic aspect of FEEL. The fact that the cells in the boxed expressions contain FEEL syntax is not highlighted.

    The figure could be improved in one of 2 ways:
    1. rename the callout from 'Expression Language (FEEL)' to 'Execution Semantics'. This more accurately describes the FEEL(...) in the dotted ovals, or
    2. delete the FEEL(...) in the dotted ovals. Instead, callout some FEEL expressions from above, e.g., Application.Date - Application . Applicant Date of Birth, not(UK), <18, etc.

  • Reported: DMN 1.0b1 — Sun, 7 Jul 2013 22:16 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Implement improvement 2 from the description.

    Also, there is a problem in the boxed invocation. The cell with

    Application.Date - Application.Applicant Date of birth

    does not result in a numeric age (it results in a days and time duration).

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Propose to remove "type" from KnowledgeSource

  • Key: DMNFTF-10
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    KnowledgeSource has a"type" attribute that is not explained or documented anywhere, only mentioned in table 13.

    I propose that we remove it from DMN 1.0: KnowledgeSources may have a description, anyway, since they are DMNElements.

  • Reported: DMN 1.0b1 — Thu, 1 Aug 2013 14:38 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Explain the intent of type.

  • Updated: Tue, 21 Apr 2015 01:19 GMT


8.3.2 accidentally mandates horizontal orientation

  • Key: DMNFTF-239
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In clause 8.3.2, as revised by Issue 54 resolution, the last paragraph before Table 24 reads:
    "In a tabular representation of the containing instance of DecisionTable, the representation of an instance of Clause depends on the orientation of the decision table. For instance, if the decision table is represented horizontally (rules as row, see section 7.2.2), instances of Clause are represented as columns, ... All the instances of Clause made of a set of inputEntry (that is, the input clauses), MUSTSHALL be represented on the right left of any instance of Clause made of a set of outputEntry (or output clauses)."
    This "For instance" suddenly becomes a rule, and it is only true when the table is represented horizontally. When the table is represented vertically (which is a different "for instance"), the inputs must be ABOVE the outputs, not to the LEFT of them.
    The text should be corrected to give both rules, or neither.

  • Reported: DMN 1.0b1 — Wed, 6 Aug 2014 15:58 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    separate inputs and outputs

    inputs before outputs in horizontal tables - not explicit

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Editorial corrections followup to Issue 99

  • Key: DMNFTF-238
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    I attach proposed editorial corrections to the replacement text adopted as the resolution to Issue 99.

  • Reported: DMN 1.0b1 — Wed, 6 Aug 2014 15:48 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    minor wording change

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Minor issues

  • Key: DMNFTF-233
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    Lists minor issues and edits in comments, for application in the beta 5

  • Reported: DMN 1.0b1 — Thu, 31 Jul 2014 16:37 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    correct minor typos as indicated in issue attachment and comment

    correct minor typos

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Beta 5 with attachments


Decision Table Clause metamodel needs clarification

  • Key: DMNFTF-54
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    I am having trouble mapping the specified decision table notation and semantics in 8.2 to the metamodel in 8.3. Let me just interject some comments in red on some beta1 spec text:
    8.3.2 Decision Table Clause metamodel
    In a decision table, a clause
    clause is a new term that is not used in the definition of the notation or semantics in 8.2. I am neutral about whether or not this is a useful concept/name (some old DT literature calls these 'stubs'). As suggested below, this should really be an abstract superclass of what we are elsewhere calling inputs and outputs (if needed at all) specifies a subject this italicized term implies it should be defined somewhere, or used in the MM, but it is not, which is defined by an input expression good, input expression is defined and used extensively and I think consistently throughout the spec or an output domain this is an undefined term. I think output values may be intended, and the finite set of the sub-domains of the subject’s domain that are relevant for the piece of decision logic that is described by the decision table the italics are mine, this time. I think input values are intended here.
    In DMN 1.0, the class Clause is used to model a decision table clause.
    An instance of Clause is made of an optional inputExpression and of a set of inputEntry, or of an optional name and a set of outputEntry, which are instances of Expression. A Clause element MUST have a set of inputEntry if it has an inputExpression, it MUST have a set of outputEntry if it does not have an inputExpression. A Clause element MUST NOT have both inputEntry and outputEntry
    An instance of Clause may have a name, which is a String, and it may reference an outputDefinition, which is an ItemDefinition element. An instance of Clause that does not have an inputExpression MUST reference an outputDefinition. An instance of Clause that contains an inputExpression MUST NOT reference an outputDefinition. If a Clause element that references an outputDefinition does not have a name, its default name is the name of the referenced ItemDefinition element.
    .It seems this could be represented more succinctly as 2 disjoint subclasses, Input(Clause) and Output(Clause). I think the outputDefinition is required iff output values are present in the decision table
    The valueDefinition of an inputEntry element MUST be Boolean an example inputEntry is [21..35[ and this certainly is not Boolean and it MAY be omitted. The inputEntry elements MUST test the value of its containing clause’s inputExpression, possibly implicitly. The inputExpression is something like age and the inputEntry is something like [21..35[. The execution semantics are defined by mapping to FEEL age in [21..35[. But this FEEL in expression is not stored explicitly in the MM!
    ...
    In a tabular representation of the containing instance of DecisionTable, the representation of an instance of Clause depends on the orientation of the decision table. For instance, if the decision table is represented horizontally (rules as row, see clause 8.2.2), instances of Clause are represented as columns, with the inputExpression or the name of the Clause element represented in the top cell, its domain of value optionally listed in the cell below, and each of the cells below representing one of the inputEntry or outputEntry in the Clause. All the instances of Clause made of a set of inputEntry, MUST be represented on the right of any instance of Clause made of a set of outputEntry.The above paragraph is concerned with linking the notation and the MM. This is made more difficult due to the introduction here of a new concept Clause, which is not defined where the other notation elements of input expression, input entry, etc. are defined in 8.2. Also, not all of the notation elements from 8.2 are accounted for here by name (e.g. input values, output values, and compound (multiple) output. We should not re-specify the notation here using different terminology from 8.2. We should use the same terminology to make the linkage between MM and notation simple, obvious, and complete

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 22:58 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Proposed edits in the text of the Clause and DecisionRule metamodel descriptions (sections 8.3.2 and 8.3.3) to better align the terminology with section 8.1 and 8.2.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Shorthand notation for vertical tables needs clarification/correction

  • Key: DMNFTF-53
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    This section raises a few related issues, listed below:

    1. In Fig 35, the labels 'output entry a', 'output entry b', 'output entry c' should instead be 'output value 1a', 'output value 1b', 'output value 1c'
    2. It is misleading that the column with optional input/output values in Fig 36 is dropped in Fig 35. This column is optional independent of whether or not the 'shorthand' is employed. I think it should be possible to use the shorthand and also display the allowed values for the inputs (e.g. input value 1a, ...), but this might look ugly. Either way, we need to specify this clearly.
    3. Why call this format a 'shorthand'? It is really limited-entry outputs. Whether or not it is 'shorter' depends on application values. It is curious that we previously (in 8.2.8) dismiss limited-entry inputs as not interesting. It seems no more or less interesting than limited-entry outputs.
    4. The metamodel has no attributes that distinguish whether or not to use the shorthand. So whereas we interchange a DT's orientation, we do not interchange whether to use 'shorthand' output entries or not.
    5. Because the metamodel uses a Clause for both inputs and outputs, we could add a boolean 'limitedEntry' attribute to Clause and thereby support limited entry inputs and outputs. There is something appealing about supporting limited entry for both inputs and outputs, or for neither.
    6. Limited entry seems to work for both horizontal and vertical orientation. Why limit to vertical?
    7. There is nothing that states that every rule must have exactly 1 'X' in its limited output entry cells. I think we must say that, in Fig 35, 'output entry 1a' is the column of 3 cells containing, from top to bottom, 'X', '-', '-'. The constraint is that exactly 1 of the output entry's cells must contain an 'X', and the others must contain a '-'.
    8. Why use '-' instead of a blank cell? '-' means something different in input entries.
  • Reported: DMN 1.0b1 — Tue, 11 Feb 2014 23:36 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Clarify shorthand notation for vertical tables with revised text and figures.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Decision Table input and output values not labeled consistently and should not be italicized

  • Key: DMNFTF-55
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In figs 31, 32, 33, 34, we have 'input value 1a', 'output value 1a' etc whereas in figs 27, 28, 36 we only have 'value 1a', etc for both input values and output values.
    Also, we should not use italics to represent an optional cell because italics are used to represent a typographical string literal.

    In addition, the revised text corrects many related decision table issues and includes many editorial improvements.

  • Reported: DMN 1.0b1 — Thu, 13 Feb 2014 19:56 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Input and output entries labeled consistently.
    Cells indicated in inverse are optional.
    Numerous related decision table issues are resolved.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

7.1 contains mistaken reference to 8.3

  • Key: DMNFTF-58
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    should this be 10.2.1.7?

  • Reported: DMN 1.0b1 — Wed, 19 Feb 2014 22:41 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Revise reference.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

The tables in 10.3.4.2 - 10.3.4.4 need heading row as in 10.3.4.1

  • Key: DMNFTF-56
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The heading row, with column heads Name(parameters), Parameter Domain, Description, Example should be present in all 4 tables.

  • Reported: DMN 1.0b1 — Wed, 19 Feb 2014 21:10 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Copy the header from the table in 10.3.4.1 onto the tables in 10.3.4.2, 10.3.4.3 and 10.3.4.4.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Semantics of equality should be clarified

  • Key: DMNFTF-25
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In the semantic domain, we use boldface '=' to mean identity. But in FEEL syntax, italic '=' is specified in 9.3.2.11, primarily in table entries for grammar rule 51.a.

    (side comment: all the tables in 9.3.2.11 need table numbers.)

    Also confusingly, the semantic mapping table entry for 51.a where FEEL Syntax is 'e1 < e2' also applies to 'e1 = e2'. This must be clarified.

    To avoid doubt about whether '=' means equals or identical, we should write identical(a,b) (or 'a is b') instead of a=b when inquiring whether or not 2 elements of the semantic domain are identical. For example,

    identical("1", 1) is false

    "1" = 1 is null

    We should clarify the existing rules that imply that

    1/0 = null is true

    1/0 = 1/0 is null

    1/0 != 1/0 is null

    1/0 != null is false

    1/0 in (0, null) is true

    By symmetry, we should also have

    null = 1/0 is true

    null != 1/0 is false

    The semantic rules don't explicitly cover the symmetry.

    Semantics of if/then/else must be clarified as 'if identical(test, true) then ... else ...' A true test result will return the interpreted then part. A false or null (or anything other than true) test result will return the interpreted else part. Similarly, a list filter retains list items where the test is true and omits items where the test evaluates to anything other than true.

  • Reported: DMN 1.0b1 — Thu, 2 Jan 2014 23:42 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Revise FEEL semantics in clause 10.3 as indicated.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

No builtin or operator for string concatenation.

  • Key: DMNFTF-24
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    I think the intent was to overload '+', so that

    1 + 1 = 2

    "1" + "1" = "11"

    "1" + 1 = null (incompatible input types)

    If so, then we need to add a row in the table on pg 119 of the revised submission to account for the string case.

  • Reported: DMN 1.0b1 — Thu, 2 Jan 2014 23:12 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Overload '+' for string concatenation

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Definition of Authority Requirement

  • Key: DMNFTF-27
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    From Ron Ross:

    In the glossary (p. 166), the definition of "Authority Requirement" reads "The dependency of a decision or business knowledge model on a knowledge source which provides a source of authority for the decision logic.".

    Figure 13, however, shows two Authority Requirement dependencies in which knowledge source is the dependent item. So Input Data and Decision can provide a source of authority for the knowledge source. This seems confirmed by the text under "b" at the bottom of p. 34.

    Point 1. The definition appears to need revision.

    Point 2. To say "Input Data and Decisions can provide sources of authority for analytic models." seems to me to be really stretching the English language. I've never heard anyone in either business or IT say something like that. Perhaps this is aimed at some Community I'm not familiar with? It seems like over reduction, or over abstraction, or over something, to me.

    Thx,

    Ron

  • Reported: DMN 1.0b1 — Wed, 6 Nov 2013 14:50 GMT
  • Disposition: Duplicate or Merged — DMN 1.0
  • Disposition Summary:

    We agreed it is a duplicate of the other issue

  • Updated: Tue, 21 Apr 2015 01:19 GMT

MM in figure 26 does not share InformationItems for shared InputData and Decisions

  • Key: DMNFTF-26
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Consider a DRD with 10 decisions that all require the same InputData I. The DRD will have 10 InformationRequirement arrows, and the MM will have 10 InformationRequirement instances. Because, according to Fig 26, the InformationRequirement owns the InformationItem, then there will be 10 (hopefully) identical copies of the InformationItem for I. Why is this a good idea? What happens if the 10 copies diverge in value?

    Proposal: InputData and Decision should own the InformationItem that denotes their output.

  • Reported: DMN 1.0b1 — Tue, 12 Nov 2013 20:56 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    The revised text does not completely resolve the issue, but it reflects agreement that imported DRD elements may need to be referenced by something more than a simple Name.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

variable should be optional in InformationRequirement

  • Key: DMNFTF-34
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    According to the beta, the "variable" attribute is mandatory in the definition of an InformationRequirement.

    However, it is useful only if the decisionLogic of the requesting Decision element is defined AND that decisionLogic uses the corresponding InformationItem.

    It is not blocking to have to create and carry around the InfoItem anyway, but it is inconvenient. There is a risk that validating implementations will reject models where the unused variables are not defined.

  • Reported: DMN 1.0b1 — Tue, 21 Jan 2014 15:50 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Propose to make variable optional in InformationRequirement (so you do not have to create and interchange it, e.g. when no decision logic is specified that uses it)

  • Updated: Tue, 21 Apr 2015 01:19 GMT

inconsistent use of term 'average' and 'mean'

  • Key: DMNFTF-36
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The FEEL builtin is called 'mean' but when aggregation is defined, and in the MM, 'average' is used.

  • Reported: DMN 1.0b1 — Thu, 23 Jan 2014 19:54 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Replace "average" with "mean"

  • Updated: Tue, 21 Apr 2015 01:19 GMT

No way to associate to a Decision the ItemDefinition of its outcome without defining decisionLogic

  • Key: DMNFTF-35
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    Whereas the items from InputData can be defined by associating an ItemDefinition to the InputData element, the only way to define the outcome of a decision is by associating a decisionLogic to the Decision, and an ItemDefinition to the decisionLogic.

    Proposal: Add an outcomeDefinition association that is an ItemDefinition to Decision, and make the itemDefinition of a decisionLogic a derived attribute (or otherwise constrain the itemDefinition of the decisionLogic to be the same as the outcomeDefinition of the owning Decision).

  • Reported: DMN 1.0b1 — Tue, 21 Jan 2014 16:02 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Proposed resolution to add an optional outputDefinition attribute to the Decision element, and to require that the output definition of a decision be the same as the item definition of its decision logic, if they are all specified.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

FEEL filter should not result in singleton list

  • Key: DMNFTF-29
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    given a list L = [10, 20, 30]

    L[1] = 10

    L[item = 10] = [10]

    L[item = 10][1] = 10

    Proposed:

    L[item = 10] = 10

    Note that because a non-null non-list element is treated as a singleton list when used in a list context, the following still holds:
    L[item = 10][1] = 10

  • Reported: DMN 1.0b1 — Mon, 28 Oct 2013 22:40 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Singleton list is equal to its content

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Tools may support only a subset of hit policies

  • Key: DMNFTF-28
  • Status: closed  
  • Source: K.U. Leuven ( Mr. Jan Vanthienen)
  • Summary:

    7.2.11 Hit policy

    p. 74

    "Tools may support only a subset of hit policies, but the table type must be clear and therefore the hit policy indication is mandatory."

    The empty subset is not considered valid.

  • Reported: DMN 1.0b1 — Tue, 5 Nov 2013 00:12 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Require unique hit policy to be supported.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

cannot interchange input data style

  • Key: DMNFTF-31
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    We have 2 notations for input data

    1. an oval shape

    2. the name of input data in the requiring decision (so-called Listed Input Data)

    As far as I see, there is nothing in the MM to distinguish these cases,

    so there is no way to interchange the intended notation.

    Proposed: add a new attribute to Decision named listedInputData of type boolean.

  • Reported: DMN 1.0b1 — Sat, 9 Nov 2013 00:33 GMT
  • Disposition: Deferred — DMN 1.0
  • Disposition Summary:

    Defer the issue. Everything else related to interchanging the notation and layout as been deferred (except decision table orientation).

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Beta 1 specification

  • Key: DMNFTF-32
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Convert the 'alpha' DMN submission into an OMG specification. Only boilerplate and formatting may change. There will be no changes to technical material. This will give a more appropriate baseline for subsequent change proposal.

  • Reported: DMN 1.0b1 — Mon, 20 Jan 2014 18:10 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Change from submission to OMG spec boilerplate.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Unary builtins with a list argument (e.g. minimum) should be n-ary.

  • Key: DMNFTF-30
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    For example, in addition to minumum([1,2]) FEEL should accept minimum(1,2). In both cases, the result is 1.

  • Reported: DMN 1.0b1 — Mon, 28 Oct 2013 22:21 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    make the following builtins n-ary: min, max, sum, mean, and, or

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

RFC-2119 language

  • Key: DMNFTF-61
  • Legacy Issue Number: 19212
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Congratulations on using RFC-2119 language pretty consistently ("must", "should" etc). However, if the spec ever gets sent to ISO, it would have to switch to ISO language. The main difference is that ISO insists on "shall" instead of "must". Fortunately, "shall" is also in RFC-2119, so by switching all instances of "must" to "shall", you can comply with both. See: http://isotc.iso.org/livelink/livelink?func=ll&objId=4230456

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Replace all occurrences of "MUST" with "SHALL", many occurrences of "should" with "SHOULD".

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Normative References section incomplete

  • Key: DMNFTF-60
  • Legacy Issue Number: 19211
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    The Normative References section is very incomplete. The specification includes parts of JSON, PMML and Java by reference, so we need references to their defining documents. There are probably others too.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    The Normative References list is modified to reflect all specifications that are normatively referenced in the body of the DMN specification. Some references in the body of the specification are corrected to refer to the names of the normative references introduced in Clause 3.

    The reference to IETF RFC 2119 is deleted, because the requirements keywords have been changed to those mandated by ISO Directives.

    The sole reference to RIF, in Annex A, is not normative, and apparently refers to the RIF-PRD specification as a relative of OMG PRR.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

FEEL grammar should define precedence of boxed expressions

  • Key: DMNFTF-49
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    It is unclear whether the following is syntactically correct

    {x:1}.x=1

    or whether the following must be used:

    ({x:1}).x=1

    The intent is that both are correct.

  • Reported: DMN 1.0b1 — Sun, 9 Feb 2014 19:22 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Split grammar rule 1 into 1a and 1b and note in the 'Additional Syntax Rules':

    Operator precedence is given by the order of the alternatives in grammar rules 1, 2 and 4. E.g., (boxed) invocation has higher precedence than multiplication, multiplication has higher precedence than addition, and addition has higher precedence than comparison. Addition and subtraction have equal precedence, and like all FEEL infix binary operators, are left associative.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

unary test is not a legal standalone FEEL expression

  • Key: DMNFTF-52
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Grammar rule 2i shows:

    i. literal | unary test | name | "(" , textual expression , ")" ;

    A unary test such as "-" or "not(1,3)" can only be used as notation within a decision table condition cell and do not directly map to the semantic domain. For example, the following is not valid:

    not(1)=0

    Proposal: replace grammar rule 2i with

    i. literal | simple positive unary test | name | "(" , textual expression , ")" ;

    Note: make corresponding change in simple feel and review the mappings of "-" and "not" to ensure they map to FEEL that does have valid syntax and semantics.

  • Reported: DMN 1.0b1 — Sun, 9 Feb 2014 19:57 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    change grammar rule 2i in clause 10.3.1.2

  • Updated: Tue, 21 Apr 2015 01:19 GMT

remove "smartquotes" from grammar rule 17 b,c

  • Key: DMNFTF-51
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    grammar rules have msword artifacts by mistake.

  • Reported: DMN 1.0b1 — Sun, 9 Feb 2014 19:44 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    replace 'smartquotes' with regular quotes

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Grammar rule 51c should require parentheses around multiple tests

  • Key: DMNFTF-50
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Correct syntax should be

    color in (red, green, blue)

    not

    color in red, green, blue

  • Reported: DMN 1.0b1 — Sun, 9 Feb 2014 19:39 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    change grammar rule 51c and add 51d as proposed

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Does DMN support DRDs, Decision Tables, and Expressions independently or in combination?

  • Key: DMNFTF-40
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The paragraph is:
    Again, although Figure 2 depicts these decision modeling constructs as interlinked, it is possible to use them independently or in any combination. For example, it is possible to use DMN only to draw DRDs, or only to define decision tables, or only to write FEEL expressions.

    However, the reality is that It is not possible to interchange a DT or an expression in a standard way without a containing DRG. The DT and expression MM is in Figure 26 of the alpha/beta 1 spec. To interchange a DT or expression directly, it would need to be immediately contained in a Definitions. By the MM in Figure 16, this isn't allowed.

    Given that we do not support independent interchange, I think this paragraph in the spec is misleading. From an interchange point of view, you cannot have a 'standalone' decision table or expression. Semantically, 'standalone' expressions are usually not very interesting. Usually, expressions are interpreted in a context (which comes from the DRG, containing boxed context, formal parameters, etc.). The context must also be interchanged.

  • Reported: DMN 1.0b1 — Thu, 23 Jan 2014 23:21 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Delete the offending paragraph.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

All tables and figures should be numbered

  • Key: DMNFTF-37
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Many tables in chapter 10 are not numbered. This makes it difficult to reference these tables. They should be numbered even if they are not referenced in the spec text. Also, it seems that many tables that are numbered have their caption on top, whereas the figures have their caption on bottom. Is this intentional?

  • Reported: DMN 1.0b1 — Thu, 23 Jan 2014 20:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Number all tables in Clause 10.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

cannot parse date/time/duration ranges

  • Key: DMNFTF-41
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    A date range can be written (using typographical literals) as, e.g., [2012-01-01Z..2013-01-01Z)
    This is defined to be [date("2012-01-01Z")..date("2013-01-01Z")). The grammar rules do not permit range endpoints to be invocations. We need to slightly generalize the syntax to support typographical literals without allowing arbitrary expressions (which causes difficulty because '[ expr' also looks like the start of a list).

  • Reported: DMN 1.0b1 — Thu, 23 Jan 2014 23:58 GMT
  • Disposition: Duplicate or Merged — DMN 1.0
  • Disposition Summary:

    adding 'date time literal' resolves both issues

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Revise Level 1 Conformance

  • Key: DMNFTF-21
  • Status: closed  
  • Source: International Business Machines ( Mr. Dave Ings)
  • Summary:

    Opening on behalf of Barb and Larry:

    Larry and I would like to raise an issue allowing for Rule Families to be compliant for Level 1 DMN Conformance. I believe, this has always been our intent and would not be comfortable if we couldn't be Level 1 conforming.

    The good news is that I believe I have a very simple edit-change to the document that should be acceptable to all:

    Current text (page 16): An implementation claiming conformance to Conformance Level 1 shall comply with all of the specifications set forth in sections 5 (Decision Requirements), 6 (Decision Logic) and 7 (Decision Table) of this document.

    Revised text (page 16): An implementation claiming conformance to Conformance Level 1 shall comply with all of the specifications set forth in sections 5 (Decision Requirements), 6 (Decision Logic) and, if using decision tables, 7 (Decision Table) of this document.

    So, this revision preserves the decision table formats for compliance but also allows for other representations that work.

  • Reported: DMN 1.0b1 — Mon, 30 Sep 2013 15:57 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    conformance levels have been extensively discussed and level 1 shall include both DRDs and decision tables with 'uninterpreted' expressions

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

lexical structure of FEEL is underspecified

  • Key: DMNFTF-20
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    the language 'alphabet' is not directly specified. E.g. 'and' is a keyword, so is 'ham and eggs' a legal name? What about 'return date'?

  • Reported: DMN 1.0b1 — Mon, 28 Oct 2013 22:18 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    The grammar rules are fine but we need a 4th and 5th 'additional syntax rule' at the end of 10.3.1.2

  • Updated: Tue, 21 Apr 2015 01:19 GMT

give execution semantics to InputData

  • Key: DMNFTF-23
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The table in 10.4 shows that InputData is associated with a 'sample data' boxed expression. There is no such association in the metamodel. The intent is that the input data values come from 'somewhere' and are mapped to the FEEL domain AS IF the input data was given by a literal FEEL expression. For example, if the input data is XML, then the mapping is described in 10.3.3. This needs to be explained here.

  • Reported: DMN 1.0b1 — Mon, 25 Nov 2013 23:18 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    define notion of binding case data to InputData, and that the case data can be notated as a boxed expression

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:
    • FeelDMSemantics.docx 16 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

in the DMN Example in 11.3, Application Risk Score is poorly named and pre/post bureau risk category logic is implausible

  • Key: DMNFTF-22
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The problem is that higher risk scores mean lower risk. This is not intuitive, and indeed the risk category decision tables require existing customers to have lower risk (higher scores) than new customers, which is likely not the intent.

  • Reported: DMN 1.0b1 — Thu, 29 Aug 2013 05:37 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Exchange "true" and "false" in the Existing Customer column.

  • Updated: Tue, 21 Apr 2015 01:19 GMT


All Decisions have BKMs though this is not necessary

  • Key: DMNFTF-88
  • Status: closed  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • Summary:

    In the example every decision is linked to a BKM and decision tables/decision logic are specified only for the BKMs. The notation does not require a BKM for each decision and this is a common point of confusion. Those decisions that do not use reusable logic should be linked directly to decision tables instead leaving the reused logic (affordability for instance) as a BKM.

  • Reported: DMN 1.0b1 — Thu, 20 Mar 2014 21:09 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Replace figures 1 and 2.
    Changes to clause 11 (Example) are described in 193 (subtask to issue 101).

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Overlapping input entries

  • Key: DMNFTF-74
  • Legacy Issue Number: 19225
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Decision tables with the Unique hit policy do not contain rules with overlapping input entries" should be "Decision tables with the Unique hit policy SHALL NOT contain rules with overlapping input entries". You should also specify absolutely precisely what "overlapping" means. All through this section 8.2.11, please substitute ISO/RFC 2119 language (e.g. "A single hit table returns the output of one rule only" -> "A single hit table SHALL return the output of one rule only").

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Define overlapping and disjoint rules and inputs.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Hit policy summarised in one character

  • Key: DMNFTF-73
  • Legacy Issue Number: 19224
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "the hit policy is summarized using a single character in a particular decision table cell." Please expand this sentence by saying precisely which character (i.e. the initial letter of Unique, Any, Priority, First) and which cell.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Specify precise hit policy codes and locations.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

"Evaluation of the expressions in a decision table does not produce side-effects."

  • Key: DMNFTF-72
  • Legacy Issue Number: 19223
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Evaluation of the expressions in a decision table does not produce side-effects." Since those expressions can include calls to external Java code, this Ain't Necessarily So. Better to put this outside the scope of conforming implementations by saying something like: "Where expressions in a decision table are are expressed solely in FEEL, with no externally-defined functions, their evaluation does not produce side-effects. The behaviour of decision tables that call externally-defined functions with side-effects is undefined."

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Expand on the definition and rationale for no side-effects. We say elsewhere that externally defined functions should not have side-effects - this is true in general and is not specific to decision tables.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

preferedOrientation behaviour

  • Key: DMNFTF-78
  • Legacy Issue Number: 19229
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "An instance of DecisionTable SHOULD BE represented as specified by its preferedOrientation, as defined in clause 8.2.2." You're saying that a conforming implementation is allowed to read a Decision Model written by another tool but display it with a different orientation. This is will greatly upset users, who get very attached to graphical elements being displayed exactly as they drew them. I suggest changing this to "An instance of DecisionTable SHALL be represented as specified by its preferedOrientation, as defined in clause 8.2.2."

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    The preferred orientation is preferred and this preference is something that vendors must maintain. However it is a PREFERRED orientation so there is not requirement that it be used to display the table.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Aggregation

  • Key: DMNFTF-77
  • Legacy Issue Number: 19228
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    For "count", you need to specify carefully whether the result is the number of rules that match or the number of distinct outputs (they're different if two or more rules return equal outputs). Specify how aggregation is specified in the written decision table (I only found out from the example on a later page).

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    aggregation replaced by collect operator

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Interval rules

  • Key: DMNFTF-82
  • Legacy Issue Number: 19233
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    is in the interval [e1..e2] also noted [e1..e2], if and only if o ≥ e1 and o ≤ e1". This "also noted" subclause is redundant. The follow bullet has a typo: "is in the interval [e1..e2] also noted [e1..e2[" should be "is in the interval [e1..e2) also noted [e1..e2[" (See what I mean about those backwards brackets being confusing? .

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Revise text as indicated.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Exponentiation rule

  • Key: DMNFTF-81
  • Legacy Issue Number: 19232
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Arthmetic exponentiation (grammar rule 4c) is defined as the multiplication of the first operand by itself as many time as indicated by the second operand. It is defined only when the first operand is a number and the second operand is an integer." Given the context, "integer" should presumably read "positive integer". But why the constraint? 1.2**3.6 is perfectly well-defined. Is there a good reason to outlaw it? Also, "Arithmetic" is misspelled.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    don't restrict the exponent to be an integer.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Output priorities

  • Key: DMNFTF-76
  • Legacy Issue Number: 19227
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Output priorities are specified in an ordered list of values, for example, the list of expected output values." I don't understand how this is different from the "First" single hit policy, or how/where this list of output priorities is specified (other than in the rule order). Please clarify.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Clarify that the output priority is given by the order of output values.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Meaning of "same"

  • Key: DMNFTF-75
  • Legacy Issue Number: 19226
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "all of the matching rules show the same output". Please precisely specify what "same" means here (presumably all output entries are equal using the equal operator defined for their type). What happens if a table specifies "Any", but a pair of matching rules return non-equal outputs? Presumably the behaviour is undefined.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Define that 'same' means equal, and that if the hit policy is Any and two matched rules do not have equal output entries, the result is undefined.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Only comparing named dates - why?

  • Key: DMNFTF-84
  • Legacy Issue Number: 19235
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Dates, times, and durations may be compared, but only if they have been given names" Why? Given that there is a syntax for specifying anonymous dates (e.g. date("2012-12-25")), why force dates to be named before they can be compared?

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Allow typographical date/time/durations to be compared, and use underline in Table 27 to callout the unary tests so as not to conflict with typographical styles (italic and bold italic)

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Grammar rule 9 reference

  • Key: DMNFTF-83
  • Legacy Issue Number: 19234
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "An expression to be tested satisfies an instance of simple unitary tests (grammar rule 9) ..." That "9" should be "14".

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Revise reference to grammar rule.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Sum weights of recent credit history example

  • Key: DMNFTF-85
  • Legacy Issue Number: 19236
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Are you sure this example is syntactically valid? It contains an anonymous date, which section 10.2.2.1 says is illegal (see previous issue report), and a use of [ ] that doesn't seem to have anything to do with intervals.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Add descriptions to FEEL examples in clause 10.6

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

"as many time" Typo

  • Key: DMNFTF-80
  • Legacy Issue Number: 19231
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Typo: "as many time" -> "as many times".

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Correct the typo.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

S-FEEL open interval syntax

  • Key: DMNFTF-79
  • Legacy Issue Number: 19230
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    guarantee that the syntax for open intervals that potentially involves brackets facing the wrong way will drive users crazy (e.g. "[1..5["). The alternative syntax that uses unmatched bracket types (e.g, "(1..5]") is almost as bad. There must be a better way!

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    See for example http://en.wikipedia.org/wiki/Interval_(mathematics)
    There's even an ISO standard: http://en.wikipedia.org/wiki/ISO_31-11

  • Updated: Tue, 21 Apr 2015 01:19 GMT

"Should not conflict with FEEL Syntax"

  • Key: DMNFTF-71
  • Legacy Issue Number: 19222
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Table entries "SHOULD NOT conflict with FEEL syntax" (4 places). OK, I know why you're saying this, but that "SHOULD NOT" is such a weak statement as to be useless. I suggest making it part of the conformance criteria: "At Conformance level 1, there is no restriction on table entries, which are not interpreted. However, at conformance levels 2 or 3, table entries SHALL comply with FEEL syntax".

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Add an expression language URI to indicate that expressions are not meant to be machine interpreted; edit text to introduce the URI and clarify its recommended usage.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

"HC" meaning


Rule numbering

  • Key: DMNFTF-69
  • Legacy Issue Number: 19220
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "The ordering is represented by the explicit numbering of the rules in the diagrammatic representation of the DecisionTable." This seems to be the only place that rule numbering is mentioned. Please introduce it (even if only with one sentence) in section 8.2. Specify exactly how rules are numbered (integers? Natural numbers? Any sequence with a total ordering? Is numbering mandatory? Must the numbers be sequential? Can I "number" my three-rule table "A" "B" and "M"?).

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Define rule numbers as consecutive natural numbers starting with 1.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Decision table example figures

  • Key: DMNFTF-68
  • Legacy Issue Number: 19219
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Fig 27, 28, 30, 31, 32 ... In several of these figures the "value 1a", "output entry 1a" etc labels are the same or different across rows and columns for no apparent reason. If there's no reason for them to match, please make them all different (e.g. I'm pretty sure there's no reason for putting "value 1a" in both the input and output columns in Figure 27). Otherwise it's confusing.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Split each figure into two: a schematic layout and an example, to better explain the decision table cell contents.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Decision table introduction

  • Key: DMNFTF-67
  • Legacy Issue Number: 19218
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "IF input expression 1 matches x AND ..." The word "matches" is a bit vague - I think "satisfies" would be better - and perhaps supply a couple of extra sentences saying what this means for S-FEEL and non-S-FEEL Decision Tables.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Issues 55, 66-70, and 74 all affect clauses 8.1-8.2.2. Combined revised text is attached

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Decision table examples

  • Key: DMNFTF-66
  • Legacy Issue Number: 19217
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Decision tables (section 8, p 70 onwards). Almost all the decision table examples and explanations have two input expressions. It would be worth making clearer that all decision tables (other than crosstab tables) can have 1, 3, 4 ... input expressions.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    examples with 3 inputs added

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Section 5.2 & 5.3 order

  • Key: DMNFTF-62
  • Legacy Issue Number: 19213
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    IMO sections 5.3 "Scope and uses of DMN" and section 5.2 "Basic concepts" should be in the other order. To have read section 5.3 would be useful background when first reading 5.2.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Swap sections 5.2 (Basic Concepts) and 5.3 (Scope and Uses of DMN)

  • Updated: Tue, 21 Apr 2015 01:19 GMT

"value expression of type invocation" point unclear

  • Key: DMNFTF-65
  • Legacy Issue Number: 19216
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Using a value expression of type invocation is never required, even when possible: FEEL specifies its own invocation mechanism for more complex usages, and a FEEL literal expression can always be used instead of a value expression of type invocation." I'm not clear what point is being made here.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DMN 1.0
  • Disposition Summary:

    The resolution of DMNFTF-13 removes the paragraph that is at issue. Nothing further to do.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

"HIGH DECLINE" example

  • Key: DMNFTF-64
  • Legacy Issue Number: 19215
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    'To avoid having to discerning whether HIGH, DECLINE is "HIGH" "DECLINE" or "HIGH, DECLINE", typographical string literals should be free of "," characters.' Why not "SHALL be free of" commas? Also, broken grammar: "having to discerning".

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Ban commas from typographical string literals and correct grammar.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Dottedness of dotted lines

  • Key: DMNFTF-63
  • Legacy Issue Number: 19214
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    fig 22 - The dotted line style used in this figure, and throughout the specification is indistinguishable from a solid line on my printer. Make the "dottedness" more apparent?

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Dotted lines are too hard to distinguish in some renderings. Use solid lines instead.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Reference to DMN elements in XML files may be ambiguous

  • Key: DMNFTF-99
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    DMN elements are referenced by their ID with the same file, and by a QName built from a prefix and their ID, where the prefix in the QName must be assigned to the namespace of the Definitions element that contains the referenced element.

    However, two different definitions in two different XML files may be in the same namespace: since ID are unique only within their XML file, two different DMN elements can, therefore, have the same reference.

    One way to repair that would be by using a bare name XPointer as the value of an XLink href attribute instead, for referencing DMN elements, where the XPointer would consist of the URL of the file containing the Definitions suffixed with the element's ID (separated by #).

  • Reported: DMN 1.0b1 — Tue, 1 Apr 2014 14:50 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Replacement for 12.3.2: Proposes to use href attribute w/o XLink with bare Xpointers to reference DMN elements that may need be referenced across Definitions elements (and thus across XML files).

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Decisions are said to have "inputs" and "outputs", however only the "inputs" are shown in the diagrams

  • Key: DMNFTF-102
  • Legacy Issue Number: 19331
  • Status: closed  
  • Source: MITRE ( Mihail Popov)
  • Summary:

    The definition of "Decision" on page 23, section 5.2.1 defines "Decision" as an activity ("act"). It mentions a Decision has an "output" value, however, an "output" shape coming out from the decision activity is not shown in the diagrams.

    It may be useful to draw and show an output shape coming out from the Decision box. That could be named "Decision output".

    This suggestion applies to Figures 1, 2, 3, 4, 5 and other similar diagrams. While the value of the decision output may not need to be explicitly depicted on all BPMN process diagrams and on other diagrams, at least the initial few diagrams where the concepts are defined it should be depicted explicitly.

    On Figure 1, in the Decision Model area, the dotted line connecting this area to the BPMN model should have a label such as "Routing Decision Output" (which the BPMN diagram implicitly assumes has a value of "ACCEPT" or "DECLINE". Similarly, diagrams 2, 3, 4, and 5 could have an "Decision Output" coming out of the Decision box and connected to it with an arrow pointing from the Decision shape to the Decision Output shape.

  • Reported: DMN 1.0b1 — Tue, 8 Apr 2014 04:00 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    We do not want every decision (including sub-decisions) to have both a decision symbol (rectangle) and some symbol for the output. This would add clutter for no reason, because every decision has exactly 1 output. We discussed the possibility of having only the 'top' decision(s) show an output, but again, this is not needed and it is possible to discern the top decisions - those that are not required by any other decision.
    Finally, we note that decisions have much metadata that can be used to link decisions to BPM activities, provide business motivation, etc. There is no standard notation for much of this metadata, so as not to over-constrain tools.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

DMN Example should not be limited to automated decisions

  • Key: DMNFTF-101
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The overall process is (up to) 3 top-level decisions:
    1. decide strategy
    2. decide routing
    3. review application and decide to Accept or Decline
    Why do we not model the 3rd decision (to some level of detail) and associate it with the human task just like other decisions are associated with the business rule tasks?

  • Reported: DMN 1.0b1 — Tue, 8 Apr 2014 19:11 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Update DMN Example with human decisions (and decisions without BKMs)

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Clarify Authority Requirement notation

  • Key: DMNFTF-92
  • Legacy Issue Number: 19290
  • Status: closed  
  • Source: Knowledge Partners, Inc. ( Paul Vincent)
  • Summary:

    It is unclear (i.e. unspecified) what are the use cases for connecting Knowledge Sources to Decisions versus Knowledge Sources to Business Knowledge (models) in the cases where the Knowledge Source is the Authority for the Decision or Business Knowledge (model). The text does not make the case for either scenario in DRDs containing all 3 entities.

    Example: Customers may connect a Knowledge Source as the authority to either or both the Decision or its related Business Knowledge (model).

    Suggested resolution: A table defining the use cases for connecting a Knowledge Source to a Decision, Business Knowledge (model)

  • Reported: DMN 1.0b1 — Wed, 19 Mar 2014 04:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Replace the text of clause 6.2.3 as follows:

  • Updated: Tue, 21 Apr 2015 01:19 GMT

DRD connection rules have no graphical key

  • Key: DMNFTF-91
  • Legacy Issue Number: 19289
  • Status: closed  
  • Source: Knowledge Partners, Inc. ( Paul Vincent)
  • Summary:

    Confusion over the notation has been propagated even before the DMN spec is finalised. For example see http://www.slideshare.net/alcedocoenen/intro-dmn-10 slide 19 which was a conference presentation on DMN gives incorrection notation interpretation. Another example was a customer version of a DMN DRD that demonstrated confusion over the shape and connector meanings.

    Suggested resolution:
    Add a graphical notation to the text of the cells in table in chapter 6.2.3 pg 35 showing shape-connector-shape to avoid any possible misinterpretation

  • Reported: DMN 1.0b1 — Wed, 19 Mar 2014 04:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Add graphical notation to the text in the table in 6.2.3

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Data Input notation specification and useage

  • Key: DMNFTF-94
  • Legacy Issue Number: 19292
  • Status: closed  
  • Source: Knowledge Partners, Inc. ( Paul Vincent)
  • Summary:

    Input Data entity definition appears to be quite sparse versus the data specification requirements likely to be needed in decision modelling. Also not well represented in the ch 11 DMN Example where it is used there for input samples rather than input specifications.

    Example: an end user defined a DRD and labelled the Input Data in their DRD with the name of the XSD of the data source. They then questioned how to annotate an Input Data with a specific named XSD - especially is the input data is constrained to a 3rd party format (such as an industry standard that is specified as an XSD), which they considered (as a tag) a business level concept, even if the details of the XSD might not be.

    Suggestion: Input Data should be more vigorously defined e.g. as a specification of input data / source (message, invocation, etc) associated with Boxed Invocation, maybe renamed Source of Data. Sample Data could be specified as a Knowledge Source for Input Data. Specifications of the format (e.g. industry XSDs) of Input Data could also be Knowledge Sources

  • Reported: DMN 1.0b1 — Wed, 19 Mar 2014 04:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Distinguish input data from case data.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Boxed Invocation has sparse references after definition

  • Key: DMNFTF-93
  • Legacy Issue Number: 19291
  • Status: closed  
  • Source: Knowledge Partners, Inc. ( Paul Vincent)
  • Summary:

    Boxed Invocation is defined in Ch7.2.3. In Ch8 Decision Table "builds on" Ch7 but has no reference to Boxed Invocation (e.g. while one might expect a reference with regard to invocation of Decision Tables). Likewise Annex B refers to Decision services but has no reference to Boxed Invocations.

    Example: an end-user defined a DRD and associated Decision Tables (to reflect BKMs) expected to have to define Boxed Invocations to represent the interface to Decision Tables.

    Suggested solutions:
    1. Either add an explanation that Boxed Invocations are conceptual and only relevant to FEEL, or add how they are represented when defining Decision Tables (Ch8) and in the DMN Example (Ch11) and Annex on Decision Services (Ann B).

    2. Show the DMN XMI model for the DMN example relating the example to the metamodel concepts in preceding chapters including Boxed Invocations.

  • Reported: DMN 1.0b1 — Wed, 19 Mar 2014 04:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    In order to make it more explicit which figures in clause 11 are boxed invocations, in 11.3, change 'invokes' to 'is a boxed invocation of'

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Can decision tables have zero inputs?

  • Key: DMNFTF-95
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    It is not clear from the spec whether it is valid to have a decision tables with no inputs. In such a table all rows would always be true (i.e. facts, rather than rules). This would be useful on occasions, e.g. for generating a list of items to be filtered in subsequent decisions (although it would be possible to provide the same functionality using boxed contexts or raw FEEL).

    Is this valid? If so we need to provide an example.
    If not the spec needs to be clarified anyway.

  • Reported: DMN 1.0b1 — Tue, 25 Mar 2014 12:15 GMT
  • Disposition: Duplicate or Merged — DMN 1.0
  • Disposition Summary:

    0 input decision tables are explicitly allowed in beta3 (there is no example)

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Some editorial changes

  • Key: DMNFTF-248
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    After careful review, we have found several minor wording changes to the final DMN specification that have been (or soon will be) made but do not have approved editing instructions. The resolution to this issue will provide thtese instructions.

  • Reported: DMN 1.0b1 — Mon, 3 Nov 2014 00:52 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    minor edits

    see attached

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Change Tracking Document


Incorporate AB feedback into the FTF Report, the marked-up specification, and the clean specification

  • Key: DMNFTF-245
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In the FTF Report,
    for DMNFTF-6 and DMNFTF-17, use the format Replace <old text> with <new text>,
    for DMNFTF-93, also use Replace/with, and identify the old text as all occurrences of invokes in 11.3, and
    for DMNFTF-221, describe the change as a restoration of the relative text positions that were unintentionally changed by a prior edit.

    In the specification,
    make changes to mark-up and comments as described in the subtask (issue 246).

  • Reported: DMN 1.0b1 — Sat, 13 Sep 2014 20:37 GMT
  • Disposition: Deferred — DMN 1.0
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was deferred to the next Task Force

  • Updated: Fri, 6 Mar 2015 20:57 GMT
  • Attachments: