OMG Specification

Decision Model and Notation — Closed Issues

Acronym: DMN
Issues Count: 721
Description: Issues resolved by a task force and approved by Board

Issues Summary

Key	Issue	Reported	Fixed	Disposition	Status
DMN16-212	ONNX not mentioned in one sentence	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-208	Single-parameter number() function is needed	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-91	Binary operators should not return null	DMN 1.5	DMN 1.6b1	Resolved	closed
DMN16-117	Returning null is not enough for reporting/handling errors	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-135	Copyright section needs update	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-93	Rounding functions introduced in DMN 1.4 should have single parameter version	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-132	Outdated reference to machine readable files	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-90	Allow ONNX as well as PMML functions	DMN 1.5	DMN 1.6b1	Resolved	closed
DMN16-71	Friendly enough cohersion to string	DMN 1.4b1	DMN 1.6b1	Duplicate or Merged	closed
DMN16-105	number(from) function does not accept number as input	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-134	External Function Definitions should be optional	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-85	Grammar rule does not match with the one proposal - typo	DMN 1.5b1	DMN 1.6b1	Closed; No Change	closed
DMN16-128	Examples use typeRef for BKMs incorrectly	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-205	New Namespace URIs needed	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-137	Acknowledgements for DMN 1.6 contributors needed	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-64	Clarification on syntax of DMNReference needed	DMN 1.3	DMN 1.6b1	Resolved	closed
DMN16-68	No Mapping of FEEL to JSON	DMN 1.4	DMN 1.6b1	Resolved	closed
DMN16-37	Knowledge Package Model and Notation (KPMN)	DMN 1.2b1	DMN 1.6b1	Closed; No Change	closed
DMN16-48	Figure 8-20 shows wrong parent for UnaryTests	DMN 1.3	DMN 1.6b1	Resolved	closed
DMN16-61	Change to the "at literal" in FEEL	DMN 1.3	DMN 1.6b1	Closed; No Change	closed
DMN16-28	Collect decision tables	DMN 1.1	DMN 1.6b1	Resolved	closed
DMN16-73	Incorrect names for parameters	DMN 1.4b1	DMN 1.6b1	Resolved	closed
DMN16-11	Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration	DMN 1.1	DMN 1.6b1	Resolved	closed
DMN16-16	Lexical representation of time string has ambiguous definitions	DMN 1.1	DMN 1.6b1	Resolved	closed
DMN16-104	Missing paragraph break and new constraintType	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-94	Filter and Iterator in attribute should not require a collection	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-5	XSD: global context	DMN 1.0	DMN 1.6b1	Closed; No Change	closed
DMN16-55	No way to tell that a Decision iterates over a collection	DMN 1.3	DMN 1.6b1	Closed; No Change	closed
DMN16-18	More Generic Ways to Define Decision Table Properties	DMN 1.1	DMN 1.6b1	Closed; No Change	closed
DMN16-4	Business Knowledge Model can have Information Requirements	DMN 1.0	DMN 1.6b1	Closed; No Change	closed
DMN16-2	No notation for ItemDefinition	DMN 1.0	DMN 1.6b1	Closed; Out Of Scope	closed
DMN16-13	Improve description of built-in function string()	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-12	Clarification needed if null is passed as value for optional parameter of built in function	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-1	Business Context links go both ways	DMN 1.0	DMN 1.6b1	Deferred	closed
DMN16-72	FEEL descendants operator	DMN 1.4b1	DMN 1.6b1	Resolved	closed
DMN16-50	Missing semantics for multiple imports	DMN 1.3	DMN 1.6b1	Resolved	closed
DMN16-82	Behaviour when decimal is provided but integer expected	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-81	Range of scale for number is open to interpretation	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-24	Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122	DMN 1.1	DMN 1.6b1	Closed; No Change	closed
DMN16-92	Inconsistent capitalization of datatypes names	DMN 1.5b1	DMN 1.6b1	Resolved	closed
DMN16-3	italics and bold used for both typographic literal notation and FEEL semantic exposition	DMN 1.0	DMN 1.6b1	Deferred	closed
DMN16-10	No adjustment for last day in month if duration is added/subtracted to date and time value	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-7	Enhancement suggestion: make unary tests first class citizens of the FEEL language	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-9	Should encapsulated decisions of a decision service include output decisions?	DMN 1.0	DMN 1.6b1	Deferred	closed
DMN16-8	Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-6	Include Test Cases in Decision Model	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-19	Scope of decision table input/output entries is not well defined in the specification	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-15	Add two new concrete numeric types, make number abstract	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-20	How to get FEEL type if evaluation is not an option?	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-17	FEEL grammar readability	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-25	Semantic domain mapping for simple expressions	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-21	Can an expression in user defined function body reference a name outside of it's scope?	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-14	Can the same Definitions/namespace be used by more than one model?	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-35	inconsistent date comparisons make unavoidavle paradoxes	DMN 1.2	DMN 1.6b1	Deferred	closed
DMN16-22	Should name declarations in same context fail or overwrite?	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-23	Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-31	notion of arbitrary order conflicts with lack of an unordered collection data type	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-34	DMN Models need a default timezone	DMN 1.2	DMN 1.6b1	Deferred	closed
DMN16-32	Unspecified conclusion is not supported	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-33	Fix interchange of links to objects in BPMN/BMM	DMN 1.2	DMN 1.6b1	Deferred	closed
DMN16-26	Requested additional built-in functions	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-42	Support for recursive calls by Business Knowledge Models	DMN 1.2	DMN 1.6b1	Deferred	closed
DMN16-36	Shared Data Model and Notation (SDMN)	DMN 1.2b1	DMN 1.6b1	Deferred	closed
DMN16-46	"instance of" not possible with some built-in functions	DMN 1.2b1	DMN 1.6b1	Deferred	closed
DMN16-47	Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-38	Temporal precision inconsistencies	DMN 1.2b1	DMN 1.6b1	Deferred	closed
DMN16-39	Provide better spec and examples for Equality, Identity, and Equivalence	DMN 1.2b1	DMN 1.6b1	Deferred	closed
DMN16-40	Friendlier handling of null values	DMN 1.2b1	DMN 1.6b1	Deferred	closed
DMN16-30	need set operations and equality in FEEL	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-27	Metamodel constraints & validation	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-29	In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement	DMN 1.1	DMN 1.6b1	Deferred	closed
DMN16-41	Lack of visual notation for processing of / iteration over lists in FEEL	DMN 1.2	DMN 1.6b1	Deferred	closed
DMN16-45	Inconsistency DMNv1.2 dropping [a]=a and get entries example	DMN 1.2b1	DMN 1.6b1	Deferred	closed
DMN16-49	Add an itemKind property to ItemDefinition	DMN 1.3b1	DMN 1.6b1	Deferred	closed
DMN16-56	P0D == P0Y in SFEEL, but it is unclear if P0D == P0Y in FEEL	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-57	the operation of is() function is not well specified	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-44	properly define type(e)	DMN 1.2	DMN 1.6b1	Deferred	closed
DMN16-43	Clarification on DMN case sensitivity of timezones	DMN 1.2	DMN 1.6b1	Deferred	closed
DMN16-51	Spec does not mandate that all user-defined function parameters are utilised	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-59	FunctionItem `parameters` array attribute is plural, not singular in name	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-54	No way to show relative multiplicity of decisions and their information requirements	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-52	Spec does not mandate that all formal parameters are utilised.	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-58	Ambiguous named params for before() and after() range functions	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-112	XML serialization is not human friendly	DMN 1.5b1	DMN 1.6b1	Deferred	closed
DMN16-53	DRG requirements only state am unused knowledge requirement is illegal	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-69	Importing libraries of functions is not business friendly	DMN 1.4b1	DMN 1.6b1	Deferred	closed
DMN16-60	Allow for partial temporal values	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-63	Allow input data to be of type Interval	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-62	Adding a new interval built-in function	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-66	Missing InformationItem Association?	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-70	Interchanging models that use external libraries of functions is complicated	DMN 1.4b1	DMN 1.6b1	Deferred	closed
DMN16-67	Functions cannot invoke external services	DMN 1.4	DMN 1.6b1	Deferred	closed
DMN16-65	Links with other standards	DMN 1.3	DMN 1.6b1	Deferred	closed
DMN16-125	ambiguity for collections	DMN 1.4b1	DMN 1.6b1	Deferred	closed
DMN16-77	No way to show dependencies of a grey-box decision service	DMN 1.5	DMN 1.6b1	Deferred	closed
DMN16-123	Clarification on the FEEL sort function with the precedes function	DMN 1.5b1	DMN 1.6b1	Deferred	closed
DMN16-119	Knowledge Sources are not fit for ML or AI purposes	DMN 1.5	DMN 1.6b1	Deferred	closed
DMN16-106	Duplicated names and labels	DMN 1.5b1	DMN 1.6b1	Deferred	closed
DMN16-79	Relation conforms to and equivalent do not cover functions with variable arguments	DMN 1.5b1	DMN 1.6b1	Deferred	closed
DMN16-78	It is not possible to assign a default value to a data type	DMN 1.4	DMN 1.6b1	Deferred	closed
DMN16-101	No binding to Python functions	DMN 1.5	DMN 1.6b1	Deferred	closed
DMN16-130	Frequently changing Namespace URIs cause market fragmentation	DMN 1.5b1	DMN 1.6b1	Deferred	closed
DMN16-215	Wrong placement of useAlternativeInputDataShape attribute in the DMN specification document	DMN 1.5b1	$issue.fixedSpecification.name	Deferred	closed
DMN11-26	DecisionRule, InputClause & OutputClause should have ID and label for referencing in execution logs	DMN 1.0	DMN 1.1	Resolved	closed
DMN12-133	DRD elements must be labeled with their name	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-89	Label versus name attribute	DMN 1.1	DMN 1.2	Resolved	closed
DMN15-159	New Namespace URIs needed	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-74	Incorrect typeRef for variables associated to BKMs	DMN 1.3	DMN 1.5	Resolved	closed
DMN15-104	Acknowledgements for DMN 1.4 and 1.5 contributors needed	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-155	Superfluous spaces after "1"	DMN 1.4	DMN 1.5	Resolved	closed
DMN15-157	Copyright section needs update	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-153	Multiple empty imports using the order as a precedence is not allowed	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-119	Incorrect function name in example	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-118	Typo in Table 66	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-56	Typos in meta model	DMN 1.2	DMN 1.5	Resolved	closed
DMN15-135	Precision on Allowed Values UnaryTests	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-65	spec places unrealistic constraints on decision expressions and BKM parameter bindings	DMN 1.3	DMN 1.5	Resolved	closed
DMN15-44	Clarification regarding equivalence of date vs date and time	DMN 1.2	DMN 1.5	Resolved	closed
DMN15-6	Depiction of Input Data is not harmonized with BPMN and CMMN	DMN 1.1	DMN 1.5	Resolved	closed
DMN15-121	It is not possible to use a range of Dates as an iteration context	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-143	Missing FEEL function to replace items in a list	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-125	Lists and filters section does not provide a dot accessor "." example with null	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-27	Improvement of Semantic Domains Specification	DMN 1.1	DMN 1.5	Closed; No Change	closed
DMN15-42	data equivalence with date and time	DMN 1.2	DMN 1.5	Duplicate or Merged	closed
DMN15-76	The "schemaLocation" relative URLs are broken	DMN 1.3	DMN 1.5	Closed; No Change	closed
DMN15-120	Wording in section above does not match the rule 35 in grammar	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-98	DMN 1.4 updated XMI references external file DMN14.mdxml	DMN 1.4	DMN 1.5	Closed; No Change	closed
DMN15-36	No way to represent a black-box or incompletely defined Decision Service	DMN 1.2	DMN 1.5	Deferred	closed
DMN15-142	Misprint in	DMN 1.4b1	DMN 1.5	Duplicate or Merged	closed
DMN15-149	Typo - "duraion"	DMN 1.4	DMN 1.5	Duplicate or Merged	closed
DMN15-45	Clean up example xml files	DMN 1.2b1	DMN 1.5	Closed; No Change	closed
DMN15-108	Positive unary tests lack equality operators	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-88	UNused Requirements are considered invalid	DMN 1.4	DMN 1.5	Resolved	closed
DMN15-78	Underspecified when ranges may include a qualified name for the endpoint, which resolves to null	DMN 1.3	DMN 1.5	Resolved	closed
DMN15-99	No built-in function to support Range conversion	DMN 1.4	DMN 1.5	Resolved	closed
DMN15-86	Table 62 limited to "negative numbers"	DMN 1.4	DMN 1.5	Resolved	closed
DMN15-94	Typo in "10.3.1.2 Grammar rules" 3rd bulletpoint in the bottom	DMN 1.4	DMN 1.5	Resolved	closed
DMN15-107	No support for numbers in scientific notation	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-137	Allowed Values for collection item definitions	DMN 1.4b1	DMN 1.5	Duplicate or Merged	closed
DMN15-131	Another False, or at least ignored statement by most vendors	DMN 1.4b1	DMN 1.5	Duplicate or Merged	closed
DMN15-130	False, or at least ignored statement by most if not all vendors	DMN 1.4b1	DMN 1.5	Duplicate or Merged	closed
DMN15-13	Clarification needed if null is passed as value for optional parameter of built in function	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-12	Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-4	Business Knowledge Model can have Information Requirements	DMN 1.0	DMN 1.5	Deferred	closed
DMN15-2	No notation for ItemDefinition	DMN 1.0	DMN 1.5	Deferred	closed
DMN15-5	XSD: global context	DMN 1.0	DMN 1.5	Deferred	closed
DMN15-7	Include Test Cases in Decision Model	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-3	italics and bold used for both typographic literal notation and FEEL semantic exposition	DMN 1.0	DMN 1.5	Deferred	closed
DMN15-96	Gaps: Range as input, mapping to JSON, evaluation of non-FEEL expression languages	DMN 1.4	DMN 1.5	Duplicate or Merged	closed
DMN15-83	Typo in 6.3.7 Decision metamodel	DMN 1.4	DMN 1.5	Resolved	closed
DMN15-18	Enumerations can only be defined as strings	DMN 1.1	DMN 1.5	Closed; Out Of Scope	closed
DMN15-109	There are questions regarding precedence of operator between negation and exponation	DMN 1.4	DMN 1.5	Resolved	closed
DMN15-81	Typo in 8.3.1 Decision Table metamodel "DecsionTable"	DMN 1.4	DMN 1.5	Resolved	closed
DMN15-1	Business Context links go both ways	DMN 1.0	DMN 1.5	Deferred	closed
DMN15-106	Incorrect reference to FEEL rule	DMN 1.4b1	DMN 1.5	Duplicate or Merged	closed
DMN15-79	Typo in the DMN 1.4 XSD schema (complexType tFilter)	DMN 1.4	DMN 1.5	Closed; No Change	closed
DMN15-31	Collect decision tables	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-23	Can an expression in user defined function body reference a name outside of it's scope?	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-30	Metamodel constraints & validation	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-15	Can the same Definitions/namespace be used by more than one model?	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-26	Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-24	Should name declarations in same context fail or overwrite?	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-25	Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-28	Semantic domain mapping for simple expressions	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-11	No adjustment for last day in month if duration is added/subtracted to date and time value	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-8	Enhancement suggestion: make unary tests first class citizens of the FEEL language	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-16	Add two new concrete numeric types, make number abstract	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-17	Lexical representation of time string has ambiguous definitons	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-10	Should encapsulated decisions of a decision service include output decisions?	DMN 1.0	DMN 1.5	Deferred	closed
DMN15-22	How to get FEEL type if evaluation is not an option?	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-20	More Generic Ways to Define Decision Table Properties	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-19	FEEL grammar readability	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-32	In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-21	Scope of decision table input/output entries is not well defined in the specification	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-14	Improve description of built-in function string()	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-9	Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-39	inconsistent date comparisons make unavoidavle paradoxes	DMN 1.2	DMN 1.5	Deferred	closed
DMN15-29	Requested additional built-in functions	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-52	Inconsistency DMNv1.2 dropping [a]=a and get entries example	DMN 1.2b1	DMN 1.5	Deferred	closed
DMN15-57	Add an itemKind property to ItemDefinition	DMN 1.3b1	DMN 1.5	Deferred	closed
DMN15-55	Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-33	need set operations and equality in FEEL	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-34	notion of arbitrary order conflicts with lack of an unordered collection data type	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-38	DMN Models need a default timezone	DMN 1.2	DMN 1.5	Deferred	closed
DMN15-40	Situational Data Model and Notation (SDMN)	DMN 1.2b1	DMN 1.5	Deferred	closed
DMN15-35	Unspecified conclusion is not supported	DMN 1.1	DMN 1.5	Deferred	closed
DMN15-37	Fix interchange of links to objects in BPMN/BMM	DMN 1.2	DMN 1.5	Deferred	closed
DMN15-48	Lack of visual notation for processing of / iteration over lists in FEEL	DMN 1.2	DMN 1.5	Deferred	closed
DMN15-49	Support for recursive calls by Business Knowledge Models	DMN 1.2	DMN 1.5	Deferred	closed
DMN15-51	properly define type(e)	DMN 1.2	DMN 1.5	Deferred	closed
DMN15-41	Knowledge Package Model and Notation (KPMN)	DMN 1.2b1	DMN 1.5	Deferred	closed
DMN15-50	Clarification on DMN case sensitivity of timezones	DMN 1.2	DMN 1.5	Deferred	closed
DMN15-53	"instance of" not possible with some built-in functions	DMN 1.2b1	DMN 1.5	Deferred	closed
DMN15-54	Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-43	Temporal precision inconsistencies	DMN 1.2b1	DMN 1.5	Deferred	closed
DMN15-46	Provide better spec and examples for Equality, Identity, and Equivalence	DMN 1.2b1	DMN 1.5	Deferred	closed
DMN15-47	Friendlier handling of null values	DMN 1.2b1	DMN 1.5	Deferred	closed
DMN15-58	Missing semantics for multiple imports	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-61	DRG requirements only state am unused knowledge requirement is illegal	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-59	Spec does not mandate that all user-defined function parameters are utilised	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-62	No way to show relative multiplicity of decisions and their information requirements	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-60	Spec does not mandate that all formal parameters are utilised.	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-63	No way to tell that a Decision iterates over a collection	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-64	P0D == P0Y in SFEEL, but it is unclear if P0D == P0Y in FEEL	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-66	the operation of is() function is not well specified	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-69	Allow for partial temporal values	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-68	FunctionItem `parameters` array attribute is plural, not singular in name	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-72	Allow input data to be of type Interval	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-67	Ambiguous named params for before() and after() range functions	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-70	Change to the "at literal" in FEEL	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-71	Adding a new interval built-in function	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-75	Links with other standards	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-101	No Mapping of FEEL to JSON	DMN 1.4	DMN 1.5	Deferred	closed
DMN15-73	Clarification on syntax of DMNReference	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-77	Missing InformationItem Association?	DMN 1.3	DMN 1.5	Deferred	closed
DMN15-91	Functions cannot invoke external services	DMN 1.4	DMN 1.5	Deferred	closed
DMN15-139	Import into default namespace is undefined	DMN 1.4b1	DMN 1.5	Resolved	closed
DMN15-151	Friendly enough cohersion to string	DMN 1.4b1	DMN 1.5	Deferred	closed
DMN15-123	Importing libraries of functions is not business friendly	DMN 1.4b1	DMN 1.5	Deferred	closed
DMN15-124	Interchanging models that use external libraries of functions is complicated	DMN 1.4b1	DMN 1.5	Deferred	closed
DMN14-197	Underspecified when ranges may include a qualified name for the endpoint, which resolves to null	DMN 1.3	DMN 1.4	Deferred	closed
DMN14-182	New built-in function to merge/concatenate two or more contexts	DMN 1.3	DMN 1.4	Duplicate or Merged	closed
DMN14-183	New built-in function to create a new context	DMN 1.3	DMN 1.4	Duplicate or Merged	closed
DMN14-181	No function to add an entry to a context	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-166	New XML Namespace needed	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-194	Missing boxed expression for iterator expression	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-192	Missing boxed expression for filter expression	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-190	Missing boxed expression for conditional statement	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-196	Typo Table55 row 7	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-178	Are the names of boxed context entries unique in a given context ?	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-55	Incorrect example in Table 40: Examples of equivalence and conformance relations	DMN 1.2	DMN 1.4	Resolved	closed
DMN14-164	More examples of replace() function needed	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-117	typo - incorrect indexing	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-185	Incorrect figure reference	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-87	Wrong and Incomplete FEEL grammar rule 52	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-156	the word 'decision' is misspelt.	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-126	Missing functions for rounding	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-167	Sub-decisions are referenced but not defined	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-150	Collections are not shown on diagrams	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-143	instance of grammar does not support range , or context, or function	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-142	DMNDiagram 'Size' attribute has capital 'S' in schema definition	DMN 1.3	DMN 1.4	Closed; No Change	closed
DMN14-141	The result of product([]) is not defined	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-74	DMNv1.3 fix DMN example files issues	DMN 1.2	DMN 1.4	Resolved	closed
DMN14-42	There is no way to identify current date and time, e.g. now() & today()	DMN 1.1	DMN 1.4	Resolved	closed
DMN14-11	Expressions cannot be used as "end points"	DMN 1.1	DMN 1.4	Resolved	closed
DMN14-8	Lack of visual notation for processing of / iteration over lists in DRD	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-6	LiteralExpression and textual expression seem to mean the same thing, need to use the same term	DMN 1.0	DMN 1.4	Closed; No Change	closed
DMN14-61	Support for function types in metamodel and XSD	DMN 1.2b1	DMN 1.4	Closed; No Change	closed
DMN14-56	Spec does not clarify meaning of hex value	DMN 1.2b1	DMN 1.4	Closed; No Change	closed
DMN14-125	Definitions of overlaps functions	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-45	Convenience documents	DMN 1.2b1	DMN 1.4	Closed; No Change	closed
DMN14-137	Typo in horizontal alignment label	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-86	Wrong example for is() built-in function	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-85	Wrong example for distinct values() built-in function	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-93	Wrong XSD for tDecisionService	DMN 1.3	DMN 1.4	Closed; No Change	closed
DMN14-88	First (and priority) hit policy are unpredictable with partial input	DMN 1.3	DMN 1.4	Closed; No Change	closed
DMN14-136	Extend endpoints to support expressions	DMN 1.3	DMN 1.4	Duplicate or Merged	closed
DMN14-52	Clarify method signature syntax for Java Function Definition	DMN 1.2	DMN 1.4	Closed; No Change	closed
DMN14-116	DMN string join built-in function proposal	DMN 1.3	DMN 1.4	Resolved	closed
DMN14-36	FEEL ambiguity	DMN 1.1	DMN 1.4	Resolved	closed
DMN14-20	Wrong character in expression for PMT function definition	DMN 1.1	DMN 1.4	Closed; No Change	closed
DMN14-1	BigDecimal is not the only mapping of number to Java	DMN 1.0	DMN 1.4	Closed; No Change	closed
DMN14-46	DMN 1.3 Metamodel	DMN 1.2b1	DMN 1.4	Closed; No Change	closed
DMN14-73	Wrong example for 10.6.1 Context Figure 10.18: Example context	DMN 1.2	DMN 1.4	Resolved	closed
DMN14-72	Wrong example for substring() builtin funciton	DMN 1.2	DMN 1.4	Resolved	closed
DMN14-75	Wrong example snippet in 10.3.2.9.4.1 Examples	DMN 1.2	DMN 1.4	Resolved	closed
DMN14-23	Enumerations can only be defined as strings	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-22	Lexical representation of time string has ambiguous definitons	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-21	Add two new concrete numeric types, make number abstract	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-19	Can the same Definitions/namespace be used by more than one model?	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-18	Improve description of built-in function string()	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-17	Clarification needed if null is passed as value for optional parameter of built in function	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-16	Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-14	Should encapsulated decisions of a decision service include output decisions?	DMN 1.0	DMN 1.4	Deferred	closed
DMN14-13	Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-12	Enhancement suggestion: make unary tests first class citizens of the FEEL language	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-10	Include Test Cases in Decision Model	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-9	Change depiction of Input to be harmonized with BPMN and CMMN	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-7	XSD: global context	DMN 1.0	DMN 1.4	Deferred	closed
DMN14-5	Business Knowledge Model can have Information Requirements	DMN 1.0	DMN 1.4	Deferred	closed
DMN14-4	italics and bold used for both typographic literal notation and FEEL semantic exposition	DMN 1.0	DMN 1.4	Deferred	closed
DMN14-3	No notation for ItemDefinition	DMN 1.0	DMN 1.4	Deferred	closed
DMN14-2	Business Context links go both ways	DMN 1.0	DMN 1.4	Deferred	closed
DMN14-48	inconsistent date comparisons make unavoidavle paradoxes	DMN 1.2	DMN 1.4	Deferred	closed
DMN14-44	Fix interchange of links to objects in BPMN/BMM	DMN 1.2	DMN 1.4	Deferred	closed
DMN14-43	Now way to represent a black-box or incompletely defined Decision Service	DMN 1.2	DMN 1.4	Deferred	closed
DMN14-41	Unspecified conclusion is not supported	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-40	notion of arbitrary order conflicts with lack of an unordered collection data type	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-39	need set operations and equality in FEEL	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-38	In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-37	Collect decision tables	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-35	Metamodel constraints & validation	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-34	Requested additional built-in functions	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-33	Semantic domain mapping for simple expressions	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-32	Improvement of Semantic Domains Specification	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-31	Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-30	Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-29	Should name declarations in same context fail or overwrite?	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-28	Can an expression in user defined function body reference a name outside of it's scope?	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-27	How to get FEEL type if evaluation is not an option?	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-26	Scope of decision table input/output entries is not well defined in the specification	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-25	More Generic Ways to Define Decision Table Properties	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-24	FEEL grammar readbility	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-15	No adjustment for last day in month if duration is added/subtracted to date and time value	DMN 1.1	DMN 1.4	Deferred	closed
DMN14-53	Temporal precision inconsistencies	DMN 1.2b1	DMN 1.4	Deferred	closed
DMN14-54	Clarification regarding equivalence of date vs date and time	DMN 1.2	DMN 1.4	Deferred	closed
DMN14-62	Support for recursive calls by Business Knowledge Models	DMN 1.2	DMN 1.4	Deferred	closed
DMN14-63	Clarification on DMN case sensitivity of timezones	DMN 1.2	DMN 1.4	Deferred	closed
DMN14-60	Lack of visual notation for processing of / iteration over lists in FEEL	DMN 1.2	DMN 1.4	Deferred	closed
DMN14-66	"instance of" not possible with some built-in functions	DMN 1.2b1	DMN 1.4	Deferred	closed
DMN14-57	Clean up example xml files	DMN 1.2b1	DMN 1.4	Deferred	closed
DMN14-58	Provide better spec and examples for Equality, Identity, and Equivalence	DMN 1.2b1	DMN 1.4	Deferred	closed
DMN14-51	data equivalence with date and time	DMN 1.2	DMN 1.4	Deferred	closed
DMN14-59	Friendlier handling of null values	DMN 1.2b1	DMN 1.4	Deferred	closed
DMN14-69	Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.	DMN 1.3	DMN 1.4	Deferred	closed
DMN14-70	Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression	DMN 1.3	DMN 1.4	Deferred	closed
DMN14-71	Typos in the XMI files	DMN 1.2	DMN 1.4	Deferred	closed
DMN14-47	DMN Models need a default timezone	DMN 1.2	DMN 1.4	Deferred	closed
DMN14-49	Situational Data Model and Notation (SDMN)	DMN 1.2b1	DMN 1.4	Deferred	closed
DMN14-50	Knowledge Package Model and Notation (KPMN)	DMN 1.2b1	DMN 1.4	Deferred	closed
DMN14-65	Inconsistency DMNv1.2 dropping [a]=a and get entries example	DMN 1.2b1	DMN 1.4	Deferred	closed
DMN14-64	properly define type(e)	DMN 1.2	DMN 1.4	Deferred	closed
DMN14-153	No way to show relative multiplicity of decisions and their information requirements	DMN 1.3	DMN 1.4	Deferred	closed
DMN12-27	Lack of visual notation for processing of / iteration over lists	DMN 1.1	DMN 1.2	Deferred	closed
DMN13-127	Incorrect claim about the Unicode character range and EBNF character expressions	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-143	Should add a new unicode escape syntax	DMN 1.2b1	DMN 1.3	Duplicate or Merged	closed
DMN13-109	Ambiguty for the source/target of DMNEdge when there is multiple depictions of its source and target	DMN 1.2	DMN 1.3	Resolved	closed
DMN13-244	Incorrect figure 6.10	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-181	PMML invocation output value in the case of single prediction	DMN 1.2	DMN 1.3	Resolved	closed
DMN13-175	A signature for the time() built in function is missing from table 66	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-2	Decision Logic Examples	DMN 1.0	DMN 1.3	Resolved	closed
DMN13-125	Disambiguation for Modulo / Remainder function	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-139	Add built-in functions to support Allen's interval algebra	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-140	Incorrect grammar rule references and missing UnaryTests section in MM	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-141	Allegedly bug in Table Table 40 Examples of equivalence and conformance relations	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-132	type conversions are too spread out in Ch 10	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-111	Remove the limitation that the second operand of exponentiation be an integer	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-156	Decision Requirement Metadata Examples	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-163	Decision Service output value in the case of single output Decision	DMN 1.2	DMN 1.3	Resolved	closed
DMN13-188	New FEEL URI needed	DMN 1.2	DMN 1.3	Resolved	closed
DMN13-178	Functions resolution	DMN 1.2	DMN 1.3	Resolved	closed
DMN13-242	Update the copyright section	DMN 1.2	DMN 1.3	Resolved	closed
DMN13-195	New acknowledgments needed	DMN 1.2	DMN 1.3	Resolved	closed
DMN13-191	New XML Namespace needed	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-21	DMN v1.2 specification	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-19	ranges do not map to the semantic domain	DMN 1.1	DMN 1.3	Duplicate or Merged	closed
DMN13-7	No item definition for function definition	DMN 1.0	DMN 1.3	Resolved	closed
DMN13-6	Need group artifact in DRD, metamodel, and XSD	DMN 1.0	DMN 1.3	Resolved	closed
DMN13-29	mix up of list and non-list in filter expression example	DMN 1.1	DMN 1.3	Resolved	closed
DMN13-59	FEEL does not support named ranges	DMN 1.1	DMN 1.3	Duplicate or Merged	closed
DMN13-35	Equality for date, date and time, time and inequality for date doesn't use the value function, which make the <= and >= operations useless and = operation behaves differently as < and >	DMN 1.1	DMN 1.3	Resolved	closed
DMN13-34	Imprecise result for example calculation of function PMT and may be typo or rounding issue	DMN 1.1	DMN 1.3	Resolved	closed
DMN13-56	string built-in underspecified	DMN 1.1	DMN 1.3	Duplicate or Merged	closed
DMN13-75	Case-aware and case-insensitive	DMN 1.1	DMN 1.3	Closed; Out Of Scope	closed
DMN13-124	Disambiguation for Modulo / Remainder function	DMN 1.2b1	DMN 1.3	Duplicate or Merged	closed
DMN13-144	instance of clarification	DMN 1.2	DMN 1.3	Resolved	closed
DMN13-131	Make explicit reference to sample standard deviation	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-133	Wrong example in chapter "10.3.1.5"	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-106	Remove reference to SQL and PMML three value logic to eliminate misinterpretation	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-126	Built-in functions only described in chapter "10.3.2.6 Context", and not described in the "10.3.4 Built-in functions"	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-122	"get value" and "get entries" function not in built-in functions list	DMN 1.2b1	DMN 1.3	Duplicate or Merged	closed
DMN13-121	example shows literal inline function definition whereas grammar says function definitions only in boxed expressions.	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-120	Minor typos in the FEEL grammar	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-98	Example: Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses values inverted	DMN 1.2b1	DMN 1.3	Resolved	closed
DMN13-40	Need additional FEEL Types	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-41	Ambiguity between qualified name and path operation	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-37	Specification of type for instance of operator misses information	DMN 1.1	DMN 1.3	Resolved	closed
DMN13-45	Missing semantic specification for FEEL for and quantified expression	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-53	Can listed input data option be used in encapsulated decisions of decision service?	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-13	Expressions in Input Entries	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-66	Missing "date" FEEL type in some enumerations	DMN 1.1	DMN 1.3	Resolved	closed
DMN13-67	Broken HTTP links	DMN 1.1	DMN 1.3	Resolved	closed
DMN13-72	Description of Table 44 is out of place	DMN 1.1	DMN 1.3	Resolved	closed
DMN13-23	Remove rule#32 additional name symbols from BNF	DMN 1.1	DMN 1.3	Closed; Out Of Scope	closed
DMN13-62	Missing FEEL namespace in the header of the xml sample	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-61	Typo in the sample xml	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-64	Broken HTTP links	DMN 1.1	DMN 1.3	Duplicate or Merged	closed
DMN13-57	Additional name symbols	DMN 1.1	DMN 1.3	Closed; Out Of Scope	closed
DMN13-60	SFEEL grammar readbility	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-63	Naming inconsistency	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-77	Figure 70 does not correspond to example file	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-42	Is really only name allowed in a FEEL path?	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-49	FEEL grammar is ambiguous for grammar rule 2.i simple positive unary test when no operator is specified for an endpoint	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-51	Page 71 states that a DT can have 0 inputs. I believe this to be incorrect	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-54	Bug in specification of the ‘Any’ Hit Policy	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-1	BigDecimal is not the only mapping of number to Java	DMN 1.0	DMN 1.3	Deferred	closed
DMN13-14	FEEL operators in names	DMN 1.1	DMN 1.3	Closed; Out Of Scope	closed
DMN13-11	Decisions can be used for many things, do we need a taxonomy?	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-5	italics and bold used for both typographic literal notation and FEEL semantic exposition	DMN 1.0	DMN 1.3	Deferred	closed
DMN13-4	No notation for ItemDefinition	DMN 1.0	DMN 1.3	Deferred	closed
DMN13-3	Business Context links go both ways	DMN 1.0	DMN 1.3	Deferred	closed
DMN13-58	Spaces and additional characters in names / identifiers	DMN 1.1	DMN 1.3	Closed; Out Of Scope	closed
DMN13-70	null is not defined in the S-FEEL grammar	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-74	Semantics of variable in decision table input entry	DMN 1.1	DMN 1.3	Closed; No Change	closed
DMN13-26	Clarification needed if null is passed as value for optional parameter of built in function	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-25	Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-24	No adjustment for last day in month if duration is added/subtracted to date and time value	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-27	Improve description of built-in function string()	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-36	FEEL grammar readbility	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-32	Lexical representation of time string has ambiguous definitons	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-38	More Generic Ways to Define Decision Table Properties	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-39	Scope of decision table input/output entries is not well defined in the specification	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-43	How to get FEEL type if evaluation is not an option?	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-18	Enhancement suggestion: make unary tests first class citizens of the FEEL language	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-17	Enhancement suggestion: allow for expressions to be used as "end points"	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-16	Include Test Cases in Decision Model	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-15	Change depiction of Input to be harmonized with BPMN and CMMN	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-12	Lack of visual notation for processing of / iteration over lists in DRD	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-10	XSD: global context	DMN 1.0	DMN 1.3	Deferred	closed
DMN13-9	LiteralExpression and textual expression seem to mean the same thing, need to use the same term	DMN 1.0	DMN 1.3	Deferred	closed
DMN13-8	Business Knowledge Model can have Information Requirements	DMN 1.0	DMN 1.3	Deferred	closed
DMN13-28	Can the same Definitions/namespace be used by more than one model?	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-31	Add two new concrete numeric types, make number abstract	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-33	Formally define enumerations and use throughout	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-20	Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-22	Should encapsulated decisions of a decision service include output decisions?	DMN 1.0	DMN 1.3	Deferred	closed
DMN13-30	Wrong character in expression for PMT function definition	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-55	Requested additional built-in functions	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-69	Collect decision tables	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-68	FEEL ambiguity	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-71	In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-73	need set operations and equality in FEEL	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-76	notion of arbitrary order conflicts with lack of an unordered collection data type	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-78	Unspecified conclusion	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-79	We need a way to identify current date and time. I propose Now()	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-91	Fix interchange of links to objects in BPMN/BMM	DMN 1.2	DMN 1.3	Deferred	closed
DMN13-90	Allow representation of black-box Decision Service	DMN 1.2	DMN 1.3	Deferred	closed
DMN13-44	Can an expression in user defined function body reference a name outside of it's scope?	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-46	Should name declarations in same context fail or overwrite?	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-47	Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-48	Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-50	Improvement of Semantic Domains Specification	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-52	Semantic domain mapping for simple expressions	DMN 1.1	DMN 1.3	Deferred	closed
DMN13-65	Metamodel constraints & validation	DMN 1.1	DMN 1.3	Deferred	closed
DMN12-29	Generalized Unary Tests	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-188	semantics of import is unspecified	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-131	Execution Semantics of Decision Services does not explain imported elements	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-216	Confusing semantics of ItemDefinitons	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-250	Formatting problems in Ballot 15 convenience doc	DMN 1.1	DMN 1.2	Closed; No Change	closed
DMN12-183	Missing type names in FEEL functions (user and external)	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-119	Support for function calls in unary tests	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-280	Missing RuleAnnotation attributes and model associations table	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-223	Limitations of FEEL for..in..return	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-18	add richer variety of DT examples in Ch 11	DMN 1.0	DMN 1.2	Duplicate or Merged	closed
DMN12-79	Typo in sublist() function example	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-41	FEEL + operator semantics operand-dependent	DMN 1.1	DMN 1.2	Closed; Out Of Scope	closed
DMN12-40	Spaces in FEEL builtin functions	DMN 1.1	DMN 1.2	Closed; Out Of Scope	closed
DMN12-70	Chapter 11 example serialization has many errors	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-155	Supporting text about Expression lists non-existing name attribute	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-143	Inconsistencies between metamodel and xsd schema	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-210	Expected behavior for list/sort built-in functions in combination with singleton lists	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-9	Typo error on Business Knowledge Model	DMN 1.0	DMN 1.2	Closed; No Change	closed
DMN12-248	Missing attribute isExpanded for DecisionService DI	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-229	Chapter 11 example in specification does not match file ch11example.xml and ch11example.xml contains errors	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-186	Wrong length range check for built-in function sublist() and substring()	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-46	Wrong numbering in S-FEEL syntax	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-45	Remove tight coupling with BPMN and BMM	DMN 1.1	DMN 1.2	Closed; Out Of Scope	closed
DMN12-20	Add Diagram Interchange to DMN	DMN 1.0	DMN 1.2	Resolved	closed
DMN12-55	Attributes in tables 29a and 29b do not correspond to metamodel Fig 51	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-23	typeRef from tables 10 and 15 not in figures 20 and 23	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-176	Decision Table hit policies C and C# should not return null when there are no matches	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-286	FEEL versions cannot be distinguished	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-190	DMN built-in functions are missing to ensure business friendliness	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-231	Import is lacking extension capability	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-94	Problem with QName usage in typeRef	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-74	Issues with Table 61	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-282	Missing annotation in Decision Table in DMN XSD	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-203	Wrong chapter reference for date and time / date and time subtraction	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-201	Type should be specified for date, time and duration properties	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-10	While BKMs enable re-use, the options for re-use are restricted to single pieces of decision logic	DMN 1.0	DMN 1.2	Resolved	closed
DMN12-38	Show diagram elements with hidden links	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-272	Allow DMN DI to provide an alternative notation for Input Data (DMN 1.2)	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-126	Chapter 11 example decision tables are incomplete	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-262	Please clarify what is the result of a filter with non-boolean expressions (null)	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-246	Lost formatting in 10.3.2.2 Equality, Identity, and Equivalence	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-217	add weekday property to date, date and time	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-184	Semantic mapping for XML syntactical artifacts	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-121	Releation between Definitions and DecisionService does not specified in XSD	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-14	Useful to denote which info requirements are unconditional	DMN 1.0	DMN 1.2	Closed; No Change	closed
DMN12-59	Need attribute for human and external decisions	DMN 1.1	DMN 1.2	Closed; No Change	closed
DMN12-58	Space in FEEL names is not well-specified	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-37	Dynamic invocation	DMN 1.1	DMN 1.2	Closed; No Change	closed
DMN12-39	Show implied Information Requirements	DMN 1.1	DMN 1.2	Closed; No Change	closed
DMN12-28	Graphical representation of Context - "sub-DRDs"	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-5	Consider date and time datatype in S-FEEL	DMN 1.0	DMN 1.2	Closed; No Change	closed
DMN12-1	cannot interchange input data style	DMN 1.0b1	DMN 1.2	Duplicate or Merged	closed
DMN12-47	FEEL 'instance of' operator is underspecified	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-48	SFEEL makes too few people happy	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-226	Missing support for escape sequences in string literals	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-129	Would like to use duplicate shapes/names in diagram to avoid multiple requirement line crossings	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-12	definition of expression in glossary omits CL3 expressions	DMN 1.0	DMN 1.2	Resolved	closed
DMN12-206	Invalid example for date and time property access	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-78	Impossible to invoke functions and() and or()	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-6	alternative indication of reusable logic in DRD	DMN 1.0	DMN 1.2	Duplicate or Merged	closed
DMN12-88	Label of Input in decision table	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-60	FEEL path expression has same precedence as filter and invocation	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-136	Decision Service Cannot be Shown in DRD	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-225	Transitive information requirements maybe inferred from the spec text	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-101	Requirements don't have an ID (needed for DI)	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-43	Drg element labels	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-21	Eliminate () from FEEL and S-FEEL	DMN 1.1	DMN 1.2	Closed; No Change	closed
DMN12-134	Add id to context entry	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-68	DMN 1.1 XML schema starts with ZERO WIDTH NO-BREAK SPACE (U+FEFF)	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-33	Scope of Variables in Context Boxed Expression	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-87	some/every ... satisfies not defined for empty list	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-211	Table 45 does not provide the semantic of addition and subtraction between elements of type Date and Duration	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-162	FEEL precedence for function definition	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-160	Metamodel is missing the "kind" attribute on function	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-124	Return All Annotations for All Hit Policies	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-195	Parameter names of built-in function date and time(date, time) are not allowed by name rules	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-189	Table 45 does not provide the semantic of addition and subtraction between two elements of type date	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-141	Unclear meaning of unique name constraint for ItemDefinitions and DRGElements	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-187	Parameter domain for built-in function years and months duration() is wrong	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-84	Decision table is not a good example of a builtin function	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-83	X and TBD are undefined in Table 35	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-86	grammar rule 56 missing comma	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-175	Different definition of hit policy collect aggregations in FEEL and DMN	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-137	clarify format of time literals / resolve inconsistency	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-148	decision table structure in 8.1 does not agree with MM	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-149	Output Order hit policy on pg 85 is incorrect	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-144	Add specification for DMN diagrams layout	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-138	Duplicate definition of BKM/@variable in Table 14	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-127	Missign Comma in Grammar Rule 48 (some/every...)	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-103	singular helping verb used with plural subject	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-36	Alternative DRD representation of BKM	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-32	Expressions in Input Entries	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-31	Collection Operators	DMN 1.1	DMN 1.2	Duplicate or Merged	closed
DMN12-24	Table 47 should specify duration/duration rather than number/duration	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-53	Missing comma to split “in” in quantified expression in FEEL syntax	DMN 1.1	DMN 1.2	Resolved	closed
DMN12-8	Wrong DecisionTable class diagram (metamodel)	DMN 1.0	DMN 1.2	Closed; No Change	closed
DMN12-22	DMN XSD 1.0 invalid path	DMN 1.0	DMN 1.2	Closed; No Change	closed
DMN12-16	Business Knowledge Model can have Information Requirements	DMN 1.0	DMN 1.2	Deferred	closed
DMN12-15	No item definition for function definition	DMN 1.0	DMN 1.2	Deferred	closed
DMN12-17	LiteralExpression and textual expression seem to mean the same thing, need to use the same term	DMN 1.0	DMN 1.2	Deferred	closed
DMN12-42	FEEL operators in names	DMN 1.1	DMN 1.2	Deferred	closed
DMN12-30	Expressions in Input Entries	DMN 1.1	DMN 1.2	Deferred	closed
DMN12-4	Business Context links go both ways	DMN 1.0	DMN 1.2	Deferred	closed
DMN12-3	Examples	DMN 1.0	DMN 1.2	Deferred	closed
DMN12-2	BigDecimal is not the only mapping of number to Java	DMN 1.0	DMN 1.2	Deferred	closed
DMN12-13	Need group artifact in DRD, metamodel, and XSD	DMN 1.0	DMN 1.2	Deferred	closed
DMN12-7	No notation for ItemDefinition	DMN 1.0	DMN 1.2	Deferred	closed
DMN12-11	italics and bold used for both typographic literal notation and FEEL semantic exposition	DMN 1.0	DMN 1.2	Deferred	closed
DMN12-260	ranges do not map to the semantic domain	DMN 1.1	DMN 1.2	Deferred	closed
DMN12-19	XSD: global context	DMN 1.0	DMN 1.2	Deferred	closed
DMN12-80	Enhancement suggestion: allow for expressions to be used as "end points"	DMN 1.1	DMN 1.2	Deferred	closed
DMN12-49	Include Test Cases in Decision Model	DMN 1.1	DMN 1.2	Deferred	closed
DMN12-44	Change depiction of Input to be harmonized with BPMN and CMMN	DMN 1.1	DMN 1.2	Deferred	closed
DMN12-25	Decisions can be used for many things, do we need a taxonomy?	DMN 1.1	DMN 1.2	Deferred	closed
DMN12-81	Enhancement suggestion: make unary tests first class citizens of the FEEL language	DMN 1.1	DMN 1.2	Deferred	closed
DMN12-77	DMN v1.2 specification	DMN 1.1	DMN 1.2	Deferred	closed
DMN11-81	extra level of indirection in decision table serialization is undesirable	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-45	Define decision service	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-176	DecisionService has no defined execution semantics, and decision model semantics in 10.4 is hard to understand	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-164	use refs in XSD only to substitution groups	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-155	DMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions)	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-146	DMN XSD, MM, Attribute/Association Tables, and spec text are not consistent	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-145	8.3.3. still speaks of condition and conclusion - supposedly removed by DMN11-81	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-122	DMN 1.1 Beta documents	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-12	Reference to BMM::Objective, BPMN::Process and BPMN::Task in XMI	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-91	dmn.xsd and dmn3.xsd should be merged and list of machine readable files corrected	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-89	Remove parameters from BKM MM - these belong at logic level	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-64	'In DMN 1.0' now not only tedious but wrong	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-47	Add association connector (artifact) with text label to represent conditional decision	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-99	Need for annotations and comments in DRD	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-92	Need to clarify which DMNElements must and must not have names	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-73	XSD: modify Import in tLiteralExpression	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-69	inputVariable and itemDefinition are redundant in Expression metamodel	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-58	Decision table default output	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-54	XSD itemDefinition/typeRef and typeDefinition are underspecified and incorrect	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-56	XSD; modify tItemDefinition by changing tItemComponent	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-50	Question on boxed invocation format	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-175	typos for DMN 1.1 RTF final report	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-166	Information item name on DTs not correct in some figures	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-139	Decision table MM and xsd need output label attribute	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-137	Need InformationItem for the FunctionDefinition of a BKM	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-127	would like to annotate Expression with typeRef	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-123	Decision, InputData, and other containers of InformationItem do not ref ItemDefinition directly	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-120	Knowledge Source metamodel diagram missing	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-25	Definitions/@namespace has no purpose	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-24	Constraints on Decision Table elements unclear	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-22	Expression defined as resulting in single value, but Decision may have multiple values	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-21	input expression example 'age<25' is not legal in SFEEL grammar	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-65	In metamodel, 'variable' should move from Information Requirement to Decision / Input Data	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-32	Decision table completeness undefined, Complete code conflicts with Collect	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-35	Dangling reference	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-34	extraneous asterisks (*)	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-60	Beta2 XSDs are broken	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-52	authorityRequirement in XSD	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-44	Remove attribute DecisionTable/@isConsistent	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-43	change "output expression" to "output name"	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-30	add Definitions optional attributes exporter, exporterVersion	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-13	DMN 1.1 RTF Issue: Negative numerics in decision tables	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-147	Nested ItemDefinition doesn't work	DMN 1.0	DMN 1.1	Duplicate or Merged	closed
DMN11-130	Clarify defaults for decision table outputs	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-7	DMN issue: date syntax in table 29	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-6	DMN Issue: typo in 3rd well-formed requirement of KnowledgeRequirement	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-4	DMN issue: typo in introduction of "Relating Logic to Decision Requirements"	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-9	XSD internally inconsistent, does not match the spec	DMN 1.0	DMN 1.1	Duplicate or Merged	closed
DMN11-3	XMI issues from Pete Rivett	DMN 1.0b1	DMN 1.1	Closed; No Change	closed
DMN11-23	S-FEEL "expression" undefined	DMN 1.0	DMN 1.1	Duplicate or Merged	closed
DMN11-27	XSD: DecisionTable/rule/condition should be IDREF not IDREFS	DMN 1.0	DMN 1.1	Duplicate or Merged	closed
DMN11-109	need to add UnaryTests to MM and XSD	DMN 1.0	DMN 1.1	Duplicate or Merged	closed
DMN11-102	XSD: change type of LiteralExpression/text, ItemDefinition/typeDefinition, and (new) textAnnotation/text to xsd:string	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-84	Decision Table metamodel and XSD should restrict input entries, input values, and output values to unary tests, and LiteralExpression for input expressions and output entries	DMN 1.0	DMN 1.1	Duplicate or Merged	closed
DMN11-88	8.2.10 calls crosstab tables "rules as columns"	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-80	XSD: make @id optional in tExpression	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-62	FEEL/S-FEEL names	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-33	list variables in decision tables	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-76	XSD: Relation and List	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-57	Xsd typeRef and itemDefinitionRef	DMN 1.0	DMN 1.1	Duplicate or Merged	closed
DMN11-55	XSD: add optional @name to inputVariable	DMN 1.0	DMN 1.1	Duplicate or Merged	closed
DMN11-53	FEEL concatenate function	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-48	dmn3.xsd	DMN 1.0	DMN 1.1	Duplicate or Merged	closed
DMN11-42	output data symbol & comment symbol missing in DRDs	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-39	Clarify Decision/outputDefinition, DecisionTable/clause/outputDefinition, DecisionTable/@name, clause/@name	DMN 1.0	DMN 1.1	Duplicate or Merged	closed
DMN11-29	Examples	DMN 1.0	DMN 1.1	Deferred	closed
DMN11-152	not all references in DMN are by ID	DMN 1.0	DMN 1.1	Resolved	closed
DMN11-8	DMN Issue: Boxed context example of XML data is wrong	DMN 1.0	DMN 1.1	Closed; No Change	closed
DMN11-1	Change Tracking Document	DMN 1.0b1	DMN 1.1	Closed; No Change	closed
DMN11-5	DMN issue: InformationItem is not a specialization of Expression	DMN 1.0	DMN 1.1	Duplicate or Merged	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-11	BigDecimal is not the only mapping of number to Java	DMN 1.0	DMN 1.1	Deferred	closed
DMN11-10	cannot interchange input data style	DMN 1.0b1	DMN 1.1	Deferred	closed
DMN11-66	No notation for ItemDefinition	DMN 1.0	DMN 1.1	Deferred	closed
DMN11-46	Consider date and time datatype in S-FEEL	DMN 1.0	DMN 1.1	Deferred	closed
DMN11-51	alternative indication of reusable logic in DRD	DMN 1.0	DMN 1.1	Deferred	closed
DMN11-31	Business Context links go both ways	DMN 1.0	DMN 1.1	Deferred	closed
DMN11-116	Need group artifact in DRD, metamodel, and XSD	DMN 1.0	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

ONNX not mentioned in one sentence

Key: DMN16-212
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
This is an oversight in ~~DMN16-100~~ which should have added ONNX to the list in the first paragraph of section "10.3.2.12 Mapping between FEEL and other domains":

Some kinds of values can be passed between FEEL and external Java methods, between FEEL and external PMML models
Reported: DMN 1.5b1 — Tue, 7 May 2024 17:29 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Add ONNX to the list

Add ONNX to the list
Updated: Mon, 16 Sep 2024 14:16 GMT

Single-parameter number() function is needed

Key: DMN16-208
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
A single-parameter version of the FEEL number() function is needed by users and for conversion in B-FEEL.
Reported: DMN 1.5b1 — Tue, 7 May 2024 16:52 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Add single-parameter version of number function

Add a single-parameter version of the number function and reuse the existing semantics of passing in null for the second and third parameters.
Updated: Mon, 16 Sep 2024 14:16 GMT

Binary operators should not return null

Key: DMN16-91
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Here, I am considering the following operators: =, <, >, not(), and, or, in, between

When considering FEEL for low-codes applications, we should expect these binary operators to always return true or false. Currently, when there is typing error, it returns null.

ex:
"a" = 1 => null
false and "a" => null
"a" in [0..100] => null
...
Reported: DMN 1.5 — Tue, 10 Oct 2023 15:57 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Alternative B-FEEL dialect with a single definition of null

In FEEL, the null value is used to both represent missing data or an execution error. We are proposing that null should be used only to represent missing data. All operations and built-in functions that return null in FEEL when an error occurs have their semantic modified to return a non-null value.
Updated: Mon, 16 Sep 2024 14:16 GMT
Attachments:
- B-FEEL - Proposal.docx 35 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Returning null is not enough for reporting/handling errors

Key: DMN16-117
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
Abusing null as an error indicator is not enough for reporting/handling errors.
In particular, it does not solve the need for users to:
- know exactly what the root cause of an error was
- control the reaction to errors
The specification already mentions error reporting but is neither a strict requirement nor consequently used:

When a built-in function encounters input that is outside its defined domain, the function SHOULD report or log diagnostic information if appropriate and SHALL return null.
Reported: DMN 1.5b1 — Tue, 30 Jan 2024 17:00 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Add strict mode

Improve de specification of error handling by adding two modes lenient and strict, with the lenient mode, the current one, the default one.

The idea is to configure the execution engine with the error handling mode when the models are executed.
Updated: Mon, 16 Sep 2024 14:16 GMT

Copyright section needs update

Key: DMN16-135
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
The Copyright section needs an update to reflect the DMN 1.6 RTF membership
Reported: DMN 1.5b1 — Wed, 24 Apr 2024 14:00 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Update copyright section

Update Copyright. Add Softeam that has been left out.
Updated: Mon, 16 Sep 2024 14:16 GMT

Rounding functions introduced in DMN 1.4 should have single parameter version

Key: DMN16-93
Status: closed
Source: Trisotech ( Mr. Simon Ringuette)
Summary:
Currently the 4 rounding methods: round up, round down, round half up, round half down only have signatures with 2 numeric arguments (n and scale).

However, pre-existing rounding functions: floor and ceiling have both a single numeric argument version and a 2 numeric argument function (n and scale).

The single numeric argument is backward compatible with DMN 1.3 (and before). It assumes a scale of 0.
Reported: DMN 1.5b1 — Thu, 19 Oct 2023 21:52 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Add single parameter versions of all rounding functions

Add single parameter versions of all rounding functions and adjust the examples to use them.
Updated: Mon, 16 Sep 2024 14:16 GMT

Outdated reference to machine readable files

Key: DMN16-132
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
Section "12.2 Machine Readable Files" refers to dtc/15-11-12 as a source for XMI and XSDs. This is wrong in several ways:
- The file is from DMN 1.1
- It is the ancillary .zip file of the RTF report, which contains a mix of normative files but also internal files of various RTF discussions
- Therefore, it is restricted to OMG members only
Reported: DMN 1.5b1 — Mon, 22 Apr 2024 21:48 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Update reference to machine-readable files

Use a link to the OMG website and update the list of provided files.
Updated: Mon, 16 Sep 2024 14:16 GMT

Allow ONNX as well as PMML functions

Key: DMN16-90
Status: closed
Source: Decision Management Solutions ( Mr. James Taylor)
Summary:
ONNX https://onnx.ai/ is an open format for ML models that supports some model types, especially neural networks, better than PMML. DMN should consider allow ONNX functions as it does PMML functions.
Reported: DMN 1.5 — Fri, 6 Oct 2023 21:56 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Support ONNX as an alternative to PMML

ONNX is an alternative to PMML for interchanging ML and AI models. This proposal extends the Kind of functions to include the ONNX Kind. It uses a similar approach to the existing Java and PMML Kinds so that a function can be defined as the execution of an ONNX model.
Updated: Mon, 16 Sep 2024 14:16 GMT
Attachments:
- Class_Diagram__DMN__ExpressionsL3.svg 230 kB (image/svg+xml)
- DMN16-100v1.docx 29 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Friendly enough cohersion to string

Key: DMN16-71
Status: closed
Source: camunda.com ( Mr. Nico Rehwaldt [X] (Inactive))
Summary:
Currently concatenating strings is not intuitive to users, as I always have to convert non string values to strings using the built-in `string` function.

So

```
"Today is " + now() = null
```

In order to yield the actual string you explicitly convert `now()` to its string representation:

```
"Today is " + string(now()) = "Today is 2021-12-12"
```

A more user friendly behavior would be to coherse the second argument to string if the first argument is already a string. This always yields a string representation of the thing. If it is not what I desire I can use custom stringification mechanisms explicitly.

We'd need to amend the Table 57 (page 128, https://www.omg.org/spec/DMN/1.4/Beta1/PDF) to support such cohersion.

—

Additional details on this case can be found in https://github.com/dmn-tck/tck/issues/538 (DMN TCK issue on this topic).
Reported: DMN 1.4b1 — Thu, 19 Jan 2023 12:50 GMT
Disposition: Duplicate or Merged — DMN 1.6b1
Disposition Summary:
Addressed in B-FEEL via ~~DMN16-109~~

Addressed in B-FEEL via ~~DMN16-109~~
Updated: Mon, 16 Sep 2024 14:16 GMT

number(from) function does not accept number as input

Key: DMN16-105
Status: closed
Source: Camunda Services GmbH ( Mr. Maciej Barelkowski)
Summary:
Currently, `string(string_variable) = string_variable`, but `number(number_variable) = null`.
This leads to surprising results like `number(5) = null` but `number("5") = 5`.
Let's add a function `number(from)` which would accept `number` as the parameter.
Reported: DMN 1.5b1 — Tue, 7 Nov 2023 14:46 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Add number(from: number)

Add a version of the number(from) function that accepts a number as an input and returns it, which is in line with the behavior of other conversion functions, e.g. string(from), and helps in situations where expressions produce, e.g. a string or a number.
Updated: Mon, 16 Sep 2024 14:16 GMT

External Function Definitions should be optional

Key: DMN16-134
Status: closed
Source: Decision Management Solutions ( Mr. James Taylor)
Summary:
The specification lists for 1.6 will list three external function types - Java, PMML and ONNX. It is not reasonable to insist on support for these to be conformant.
2.1 Conformance Levels should be amended such that Conformance Level 3 excludes the need to support any function Kind other than FEEL - support for Java, PMML and ONNX is not required..
Reported: DMN 1.5b1 — Tue, 23 Apr 2024 17:26 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Make Java, PMML & ONNX optional

Make Java, PMML & ONNX optional
Updated: Mon, 16 Sep 2024 14:16 GMT

Grammar rule does not match with the one proposal - typo

Key: DMN16-85
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Grammar rule does not match to the one in proposal https://issues.omg.org/browse/DMN15-107

35. numeric literal = [ "~~" ] , ( digits , [ ".", digits ] | "." , digits, [ ( "e" | "E" ) , [ "+" | "~~" ] , digits ] ) ;

should be

35. numeric literal = [ "~~" ] , ( digits , [ ".", digits ] | "." , digits) , [ ( "e" | "E" ) , [ "+" | "~~" ] , digits ] ;
Reported: DMN 1.5b1 — Tue, 15 Aug 2023 13:43 GMT
Disposition: Closed; No Change — DMN 1.6b1
Disposition Summary:
Typo already fixed in formal edit of DMN 1.5

Typo originated during edit of the convenience document. Michelle Seaver applied the revised text correctly in smsc/24-04-02 leaving no issue to be addressed in DMN 1.6.
Updated: Mon, 16 Sep 2024 14:16 GMT

Examples use typeRef for BKMs incorrectly

Key: DMN16-128
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
There are a few other DMN example files with the same error as in ~~DMN15-74~~. Also the typeRef, has to move into the body of the BKM not the encapsulatedLogic as this one is the same with BKM.typeRef.
Reported: DMN 1.5b1 — Mon, 22 Apr 2024 16:15 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Correct the typeRef for BKMs in examples

Move typeRef from variable and/or encapsulatedLogic into the body of the BKM (is the type returned by the BKM)
Updated: Mon, 16 Sep 2024 14:16 GMT

New Namespace URIs needed

Key: DMN16-205
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
For tools to clearly identify the version of a DMN file or FEEL expression, the XML namespaces of DMN, and FEEL should be updated.

Namespace URIs must be backwards compatible with the scheme applied in previous versions for tools that support multiple versions in parallel. See:
DMN DI, DI, and DC namespaces can stay the same as DMN 1.6 DI is unchanged since 1.5 and still based on the same DD 1.1 specification and "OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces in OMG Specifications", states explicitly:

Note: if a spec has many machine readable files, and only some of them change at a given specification version, then only the changed files should get new URIs. That could mean a mixture of URI date segment values for a given specification version.
Reported: DMN 1.5b1 — Fri, 26 Apr 2024 21:27 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Update Namespace URIs for DMN 1.6

Update namespace URIs with the following values:

XSD: https://www.omg.org/spec/DMN/20240513/MODEL/
FEEL: https://www.omg.org/spec/DMN/20240513/FEEL/
XMI: https://www.omg.org/spec/DMN/20240513/DMN16.xmi

These URIs conform to the OMG Policy for Specification URIs and Namespaces (smsc/2018-08-01) and are backwards-compatible with the namespace scheme applied in DMN 1.2, 1.3, 1.4, and 1.5 which is important for vendors supporting multiple versions in parallel.
Updated: Mon, 16 Sep 2024 14:16 GMT

Acknowledgements for DMN 1.6 contributors needed

Key: DMN16-137
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Section 4.1 Acknowledgement needs to be updated with DMN 1.6 RTF contributors.
Reported: DMN 1.5b1 — Wed, 24 Apr 2024 14:32 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Add acknowledgements for DMN 1.6 contributors

Add paragraphs to acknowledge the DMN 1.6 contributors to section "4.1 Acknowledgements" based on taskforce membership
Updated: Mon, 16 Sep 2024 14:16 GMT

Clarification on syntax of DMNReference needed

Key: DMN16-64
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
It is not very clear (see discussion on TCK https://github.com/dmn-tck/tck/pull/366) if DRGElement can be referenced in the same XML file using an absolute path.

For example,

<requiredDecision
href=”http://www.example.org/Definitions01.xml#prebureauriskDec01”/>

is a valid reference even if prebureauriskDec01 is defined in the same file with element the referenced it.
Reported: DMN 1.3 — Fri, 1 Jan 2021 11:14 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Add clarification on DMNReference

Add clarification on DMNReference
Updated: Mon, 16 Sep 2024 14:16 GMT

No Mapping of FEEL to JSON

Key: DMN16-68
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
Current DMN Specification v1.4 does not define a mapping of FEEL to JSON, while it already provides mapping for Java, XML, PMML in chapter "10.3.2.12 Mapping between FEEL and other domains"

This capability can be useful in other use-cases beyond mapping itself. For example, but not limiting to: the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services.
Reported: DMN 1.4 — Wed, 13 Apr 2022 13:22 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
*Add mapping between FEEL and JSON *

Add relevant entries in chapter 10.3.2.12 in order to introduce mapping of FEEL to JSON, in addition to existing mappings.
Updated: Mon, 16 Sep 2024 14:16 GMT
Attachments:
- FEEL-JSON-Mapping.docx 6 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Screenshot 2022-04-13 at 15.17.46.png 267 kB (image/png)

Knowledge Package Model and Notation (KPMN)

Key: DMN16-37
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
A Knowledge Package is mechanism for packaging and distributing a set of BPM+ models (the knowledge)
A Knowledge Package references separate, but connected BPM+ models (BPMN Processes, CMMN Cases, and DMN Decision Services)
KPMN is focused solely on the BMI behavioral standards
A Knowledge Package also contains a Data Item library for the data that will be used by the BPM+ models
A Situational Data Model and Notation (SDMN) is also being proposed as a potential BMI standard to be added to the BPM+ stack (see separate presentation on this topic)
A Knowledge Package also contains metadata about the topic of the package to aid in understanding the content and to find appropriate Knowledge Packages
We are still exploring the relationships between KPMN and Provenance and Pedigree
KPMN includes a diagram to illustrate the scope of the Knowledge Package’s content (a Knowledge Model Diagram)
Reported: DMN 1.2b1 — Tue, 10 Sep 2019 17:59 GMT
Disposition: Closed; No Change — DMN 1.6b1
Disposition Summary:
Close because KPMN cancelled

The KPMN 1.0 FTF decided in January 2024 to not submit a report and therefore the specification got dropped by OMG.
Updated: Mon, 16 Sep 2024 14:16 GMT
Attachments:
- BMI Update - KPMN Sep 23 2019.pptx.zip 6.44 MB (application/zip)

Figure 8-20 shows wrong parent for UnaryTests

Key: DMN16-48
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression. The figure should be updated.
Reported: DMN 1.3 — Wed, 1 Jan 2020 00:21 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Update MM figure 8-20

Replace Figure 8-20 with a version that shows UnaryTests as a subclass of Expression

See also diff in GitHub: https://github.com/omg-dmn-taskforce/omg-dmn-spec/pull/32/files
Updated: Mon, 16 Sep 2024 14:16 GMT
Attachments:
- Class_Diagram__DMN__DecisionTable.svg 491 kB (image/svg+xml)

Change to the "at literal" in FEEL

Key: DMN16-61
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Currently the at literal = "@", string literal
Rather than a string following the @ symbol we would use the ISO 8601 format.
For date : @YYYY-MM-DD e.g. @2019-09-17
For time : @THH:MM:SS e.g. @T09:55:00
For date and time : @YYYY-MM-DDTHH:MM:SS e.g. @2019-09-17T09:55:00
For duration : @P[n]Y[n]M[n]DT[n]H[n]M[n]S where [n] is a number
e.g. @P18M, @P365D, PT48H
Reported: DMN 1.3 — Tue, 26 Jan 2021 22:11 GMT
Disposition: Closed; No Change — DMN 1.6b1
Disposition Summary:
The expected benefit of user friendliness does not warrant a change of grammar.

While it would be friendlier to drop the quotes in the At-literals, it would require a change of grammar. We do not expect any ambiguities to occur, but believe that such a change does not present sufficient benefit.
The issues does not seem to get much attention as it is open since DMN 1.3.
Updated: Mon, 16 Sep 2024 14:16 GMT

Collect decision tables

Key: DMN16-28
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
(1) The spec says "Collect: returns all hits in arbitrary order. An operator (‘+’, ‘<’, ‘>’, ‘#’) can be added to apply a simple function to the outputs. If no operator is present, the result is the list of all the output entries.". This is confusing - as I understand it if an operator is present a collect hit policy does not return all hits, only the result of the operation.

(2) The spec should state clearly what result is returned by Collect decision tables when no rules fire. In particular the result of a C+ decision table is not clear, because the result of sum([]) is undefined. I think a case could be made (based on a recursive definition) that the sum of an empty list is zero, which would be a much more useful result from the decision table than null. In general, section 10.3.4.4 restricts the semantics of all list functions to non-empty lists, although some functions have natural and useful results for the empty list e.g. count([])=0, sum([])=0, sublist([],x,y)=[], append([],items)=[items], concatenate([],items)=items, reverse([])=[], union([],items)=[], distinct values([])=[], flatten([])=[].

(3) Why is the result of C+ defined as "sum of all the distinct outputs" rather than just "sum of all the outputs"? I would say that if three rules fire proposing the value 5, the C+ result should be 15, not 5.
Reported: DMN 1.1 — Thu, 13 Oct 2016 08:25 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Clarify description of Collect hit policy

The issue raises three points. As discussed in the comments of ~~DMN15-31~~:
- Point 2 has been fixed in DMN 1.4 with wording on page 118 (PDF 134).
- Point 3 has been fixed in ~~DMN12-175~~
This proposal therefore only addresses Point 1 by providing revised wording for the description of the Collect hit policy.
Updated: Mon, 16 Sep 2024 14:16 GMT

Incorrect names for parameters

Key: DMN16-73
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The names of the number() function in note 1 at the end of Table 72
Reported: DMN 1.4b1 — Tue, 31 Jan 2023 18:50 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Correct footnote of table 72 (page 139)

In table 72 on page 138, the cell of the 9th line and 2nd column refers to a footnote ¹, which can be found on page 139.
The footnote intends to mention the parameters specified in the cell of the 9th line and 1st column of the table, but does not refer to them with correct names:
- grouping separator is incorrectly referred to as grouping
- decimal separator is incorrectly referred to as decimal
  In addition, the footnote reference ¹ in column 2 should rather be placed at the end of string, string, sting instead of after the first string.
Updated: Mon, 16 Sep 2024 14:16 GMT

Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration

Key: DMN16-11
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Chapter 10.3.2.3.4 time, 10.3.2.3.5 date, 10.3.2.3.6 date-time, 10.3.2.3.7 days and time duration and chapter 10.3.2.3.8 years and months duration defines each a value function. For date time arithmetic operations it would be useful to have this value available in the FEEL semantic domain. Therefore we suggest to add a new property value that is directly available for values of this type. Return type of the value if always a number.

Table 53 should be adjusted accordingly.
Reported: DMN 1.1 — Tue, 10 Oct 2017 09:57 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Introduce new property 'value'

Expose value functions for each semantic domain as a property
Updated: Mon, 16 Sep 2024 14:16 GMT

Lexical representation of time string has ambiguous definitions

Key: DMN16-16
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
A lexical time string is defined o page 131 by XML Schema Part 2 Datatypes (for local times and offset times) and by ISO 8601 with the extended form of a local time (for zoned times).

Unfortunately XML Schema Part 2 and ISO 8601 has different definitions. Therefore it is unclear which of them to use. Or are both of them valid?

Additionally the user should not have different lexical time string formats for a local time, an offset time or a zoned time.

The list of ambiguities:
- ISO 8601 allows a leading "T" character prefix. XML Schema Part 2 does not.
- ISO 8601 allows optional seconds. In XML Schema Part 2, the seconds are mandatory.
- ISO 8601 allows decimal fraction for seconds and minutes. XML Schema Part does not allow this.
- ISO 8601 allows 00:00:00 and 24:00:00 for midnight. XML Schema Part 2 only allows 00:00:00.
- ISO 8601 allows time offset of hours only. Minutes are optional. XML Schema Part 2 always requires minutes.
Therefore clarification is needed. Which definitions are valid for FEEL? The stricter XML Schema Part 2 or the more user friendly ISO 8601 spec?
Reported: DMN 1.1 — Mon, 13 Nov 2017 15:24 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Deprecate IANA time zone use in time strings
- Remove the XML Schema Part 2 from the specification as the ISO 8601 covers it.
- Deprecate usage of IANA IDs for time literals
- Add new function to allow migration of deprecated use cases.
Updated: Mon, 16 Sep 2024 14:16 GMT

Missing paragraph break and new constraintType

Key: DMN16-104
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The below text was a separate paragraph in DMN 1.4. In DMN 1.5 is a part of the previous paragraph. Also, the new typeConstraint property is missing.

An alternative way to define an instance of ItemDefinition is as a composition of ItemDefinition elements. An instance of ItemDefinition may contain zero or more itemComponent, which are themselves ItemDefinitions. Each itemComponent in turn may be defined by either a typeRef and allowedValues or a nested itemComponent. In this way, complex types may be defined within DMN. The name of an itemComponent (nested ItemDefinition) must be unique within its containing ItemDefinition or itemComponent.
Reported: DMN 1.5b1 — Thu, 2 Nov 2023 11:42 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Split paragraphs again

Split accidentally merged paragraphs and complete the list of options
Updated: Mon, 16 Sep 2024 14:16 GMT

Filter and Iterator in attribute should not require a collection

Key: DMN16-94
Status: closed
Source: Trisotech ( Mr. Simon Ringuette)
Summary:
Currently the in parameter is defined as: This attribute holds the expression that is evaluated as the collection to be processed.

The intention was to align with the FEEL version of filter and iterators and therefore apply the the 10.3.2.9.4 Type conversions rule: to singleton list: When the type of the expression is T and the target type is List<T> the expression is converted to a singleton list.

The definition of the in parameter needs to be updated to properly reflect this.
Reported: DMN 1.5b1 — Thu, 19 Oct 2023 21:59 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Clarify that implicit conversion applies to Filter and Iterator

Clarify that implicit conversion to singleton list applies
Updated: Mon, 16 Sep 2024 14:16 GMT

XSD: global context

Key: DMN16-5
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
10.3.2.9.2 says "The global context is a context provided for convenience and 'pre-compilation'. Any number of expressions can be named and represented in a FEEL context m. The syntactic description m of this context can be evaluated once, that is, mapped to the FEEL domain as m, and then re-used to evaluate many expressions." For example, you might want to put a Relation used as a multi-dimensional constant in the global context. Or you might want to put a reusable function definition in the global context. Currently the xsd does not have globals. All expressions are bound to a specific drgElement, not global. The Import element probably needs to be modified to support this also.
Reported: DMN 1.0 — Sun, 31 May 2015 16:35 GMT
Disposition: Closed; No Change — DMN 1.6b1
Disposition Summary:
Issue does not relate to current spec wording

The paragraph referred to in the issue has been reworded significantly in later versions.
Updated: Mon, 16 Sep 2024 14:16 GMT

No way to tell that a Decision iterates over a collection

Key: DMN16-55
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
There is no visual way to show that a decision iterates over a collection at the top level.
Reported: DMN 1.3 — Wed, 24 Feb 2021 05:31 GMT
Disposition: Closed; No Change — DMN 1.6b1
Disposition Summary:
Issue has mostly been addressed

A marker for Data Input collections has been added in ~~DMN14-151~~. Adding a marker for decisions iterating over them would attempt to reveal part of the decision's logic, which is not the purpose of a DRD.
~~DMN14-195~~ already added the boxed iterator expression.
So there is very little left to add to a DRD and ~~DMN14-151~~ has already used the icon that would be natural from a BPMN perspective.
Updated: Mon, 16 Sep 2024 14:16 GMT

More Generic Ways to Define Decision Table Properties

Key: DMN16-18
Status: closed
Source: OpenRules ( Jacob Feldman)
Summary:
I described several issues with the current way of representing decision table properties and made concrete suggestions for improvement in this LinkedIn post: https://www.linkedin.com/pulse/decision-table-properties-dmn-beyond-jacob-feldman
Reported: DMN 1.1 — Sat, 20 May 2017 19:09 GMT
Disposition: Closed; No Change — DMN 1.6b1
Disposition Summary:
Issue withdrawn

Jacob is fine with the feedback given to him and no changes to the spec are required.
Updated: Mon, 16 Sep 2024 14:16 GMT

Business Knowledge Model can have Information Requirements

Key: DMN16-4
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
FEEL function definitions are defined as lexical closures, which simply means that names in the function body must be in scope, and that scope includes the function parameters and, just like any other decision logic, it includes the information requirements and the knowledge requirements. This is very handy. For example, it allows the logic of a BKM to reference 100 Input Data items by name, without requiring that each invocation pass in 100 parameter bindings.

In order for this to work, the BKM would model 100 Information Requirements on the 100 Input Data items, instead of modeling them as parameters. The boxed invocations would not have 100 rows of repetitive binding information. We must extend the MM and Table 2 to allow a BKM to have information requirements.
Reported: DMN 1.0 — Thu, 23 Jul 2015 23:30 GMT
Disposition: Closed; No Change — DMN 1.6b1
Disposition Summary:
Issue rendered redundant by introduction if Invocable

This issue was raised before the introduction of invocables and decision services. Not considered necessary now.
Updated: Mon, 16 Sep 2024 14:16 GMT

No notation for ItemDefinition

Key: DMN16-2
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The notion of a 'type' or ItemDefinition is in the metamodel (with some pending issues) and in the semantics and concepts, but little is in the notation. Thus, we have notation that allows you to execute an expression with actual arguments, but no notation to allow validation based on type information without actual values.

We have most of the pieces, so it should not be difficult. E.g., individual values can be number, string, date and time, etc. We can allow numeric ranges using our unary tests, e.g. '>0', '[10..30)', etc. We can allow LOVs using "abc", "def", "ghi". These can be 'simple items', and we can also define structures using something similar to boxed contexts.
Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
Disposition: Closed; Out Of Scope — DMN 1.6b1
Disposition Summary:
No requirement for item definition notation

Notation for Item Definition is being addressed in SDMN
- out of scope for DMN
Updated: Mon, 16 Sep 2024 14:16 GMT

Improve description of built-in function string()

Key: DMN16-13
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
The expected output of the built-in function string() should be defined for each type. Otherwise it is unclear what the result for a value, for example of type time, is. Is it the string literal or the full expression with built-in function time()?
// which FEEL expression is valid? string(time("11:00:00")) = "11:00:00" string(time("11:00:00")) = "time("11:00:00")"
Recommendation: Introduce a new table that lists example outputs for all types:
- null -> null
- boolean -> "true" or "false"
- string -> "This is a string"
- number -> "-1.234"
- date -> "2017-10-11"
- time -> "11:00:00.123" or "11:00:00.123+02:00" or "11:00:00.123@Europe/Paris"
- date and time -> "2017-10-11T11:00:00.123" or "2017-10-11T11:00:00.123+02:00" or "2017-10-11T11:00:00.123@Europe/Paris"
- days and time duration -> "P2DT3H4M5.123S"
- years and months duration -> "P2Y3M"
- list -> "[1,2,3]"
- context -> "{a: true, b: false}"
- range -> "[1..100]"
- unary test -> "> 10"
- function -> null
Reported: DMN 1.1 — Wed, 11 Oct 2017 09:02 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Clarification needed if null is passed as value for optional parameter of built in function

Key: DMN16-12
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Some built-in functions has optional parameters. Chapter 10.3.4 describes "Whenever a parameter is outside its domain, the result of the built-in is null."

Should the following call to a built-in function result to null?
replace("This is a string", "[a-z]", "#", null)
The optional parameter "flags" of the built-in function replace() is null. Parameter domain is string as stated in table 60 on page 133. Null is not in the domain of type string.

This topic was already discussed in the DMN TCK. We think that the behavior should be the same as the function is called without the optional parameter:
replace("This is a string", "[a-z]", "#", null) = replace("This is a string", "[a-z]", "#")
Clarification in the specification is appreciated.

May be we can change the sentence in chapter 10.3.4 on page 130 to: "Whenever a parameter is outside its domain, the result of the built-in is null. If null is passed as value to an optional parameter, the built-in behaves like no value is passed."
Reported: DMN 1.1 — Tue, 10 Oct 2017 14:32 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Business Context links go both ways

Key: DMN16-1
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In XSD, business context pointers are duplicated in both directions. E.g. decisionOwner and decisionMaker point to organizationalUnit, which in turns has pointers back the other way. This duplication adds no new information, just potential for internal inconsistency. I suggest omitting one of these directions; the other one is easily extracted from the serialization by XPATH.
Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

FEEL descendants operator

Key: DMN16-72
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In some decision models, the input data must conform to an industry-standard xml schema in which elements of interest are many levels deep. Converting such a schema directly to a FEEL item definition requires very long path references. The xpath language has a descendants operator that significantly shortens the path expression. I propose a similar operator (or, less ideally, a function) for FEEL.

An example is MISMO from the Mortgage Bankers Association. In home appraisals, one item of interest is the Appraiser. To reference the Appraiser from the FEEL item definition generated from the xsd requires this:
MESSAGE.DOCUMENT_SETS.DOCUMENT_SET.DOCUMENTS.DOCUMENT.DEAL_SETS.DEAL_SET.DEALS.DEAL.SERVICES.SERVICE.VALUATION.VALUATION_RESPONSE.VALUATION_ANALYSES.VALUATION_ANALYSIS.PARTIES.PARTY[ROLES.ROLE.ROLE_DETAIL.PartyRoleType="Appraiser"][1]

In xpath, omitting namespace prefixes, the descendants operator // simplifies this considerably:
MESSAGE//PARTY[.//PartyRoleType='Appraiser']

If // were used as a FEEL descendants operator, you would need only
MESSAGE//PARTY//PartyRoleType="Appraiser"[1]

To get the Appraiser's name, instead of
MESSAGE.DOCUMENT_SETS.DOCUMENT_SET.DOCUMENTS.DOCUMENT.DEAL_SETS.DEAL_SET.DEALS.DEAL.SERVICES.SERVICE.VALUATION.VALUATION_RESPONSE.VALUATION_ANALYSES.VALUATION_ANALYSIS.PARTIES.PARTY[ROLES.ROLE.ROLE_DETAIL.PartyRoleType="Appraiser"].INDIVIDUAL.NAME[1]

you would need only

MESSAGE//PARTY//PartyRoleType="Appraiser"//NAME[1]
Reported: DMN 1.4b1 — Tue, 14 Mar 2023 19:38 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Add a descendent operator to the FEEL grammar

Add a descendant operator in the FEEL grammar that is similar to a path expression but uses 3 dots (...) instead of one.
Updated: Mon, 16 Sep 2024 14:16 GMT

Missing semantics for multiple imports

Key: DMN16-50
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The semantics of Import is not fully specified.

In certain use cases the same DMN element (e.g. ItemDefinition or DRGElement) can be imported multiple times (e.g. transitive imports).

Lets consider the following use case:
- Model A contains the definition of an InputData for a Person (e.g. name, age etc)
- Model B imports model A. Model B contains a decisions DB that uses the Person as input
- Model C imports models A and B. Model C contains a decision DC that uses Person and DB as input
In this situation model C imports Person twice due to transitive import.

In order to evaluate DC the Person InputData has to be bound to a value. The question is how many values is the user going to provide, lets say in a Web form? A single value or one value for each import path (in this case 2)?

I am inclining towards the first option - one single value per input data. Here is my rationale:
- InputDatas / DRGElements are uniquely identified by model namespace and DRGElement.name
- InputDatas own one single variable (see 6.3. Metamodel). The semnatics for InputData.variable is in Table 18:
  The instance of InformationItem that stores the result of this InputData.
- Consistency with the import of other DMN Elements: it does not make any sense for ItemDefinitions, BKMs and DSs to have multiple variables / values when imported several times.
- If we choose the second option and the model is refactored (e.g. models are merged), but the logic does not change, the user has to fill-in different input forms. It is not very user friendly.
- I am not aware of any PL/DSL that uses the second option
Lets discuss.
Reported: DMN 1.3 — Tue, 30 Mar 2021 08:28 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Define semantics for multiple imports

Define semantics for multiple imports of the same input data
Updated: Mon, 16 Sep 2024 14:16 GMT

Behaviour when decimal is provided but integer expected

Key: DMN16-82
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
In the DMN spec the only supported number type is decimal.

However, there are a few places (e.g. scale in round functions and list access) when an integer is needed.

What is the expected behavior when an integer is expected but a decimal number is provided? For example 'decimal(123, 5.6)' or ''remove([1, 2], 1.5).

Is this an error or the engine recovers from the error and uses only the integer part of the number?
Reported: DMN 1.5b1 — Thu, 20 Jul 2023 15:34 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Define type conversion from decimal to integer

Define type conversion from decimal to integer
Updated: Mon, 16 Sep 2024 14:16 GMT

Range of scale for number is open to interpretation

Key: DMN16-81
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
According to the DMN spec (10.3.2.3.1 number) a number is equivalent to "Java BigDecimal with MathContext DECIMAL 128.".

The Java doc states, " A BigDecimal consists of an arbitrary precision integer unscaled value and a 32-bit integer scale.".

However, the DMN spec de scale is in range range [−6111..6176].

The question is what is the correct range for scale?
Reported: DMN 1.5b1 — Thu, 20 Jul 2023 15:23 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Clarify definition of number as based on IEEE 754-2008 Decimal128

Remove misleading sentence from the definition of FEEL numbers as it lead people to believe that the definition was based on Java. The sentence was just a hint for implementers and that is already covered elsewhere in the spec.
Updated: Mon, 16 Sep 2024 14:16 GMT

Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122

Key: DMN16-24
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
on page 122 in table 43 in row 2 and 3: "e1 in [e2, e3, ...]"
on page 109 grammar rule 51.c: expression "in" positive unary test
on page 109 grammar rule 51.c: expression "in" "(" positive unary tests ")"

The syntax with square brackets is not allowed by the grammar rules 51.c. Either table 43 or grammar definition should be changed.
Reported: DMN 1.1 — Wed, 3 May 2017 08:58 GMT
Disposition: Closed; No Change — DMN 1.6b1
Disposition Summary:
Already possible

The issue was raised a long time ago. In the meantime, the grammar has changed. Currently, a positive unary test can be any feel expression, hence the second operand can be a list.
Updated: Mon, 16 Sep 2024 14:16 GMT

Inconsistent capitalization of datatypes names

Key: DMN16-92
Status: closed
Source: Trisotech ( Mr. Simon Ringuette)
Summary:
In section 10.3.1.3 Literals, data types, built-in functions, there is an enumeration of FEEL datatypes.

The first 3 starts with uppercase letters (Number, String, Boolean) while the other starts with lowercase letters.

Number, String and Boolean should be number, string, boolean like presented in the Figure 10-26: FEEL lattice type on page 112.
Reported: DMN 1.5b1 — Tue, 17 Oct 2023 15:16 GMT
Disposition: Resolved — DMN 1.6b1
Disposition Summary:
Correct capitalisation in 10.3

In Section 10.3.1.3, correct the capitalization of the first three items in the list.
Updated: Mon, 16 Sep 2024 14:16 GMT

italics and bold used for both typographic literal notation and FEEL semantic exposition

Key: DMN16-3
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
in typographic literals, italics are strings and bold italics are date literals, but in 10.3, italics are feel syntactic elements and bold are semantic elements. Better to have different notations
Reported: DMN 1.0 — Thu, 3 Sep 2015 15:58 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

No adjustment for last day in month if duration is added/subtracted to date and time value

Key: DMN16-10
Status: closed
Source: ACTICO ( Daniel Thanner)

Summary:

The specification says that the addition/subtraction of a date and time and a years and months duration value is defined as:

date and time (
   date(e1.year +/– e2.years + floor((e1.month+/– e2.months)/12),
   e1.month +/– e2.months – floor((e1.month +/– e2.months)/12) * 12,
   e1.day), 
   time(e1))

If you apply this expression to the following two values:

date and time("2017-08-30T11:00:00Z")
duration("P18M")
you would expect the following results:

date and time("2017-08-30T11:00:00Z") + duration("P18M")  --> result should be date and time("2019-02-28T11:00:00Z")
date and time("2017-08-30T11:00:00Z") - duration("P18M")  --> result should be date and time("2016-02-29T11:00:00Z")

If you apply the values to the defined formula, you get:

date and time (
   date(2017 +/– 1 + floor((8 +/– 6)/12),
   8 +/– 6 – floor((8 +/– 6)/12) * 12,
   30), 
   time("11:00:00Z"))

Addition
which results for addition into:

date and time (
   date(2018 + floor(1,1667),
   14 – floor(1,1667) * 12,
   30), 
   time("11:00:00Z"))

which is:

date and time (date(2019, 2, 30), time("11:00:00Z"))

The adjustment to the last valid day in a month is missing. 30th February is invalid, since February has only 28/29 days.

Subtraction
which results for subtraction into:

date and time (
   date(2016 + floor(0,1667),
   2 – floor(0,1667) * 12,
   30), 
   time("11:00:00Z"))

which is:

date and time (date(2016, 2, 30), time("11:00:00Z"))

The adjustment to the last valid day in a month is missing. 30th February is invalid, since February has only 28/29 days.

Recommendation:
Adjustment to last valid day in month must be added to spec.

Reported: DMN 1.1 — Mon, 2 Oct 2017 12:41 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Enhancement suggestion: make unary tests first class citizens of the FEEL language

Key: DMN16-7
Status: closed
Source: Red Hat Inc ( Edson Tirelli)
Summary:
This is a suggestion for future versions of the spec:

Add support for Unary Tests as first class citizens of the FEEL language, in a similar way as ranges and functions already are.

A unary test is really a “predicate”: a single parameter function that returns a boolean. It is syntax sugar on:

function ( x ) x in <unary_test>

FEEL already supports functions as first class citizens, so it makes sense to support Unary Tests. The following two syntaxes would then be equivalent:

is minor : < 18
is minor : function( age ) age in < 18

Invoking unary tests explicitly would be like invoking a function:

Bob is minor : is minor( bob.age )

More importantly, it would allow the implementation to actually support passing unary tests as parameters to functions and make the example on page 115 viable:

decision table (
outputs: "Applicant Risk Rating",
input expression list: [Applicant Age, Medical History],
rule list: [
[ >60, "good", "Medium" ],
[ >60, "bad", "High" ],
[ [25..60], -, "Medium" ],
[ <25, "good", "Low" ],
[ <25, "bad", "Medium" ]
],
hit policy: "Unique"
)

Unary test syntax is not ambiguous, so supporting it would mean to basically change rule 2 in the grammar to include rules 14 and 17 as possible options. The semantic mapping table on page 116 would also need to include a new FEEL value type: "unary test".
Reported: DMN 1.1 — Tue, 23 Aug 2016 01:41 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Should encapsulated decisions of a decision service include output decisions?

Key: DMN16-9
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Figure 10 on page 25 with text "The encapsulated decisions are therefore
{Decision 1, Decision 2}
"

Figure 11 on page 26 with text "The encapsulated decisions for this services are
{Decision 1}
".

Table 20 on page 56:
- "outputDecisions: This attribute lists the instances of Decision required to be output by this DecisionService".
- "encapsulatedDecisions: If present, this attribute lists the instances of Decision to be encapsulated in this DecisionService".
For us it is unclear what decisions should be stored in the DMN model as encapsulated decisions. Must the output decisions also be included in the list of encapsulated decisions (as stated on page 25, 26)? Or does the list of encapsulated decisions only hold the decisions contained in the lower compartment of a decision service (as mentioned on 56 since encapsulatedDecisions seems to be optional)?
Reported: DMN 1.0 — Tue, 20 Mar 2018 14:49 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions

Key: DMN16-8
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
In Figure 6.15 the multiplicity of output decisions for a decision service is shown as zero to many (0..), but the text below and Table 16 says the that multiplicity is one to many (1..). The figure should be correct to match the text and table.
Reported: DMN 1.1 — Fri, 3 Aug 2018 21:19 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Include Test Cases in Decision Model

Key: DMN16-6
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
For interchange of test cases along with a decision model, it would be convenient to define metamodel and xsd elements for a suite of test cases, where a test case contains values for input data and expected values output decisions.
Reported: DMN 1.1 — Sat, 28 May 2016 16:25 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT
Attachments:
- testCases.xsd 3 kB (text/xml)

Scope of decision table input/output entries is not well defined in the specification

Key: DMN16-19
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
While the scope of context entry specifically says to include the previous context entry (section 7.3.1), there is no mention for the scope of input and output entries of decision tables.
Reported: DMN 1.1 — Mon, 15 May 2017 17:59 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Add two new concrete numeric types, make number abstract

Key: DMN16-15
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Currently S-FEEL / FEEL contains only one single numeric type called number that matches the semantics defined in IEEE 754-2008.

This can lead to some strange constructions, such as
substring("footbar", 3.67)
perfect valid in FEEL.

It also has impact on the performance of the execution (speed).

Here is my proposal:
- keep number as an abstract type to backwards compatibility
- add a new concrete type real/float/decimal that matches the semantics of defined in IEEE 754-2008
- add a new concrete type integer
- change the signature of all built-in functions to restrict number to integer when it makes sense (e.g. index in a string and list, length of string. size of list)
- add a separate paragraph to specify the implicit conversions performed by the FEEL processor when required (e.g. function resolution). For example,
  2 + 4.5 leads to a promotion 2 -> 2.0 that adding it 4.5.
If we agree in principal all start working on it.
Reported: DMN 1.1 — Wed, 6 Dec 2017 13:44 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

How to get FEEL type if evaluation is not an option?

Key: DMN16-20
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
in chapter 10.3.2.10: "Sometimes we do not want to evalutate a FEEL expression e, we just want to know the type of e."

in table 54: column Applicability defines which row in the table to use, depending on the type of a FEEL expression.

Table 54 only makes sense if it is not allowed to pre-evaluate the expression e2, since even for a pre-evaluation context entries (for example: "item") must be declared in scope.

How do we know the type of a FEEL expression if it is not allowed to evaluate it?

Examples:
- [1,2,3][min(3,2,1)]
- {a:function() external {java: {class: "clazz", method signature: "method()"}}, b:[1,2,3][a()]}.b
- {a: 1, b: a instance of number, c: [1,2,3][b] }
Reported: DMN 1.1 — Wed, 3 May 2017 14:56 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

FEEL grammar readability

Key: DMN16-17
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
The grammar contains several sub-grammars each one with its own start non-terminal: expression, simple expressions, unary tests.

The grammar should be broken in several grammars, and common part to make things more obvious. It will help the CL3 implementation.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:37 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Semantic domain mapping for simple expressions

Key: DMN16-25
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The FEEL grammar contains simple expressions as starting terminal

page 107 6. simple expressions = simple expression ,
{ "," , simple expression }
;

I could not find a mapping to a semantics domain for it. What is the type / domain of "simple expressions"? A list with element type Any or a Tuple Type with several element types?
Reported: DMN 1.1 — Fri, 17 Mar 2017 14:42 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Can an expression in user defined function body reference a name outside of it's scope?

Key: DMN16-21
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
If an expression in a user defined function body references a name outside of it's scope (for example a parent scope), this scope must be available also during invocation of the function.

Examples:
- {f:function() a, a:1, i:f()}
  possible, since name a is still available in local context (scope) during invocation
- {b:1,f:function() b}
  .f() impossible, since name b is not available outside of the context.
It would be nice if the semantic mapping and the differentiation between function definition and invocation is clearly specified in the spec. What names can be referenced? Must the scopes also be available during invocation?
Reported: DMN 1.1 — Wed, 3 May 2017 15:24 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Can the same Definitions/namespace be used by more than one model?

Key: DMN16-14
Status: closed
Source: Red Hat ( Edson Tirelli)
Summary:
Please clarify if it is possible to have multiple models on the same namespace. For instance:

<definitions namespace="http://my.company/financeModels" name="Model A" ...

<definitions namespace="http://my.company/financeModels" name="Model B" ...

The current text of the specification does not say anything explicitly one way or another, so please clarify that.

In addition to this, if multiple models can use the same namespace, then the <import> element will require an additional attribute (for instance: modelName) in order to uniquely identify which model should be imported.
Reported: DMN 1.1 — Thu, 8 Mar 2018 16:20 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

inconsistent date comparisons make unavoidavle paradoxes

Key: DMN16-35
Status: closed
Source: fujitsu america ( keith swenson)
Summary:
Date "=" is defined to include the time zone, and "<" and ">" does not. This causes a bunch of problems.

see: https://social-biz.org/2017/08/03/a-strange-feeling-about-dates/

Suggestion is simple: define date equality to be (date1 - date2 == 0) Eliminate the need to compare the "timezone" of the dates.

My experience with the group is that most suggestions are ignored, so I don't really want to waste any time making a more detailed proposal, but if you have questions about this problem you can contact me.
Reported: DMN 1.2 — Wed, 18 Sep 2019 10:01 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Should name declarations in same context fail or overwrite?

Key: DMN16-22
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
As I see the spec doesn't define what should happen if in a context a name should be declared that already exists in the current context. Sample FEEL expression: "for i in [1,2,3], i in [4,5,6] return i * i" Does the second definition of i overwrite the first one or should we return null for the complete "for" expression?
Reported: DMN 1.1 — Wed, 3 May 2017 09:25 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test

Key: DMN16-23
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
For simple positive unary test(s) there are extra entry points in the FEEL grammar. Therefore why do we need simple positive unary test in grammar rule 2.i. What is the semantic mapping?
Reported: DMN 1.1 — Wed, 3 May 2017 09:11 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

notion of arbitrary order conflicts with lack of an unordered collection data type

Key: DMN16-31
Status: closed
Source: Signavio GmbH ( Dr. Bastian Steinert)
Summary:
Section "8.2.11 Hit policy" describes that hit policy "Collect: returns all hits in arbitrary order". This implies that the order of the results does not have to be deterministic and can also vary among different implementations. However, the standard only supports the notion of 'lists', which do have an order. The comparison of lists is also specified in a way that the order of elements is significant. The issue might get more clear when thinking about testing the interface of decisions. Strictly speaking, it is currently not feasible to define a test against a decision table with hit policy 'collect'. The expected result can only be defined using a list, whose elements do have an order. The operator to compare the 'expected' and the 'actual' result will also take order into account.

The issue could easily be resolved by replacing 'arbitrary order' with 'rule order'.
Reported: DMN 1.1 — Sun, 26 Jun 2016 10:11 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

DMN Models need a default timezone

Key: DMN16-34
Status: closed
Source: fujitsu america ( keith swenson)
Summary:
All date expressions, if the timezone is not explicitly mentioned, are interpreted as being in the timezone of the computer running the code. This means you can design a model that runs correctly in one timezone,a nd incorrectly in a different one.

Imagine you have a development team in Bangalore which makes a DMN model that runs correctly and passes all the tests. Then it is installed into the company server in London, and it fails.
Does anyone think this is a good idea?

The solution is simple: the model should have a default timezone. All date expressions that don't mention the timezone are interpreted according to this default time zone, and NOT according the timezone of the machine you are running on. Then, models will run exactly the same way no matter where it is run. That is a good idea, right?

See this: https://social-biz.org/2017/08/03/a-strange-feeling-about-dates/
Reported: DMN 1.2 — Wed, 18 Sep 2019 09:55 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Unspecified conclusion is not supported

Key: DMN16-32
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
I remember discussions about allowing "-" in conclusions to mark an unspecified conclusion in a decision table. This would allow some of the conclusions in a multiple output decision table to be marked as "unspecified" where there was no output relevant for that conclusion for a specific rule and to allow rules in multi-hit tables to show that a particular combination of conditions had been considered but did not result in anything being added to the result set.
However the standard as written says that an output entry must adhere to the literal expression grammar, and '-' is not allowed. You have to return some FEEL value, e.g. 0, false, "N/A", null, etc.
Reported: DMN 1.1 — Mon, 13 Jun 2016 21:41 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Fix interchange of links to objects in BPMN/BMM

Key: DMN16-33
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
The current spec uses objects from BMM and BPMN. However it is not at all clear how links to these objects, and the objects at the end of the links, should be interchanged. Does the DMN file contain a snippet of BPMN? Should a separate BPMN file be generated and then referenced? If we are going to have these links then we need to show/explain how to interchange them both with tools that only support DMN (and so only have a few BPMN or BMM objects) and with those that support DMN/BPMN/BMM.
Reported: DMN 1.2 — Thu, 27 Sep 2018 01:07 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Requested additional built-in functions

Key: DMN16-26
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(from Bruce)
a. String-join(stringList, separatorString)

b. Format-number(value, formatString), where formatString (to be negotiated) generally follows Excel or xpath, maybe not all the features.

c. Format-date(value, formatString), format-dateTime(value, formatString)
Reported: DMN 1.1 — Mon, 2 Jan 2017 20:43 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Support for recursive calls by Business Knowledge Models

Key: DMN16-42
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The definition of "well formed" for a BusinessKnowledgeModel excludes the notion of the encapulatedLogic of a BusinessKnowledgeModel being able to invoke itself to permit recursion. There is no means to define a 'self' relationship via knowledgeRequirements - the spec forbids it.

However, vendors are currently supporting BusinessKnowledgeModel recursion simply by permitting a BusinessKnowledgeModel's encapulatedLogic to invoke the contained BusinessKnowledgeModel as a function using the contained BusinessKnowledgeModel's name. I propose we formalise this in the spec.

I propose that after the definition of well-formed on page 56/57 (repeated below):

"An instance of BusinessKnowledgeModel is said to be well-formed if and only if, either it does not have any knowledgeRequirement, or all of its knowledgeRequirement elements are well-formed. That condition
entails, in particular, that the requirement subgraph of a BusinessKnowledgeModel element SHALL be acyclic, that is, that a BusinessKnowledgeModel element SHALL not require itself, directly or indirectly. "

The following paragraph is added:

"However, the encapsulatedLogic within a BusinessKnowledgeModel may invoke itself in a recursive manner by using the name of the containing BusinessKnowledgeModel as an invokable name."
Reported: DMN 1.2 — Sat, 6 Apr 2019 02:38 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Shared Data Model and Notation (SDMN)

Key: DMN16-36
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
Situational Data is the set of Data Items and their structures that are needed for the performance and understanding of a Knowledge Package Model.
The details of the Data Items will usually be a subset of the “official” complexity of those items in the environment of the Knowledge Package Model.
For example, the official definition of the Data Item for Blood Pressure (in healthcare) includes more than 50 properties. A Data Item in a Situational Data Model may need only 2 of those properties for execution of the Processes, Cases, and or Decision Services.
Semantic References can be added to link the Data Item to the “official” details.
Uses of the Data Items in BPM+ models that determine the scope of Situational Data include:
Data required for DMN Decisions
Data required for BPMN Gateways transitions
Data required to be passed to/from services invoked by BPMN and CMMN
Data required to trigger Sentries in CMMN
Etc.
Reported: DMN 1.2b1 — Tue, 10 Sep 2019 18:04 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT
Attachments:
- BMI Update - SDMN Sep 23 2019.pptx 3.94 MB (application/vnd.openxmlformats-officedocument.presentationml.presentation)

"instance of" not possible with some built-in functions

Key: DMN16-46
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
some built in functions are overloaded in that they can have multiple signatures. So, say, performing an "instance of" to compare against the function "min" is meaningless as the signature is not known unless it is invoked.

Unless the type system is to take into account overloaded functions?
Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:15 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.

Key: DMN16-47
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.
UnaryTest should be added to the diagram.
Reported: DMN 1.3 — Wed, 1 Jan 2020 00:23 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Temporal precision inconsistencies

Key: DMN16-38
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
The spec sometimes refers to the temporal precision as milliseconds and sometimes to seconds. Sections 10.3.2.3.3, 10.3.2.3.5 and 10.3.2.3.6 refer to Seconds whereas table 48 offers a semantic of Milliseconds
Reported: DMN 1.2b1 — Tue, 16 Jul 2019 14:02 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Provide better spec and examples for Equality, Identity, and Equivalence

Key: DMN16-39
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
the builtin function is() refers to this section. It should cover some pos/neg examples of equality vs. identity, and explain aggregate elements in D, e.g. list of structures.
Reported: DMN 1.2b1 — Tue, 28 May 2019 16:40 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Friendlier handling of null values

Key: DMN16-40
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
E.g. in aggregation, default for item definition, see examples in DMN-2, where filters like [item!=null] are used repeatedly
Reported: DMN 1.2b1 — Tue, 21 May 2019 16:53 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

need set operations and equality in FEEL

Key: DMN16-30
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
some notes toward a proper description:
FEEL has ordered lists and some set builtins, e.g. distinct values and union. Lacks intersection and equality.

[1,2] in (1,2,[1,2], 3) is true

intersect([1,2,3], [3,1,4]) = [1,3]

set equals([1,1,3], [3,1]) is true
probably - distinct values([1,1,3]) = distinct values([3,1])
maybe change to set([1,1,3]) = set([3,1])
(set needs to both remove dups and return elements in canonical order)
what is canonical order [null, 0, {}, []]?
[1,3] = [3,1] is false

Another option is to add sets to FEEL semantic domain (along with lists, numbers, contexts, ...). And need syntax.

simpler and more biz friendly proposal - add 'contains any' and 'contains all' as boolean infix operators taking 2 lists as LHS and RHS. And allow these to be added to unary tests w/o a '?'. E.g. 1,2,3 , in (1,2,3) , contains any (1,2,3), contains all (1,2,3). First 2 are what we have now (2nd allowed for symmetry). Last 2 assume input expr is a list (set).

if we just add set oriented builtins, but no friendlier syntax, this may not solve the biz problem of allowing DTs to process sets in a user friendly way. Too many ()s and ?s
Reported: DMN 1.1 — Thu, 11 Aug 2016 15:35 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Metamodel constraints & validation

Key: DMN16-27
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
None of the metamodels contain logic constraints. For example, the name of a decision table is the same with the name of the variable defined inside of the decision table tag (invariant at decision table level).

Ideally these constrains would be used to validate the diagrams before execution (e.g. generating code from Java). Bruce Silver's already covers some of the. We should add them and more in the spec.

I think the metamodel constraints should be described with OCL – see the UML metamodels. There should be constraints for CL1, CL2 and CL3. It’s very likely the CL3 constraints will be a superset of CL2 constraints.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:45 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement

Key: DMN16-29
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement
Reported: DMN 1.1 — Wed, 24 Aug 2016 16:45 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Lack of visual notation for processing of / iteration over lists in FEEL

Key: DMN16-41
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
split off from ~~DMN13-12~~
Reported: DMN 1.2 — Tue, 20 Nov 2018 17:55 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Inconsistency DMNv1.2 dropping [a]=a and get entries example

Key: DMN16-45
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
Since DMNv1.2 the spec dropped the equivalence of:
[a] = a
because it does not apply to the statement that

a singleton list L, when used in an expression where a list is not expected, behaves as if L[1] is written.

So the expression
[a] = a
on DMNv1.2 is expected to return false.

However, in section 10.3.2.6 Context of the spec, it provides the following statement for the get entries function:
To retrieve a list of key,value pairs from a context m, the following built-in function may be used: get entries(m).
For example, the following is true:
get entries({key 1 : "value 1 "})[key="key 1 "].value = "value 1 "
BUT
get entries({key1 : "value1"})[key="key1"].value = "value1" by substitution: [ { key : "key1", value : "value1" } ][key="key1"].value = "value1" [ { key : "key1", value : "value1" } ].value = "value1" [ "value1" ] = "value1"
according to DMNv1.2 should be false

By the same principle that the DMNv1.2 for the following literal expression:
[123] = 123
on DMNv1.2 is expected to be false
Reported: DMN 1.2b1 — Wed, 30 Jan 2019 14:43 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Add an itemKind property to ItemDefinition

Key: DMN16-49
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
SDMN, BPMN, and CMMN have a property that specifies the kind of element that is being modeled. The set of enumerations for this property include: data, conceptual, physical, etc.
SDMN is directly referencing DMN’s ItemDefinition, but is extending the element to include this “itemKind” property.
If this property makes sense in the DMN context and is added in DMN 1.4, then SDMN would not have to extend ItemDefinition for this property.
SDMN extends ItemDefinition in other ways, which will be addressed by separate issues.
Reported: DMN 1.3b1 — Tue, 6 Apr 2021 22:11 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

P0D == P0Y in SFEEL, but it is unclear if P0D == P0Y in FEEL

Key: DMN16-56
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
Section 9.4 says "Comparison operators are defined only when the two operands have the same type, except for years and months duration
and days and time duration, which can be compared for equality. Notice, however, that “with the exception of the zerolength
duration, no instance of xs:dayTimeDuration can ever be equal to an instance of xs:yearMonthDuration.”

Thus stating that `P0D == P0Y` despite the fact they are different types and do not comply with the type-lattice equivalency. This is as per the XPATH operation `op:duration-equal` that the spec says equality here conforms to.

It is not crystal clear if this applies to FEEL as well as SFEEL though the same sections does say:

> The semantics of S-FEEL expressions are defined in this section, in terms of the semantics of the XML Schema datatypes
and the XQuery 1.0 and XPath 2.0 Data Model datatypes, and in terms of the corresponding functions and operators
defined by XQuery 1.0 and XPath 2.0 Functions and Operators (prefixed by “op:” below). A complete stand-alone
specification of the semantics is to be found in clause 10.3.2, as part of the definition of FEEL. Within the scope of SFEEL,
the two definitions are equivalent and equally normative.

So, "Within the scope of SFEEL, the two definitions are equivalent and equally normative." seems to indicate that it does hold true for FEEL.

My recommendation is that `P0D == P0Y` does apply to FEEL because it would make sense to a business person. `1 Apple != 1 Orange`, but zero apples is really the same as zero oranges, or zero anything for that matter. And, in practice, zero days really is the same as zero years.
Reported: DMN 1.3 — Fri, 19 Feb 2021 09:31 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

the operation of is() function is not well specified

Key: DMN16-57
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The new is() function is in a spec section called "Date and time functions" but it is unclear if it related only to date and time types. The examples only show date and time. Though it would seem reasonable that is also handled datetime type as well.

Additionally, it references section 10.3.2.2 for descriptions of semantics and that section deals with ore than just date and time. It also deals with other 'primitive' types - so it is unclear if is() relates to these also. Additionally, that section does not deal with other types like range/context/function/list so it is not clear if is() deals with all types in that section, and indeed other types as well.

By example, is it not evident if is({},{}) is true, false, or illegal. Similarly for is([1], [1]) or is(1,1), or is([null..2], < 2).

Additionally, it is also unclear (to me) from the semantic description whether is(@"2021-02-19T10:10:10Z", @"2021-02-19T10:10:10@Etc/GMT") as they are both UTC forms. The spec says they are 'comparable', but does that relate to is()?
Reported: DMN 1.3 — Fri, 19 Feb 2021 10:20 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

properly define type(e)

Key: DMN16-44
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
In some places the spec uses type(e) and other places type(e). These are different. The former provides a type-checking function that can validate a FEEL expression e without input data values (although some kind of scope is needed for disambiguation). The latter simply returns the datatype of the semantic domain element e. The former is more useful to implementors, but more work to specify. Essentially, all the semantic mapping tables need a new column to specify the result type given the input types, for each FEEL operator and builtin. The latter is a matter of generalizing Table 39. It must cover cases such as type([0,false]). It should be clear that type(e) as a function must return the most specific type (and there must be only 1), but informally the types also include those that are conformed to, so for example, [1,2,3] has types list<number>, list<Any>, Any.
Reported: DMN 1.2 — Tue, 27 Nov 2018 22:31 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Clarification on DMN case sensitivity of timezones

Key: DMN16-43
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
DMN spec refers to usage of iana timezones. iana does not specify that timezones are case-sensitive - that is up to the implementation. https://data.iana.org/time-zones/theory.html: re zone naming:

"Do not use names that differ only in case. Although the reference implementation is case-sensitive, some other implementations are not, and they would mishandle names differing only in case."

This issue is seeking clarification via the spec as to whether DMN's usage of time zones permits case insensitivity such that "etc/utc" is the same zone as "Etc/UTC" ... or not.
Reported: DMN 1.2 — Sat, 16 Mar 2019 01:12 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Spec does not mandate that all user-defined function parameters are utilised

Key: DMN16-51
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
Section "10.3.2.13.2 User-defined functions" provides definition and invocation semantics for user defined functions but permits unused parameters.

As DMN is to be 'executable documentation' I suggest that unused parameters provide documentation that does not reflect reality.

I propose the follow additional paragraph to "10.3.2.13.2 User-defined functions" :

"The body expression of a user-defined function SHALL utilise every formal parameter. "
Reported: DMN 1.3 — Thu, 25 Mar 2021 08:35 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

FunctionItem `parameters` array attribute is plural, not singular in name

Key: DMN16-59
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The `parameters` attribute of the new FunctionItem introduced in DMN 1.3 is plural in name and not singular like all other array attributes described in the meta-models. This is an exception.

This leads to an XML form where each `<parameters>` element contains one parameter.

Recommendation. Change FunctionItem array attribute `parameters` to `parameter`. Another possibility is to deprecate `parameters` in favour of `parameter` and drop support in a future version.
Reported: DMN 1.3 — Tue, 2 Feb 2021 22:55 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

No way to show relative multiplicity of decisions and their information requirements

Key: DMN16-54
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
Item Definitions are hierarchical so the top level one in an Input Data or a Decision might not be a collection while one or more of those contained are. This means that there may be a collection to process even if the Input Data or Decision is not marked as a collection (see ~~DMN14-123~~ for this separate issue). It should be possible to show both "fan in" where multiple instances of the source of the requirement are used by a single instance of a decision and "fan-out" when the source of requirement contains a collection which will be processed one at a time by the decision.
Reported: DMN 1.3 — Wed, 24 Feb 2021 05:36 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT
Attachments:
- FanProposal_JTJP.pdf 297 kB (application/pdf)

Spec does not mandate that all formal parameters are utilised.

Key: DMN16-52
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
Section "10.5.3 FunctionDefinition metamodel" does not specify that formal parameters must be utilised in the function logic . As DMN is a self-documenting decision executable this leads to a situation where (documented) parameters may be defined but unnecessary.

I propose the following paragraph is added to section "10.5.3 FunctionDefinition metamodel":

"The body expression of a FunctionDefinition SHALL utilise every formal parameter. "
Reported: DMN 1.3 — Thu, 25 Mar 2021 08:25 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Ambiguous named params for before() and after() range functions

Key: DMN16-58
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The `before` and `after` range functions have ambiguous invocation when using named params. Both functions have 4 variants - take `before` as an example:

```
(a) before(point1, point2)
(b) before(point, range)
(c) before(range, point)
(d) before(range1, range2)
```

If I invoke `before(range: [1..10], point: 1)` is it for variant (b) ... or (c) ... ?

Suggest renaming the param names or making the variants separate functions.
Reported: DMN 1.3 — Tue, 2 Feb 2021 23:38 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

XML serialization is not human friendly

Key: DMN16-112
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
DMN models are serialized in the XML format. XML notation is not user-friendly.

I suggest adopting an equivalent textual notation that is user-friendly similar to the HUTN notation for UML https://www.omg.org/spec/HUTN/1.0/PDF
Reported: DMN 1.5b1 — Tue, 5 Dec 2023 11:28 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

DRG requirements only state am unused knowledge requirement is illegal

Key: DMN16-53
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
Subsection "6.2.2.2 Knowledge Requirement notation" of "6.2.2 DRD Requirements" states that knowledge requirements must be utilised in the decision/BKM knowledge requirement:

"If e is a decision or a BKM in some DRD, and e contains a knowledge requirement on some invocable element b, then the logic of e must contain an invocation expression of b, including expressions for each of b's parameters."

However, this section does not mandate that Information Requirements must also be utilised by the requiring DRG element in the same way that a knowledge requirement must. If a purpose of DMN is to serve as documentation and show actual relationships between decision elements then it is paramount the DRG reflects actual usage in the model, otherwise the graph is incorrect - it may show relationships that do not reflect the decision-making reality.

I propose adding the following to section "6.2.2.1 Information Requirement notation":

"If e is a DRG element in some DRD, and e contains an information requirement on some other DRG element b, then the logic of e MUST contain a usage of the information provided by b"
Reported: DMN 1.3 — Thu, 25 Mar 2021 08:10 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Importing libraries of functions is not business friendly

Key: DMN16-69
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
There are many different Functions that are needed to make FEEL expressive enough for tackle the logic of various contexts/industries:
e.g Financial Functions, Healthcare Functions, etc. even advanced Mathematical functions or Matrix manipulation functions.

Currently these functions need to be imported in, and then all functions need to be prefixed with a namespace.
This not ideal as the business friendly name with space such as "annual interest rate" now becomes cryptic as "financial.annual interest rate"
or "discount as percentage" becomes "financial.discount as percentage"
Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:27 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Allow for partial temporal values

Key: DMN16-60
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
It should be possible to define partial temporal values but only for trailing precisions (i.e., if you specify a day, you must also specify a year and month)
Values of type Date, the precision unit must be one of: years, months, or Days
e.g. date( 2019 ), date( 2019, 09 ), date( 2019, 09, 17)
Values of type Time, the precision unit must be one of: hours, minutes, or seconds
e.g. time( 09 ), time( 09, 55), time( 09, 55, 00)
Values of type Date and Time, the precision unit must be one of: years, months, days, hours, minutes, or seconds
e.g. date and time( date(2019,09,17), time(09,55) ), date and time( “2019-09-17T09:55”)

Operations carried out on elements with different time based precision units shall be done based on the lowest common precision unit (truncating any resulting decimal portion)
Reported: DMN 1.3 — Tue, 26 Jan 2021 22:17 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Allow input data to be of type Interval

Key: DMN16-63
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
In many situations, it is desirable to have a data input that is an interval. Particularly when it comes to temporal logic many situations requires one to enter the "Valid Period", the "Measurement Period", the "Disccount Period" etc
To currently achieve this requires to create two data inputs (one for the start data/time and one for the end data/time) and then assembling them into an interval named "Period using a literal expression [start..end].
Reported: DMN 1.3 — Mon, 25 Jan 2021 20:17 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Adding a new interval built-in function

Key: DMN16-62
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Add a new interval built-in function called: width of( Interval )
to offer the behavior as follows:
width of( (1..10] ) = 9
width of( [1..10] ) = 10
width of( (1..10) ) = 8
width of( [ time(“09:55:00”)..time(“10:35:00”) ] ) = PT40M
Reported: DMN 1.3 — Tue, 26 Jan 2021 22:03 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer until we have Integer numbers

We see the potential value of the proposed function. The examples show that results can be interpreted in different ways. Usefulness would be increased if we had integer numbers.
Updated: Mon, 16 Sep 2024 14:16 GMT

Missing InformationItem Association?

Key: DMN16-66
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
In other sections in the spec, InformationItem is described as storing the data through an ItemDefinition or Expression. Figure 6.16 shows that InformationItem has a /type association with ItemDefinition. Other figures show this also.
But the table in the section on InformationItem (7.3.4) doesn't list this association and ItemDefinition is not mentioned in the section.
Reported: DMN 1.3 — Fri, 10 Jul 2020 21:28 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Interchanging models that use external libraries of functions is complicated

Key: DMN16-70
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Currently if a DMN model makes use of an external library of functions, the receiving tool may be challenged in also importing this library and execute on these new functions.

We should explore a way to make the interchanged model not only exchangeable but also executable.
Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:35 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Functions cannot invoke external services

Key: DMN16-67
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
The current definition of externally-defined functions only allows Java and PMML external functions. There are clear use cases for allow an external (stateless and side-effect free) service to be used in this way.
Reported: DMN 1.4 — Wed, 16 Mar 2022 19:34 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Links with other standards

Key: DMN16-65
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
A "bucket" for collecting related issues around external links
Reported: DMN 1.3 — Tue, 3 Nov 2020 18:17 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

ambiguity for collections

Key: DMN16-125
Status: closed
Source: University of Koblent, SAP Signavio ( Carl Corea)
Summary:
I do not understand the following aspect about collections: Assume the input data node is a collection, but the decision is NOT a collection. From my understanding, the individual values of the input collection are passed iteratively to the decision. As the latter is NOT a collection in the example, it is my understanding there should be some form of aggregation(?).

I can understand how this should work for numerical values (e.g. "aggregate" by sum) however I am not clear of the aggregation method (is it always sum?). Furthermore, how should aggregation work if the output column of the decision contains strings?

Example: Two rules: "a"->"b", "c"->"d". Then an input collection {"a","c"} is passed. So the two outputs are "b", "d". As the decision is NOT a collection, we should not yield something like {"b","d"}, but should aggregate(?), yet, as stated, how to aggregate b,d?
Reported: DMN 1.4b1 — Wed, 10 Apr 2024 07:57 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

No way to show dependencies of a grey-box decision service

Key: DMN16-77
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
When a decision service is fully defined, its dependencies are shown as the information requirements of its encapsulated decisions on external decisions or input data. If the encapsulated decisions of a decision service are not fully defined (e.g. temporarily during analysis, or because it is modelling a 3rd-party service with partial obfuscation), this may not be possible. It would be convenient in such cases to be able to draw information dependencies attaching to the boundary of the decision service. Such a service would not be executable.

This issue is a continuation of https://issues.omg.org/browse/DMN15-36 which was deferred to 1.6.
Reported: DMN 1.5 — Wed, 5 Jul 2023 16:05 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT
Attachments:
- DMN 15 Gray Box decision services JT AF.docx 487 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Clarification on the FEEL sort function with the precedes function

Key: DMN16-123
Status: closed
Source: Trisotech ( Mr. Simon Ringuette)
Summary:
In section 10.3.4.9 of the DMN 1.5 specification (page 153, PDF 161) the sort function is defined with the possibility to use a precedes boolean function to compare list elements.

Text should be added after table 80 to clarify how the precedes function deal with equal parameters.

I would propose that precedes return false when both parameters are equals.

This new paragraph should also establish the stability expectation of the sort FEEL function (equal elements keep the order of the original list).

I would propose that the FEEL sort function does not guarantee stability. Guaranteeing stability could impact certain sort performances.
Reported: DMN 1.5b1 — Thu, 21 Mar 2024 19:28 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Knowledge Sources are not fit for ML or AI purposes

Key: DMN16-119
Status: closed
Source: Decision Management Solutions ( Mr. James Taylor)
Summary:
Especially when used in projects that use ML or AI models, the current approach to Knowledge Sources is not fit for purpose. A more structured, template-based approach is needed to specify what information should be captured about a policy document, a regulation, a MVAR/imputation approach, an ML model training regime, data distributions etc. Either a defined set of knowledge source types should be defined with more specific properties or it should be possible to define, exchange and use templates.
Reported: DMN 1.5 — Fri, 23 Feb 2024 22:50 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to future revision

There seems to be to little interest for now
Updated: Mon, 16 Sep 2024 14:16 GMT

Duplicated names and labels

Key: DMN16-106
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
According to 6.3.1 DMN Element metamodel and 6.3.5 DRG Element metamodel, DRGElements have name and label attributes.

They also have a variable property that has a name. The DMNDI model also has a label property.

Possible solution:
- deprecate the attributes (e.g. DMNElement.label)
- add a constraint (e.g. DRGElement.name == DRGElement.variable.name)
Reported: DMN 1.5b1 — Mon, 27 Nov 2023 10:49 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Relation conforms to and equivalent do not cover functions with variable arguments

Key: DMN16-79
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Sections 10.3.2.9.1 Type Equivalence and 10.3.2.9.2 Type Conformance define relations between types.

The definitions do not contain specification for existing builtin functions with variable arguments (e.g. sum).

The issue was discovered in TCK when testing function invocations.
Reported: DMN 1.5b1 — Tue, 4 Jul 2023 07:57 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

It is not possible to assign a default value to a data type

Key: DMN16-78
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
When creating a data type I cannot assign a default value (for when the user input is provided as null)
Reported: DMN 1.4 — Thu, 15 Jun 2023 19:56 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

No binding to Python functions

Key: DMN16-101
Status: closed
Source: Decision Management Solutions ( Mr. James Taylor)
Summary:
There is clear value to ML projects of using DMN to document their projects (requirements, project design, MLOps). ML programmers though use Python not Java for their functions. If DMN can support Java libraries for rules developers, it should support Python for ML developers.
Reported: DMN 1.5 — Fri, 3 Nov 2023 22:25 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Frequently changing Namespace URIs cause market fragmentation

Key: DMN16-130
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
Currently, the version of DMN used in an DMN XML file is identified by the XML namespace URI, which is therefore changed with every revision. However, frequently changing namespace URIs cause market fragmentation across supported specification versions, as it cannot be assumed that all vendors update to the latest version of the spec at the same time, if at all.

This forces users to do unnecessary version migrations, or their models would be rejected by a tool as invalid or outdated even though language features used in the model may be perfectly supported by the tool. This issue has also been recognized by Specification Common Elements (SCE) in ~~SCE-117~~.

With DMN shipping bugfixes on a yearly pace, the fragmentation of the tool market increases, while the actual number of changes to the XML schema decreases. In fact, DMN 1.6 has zero changes to the XML schema at all but if it would follow the "tradition", it would again declare itself totally incompatible with DMN 1.5 and all prior versions.

DMN 1.x revisions have been following the backwards compatibility guidelines for machine-readable files and XML schemas as defined in the OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces (smsc/2018-08-01). Therefore, DMN 1.x revisions should not change the namespace URL until a version 2.0 introduces breaking changes, which is not planned at the moment.

The "tradition" to always change the namespace has somewhat accidentally grown:
- DMN 1.1 had to legitimately change the namespace because the XML serialization from DMN 1.0 was unimplementable and required breaking changes
- DMN 1.2 had to change the namespace because the one from DMN 1.1 did not conform to OMG's policy (due to last-minute bad advice from the technical director at the time)
- DMN 1.3 jumped on that to abuse it as a version indicator
- DMN 1.4 and DMN 1.5 followed to be "consistent with the scheme"
Reported: DMN 1.5b1 — Mon, 22 Apr 2024 19:36 GMT
Disposition: Deferred — DMN 1.6b1
Disposition Summary:
Defer to DMN 1.7

Defer to DMN 1.7
Updated: Mon, 16 Sep 2024 14:16 GMT

Wrong placement of useAlternativeInputDataShape attribute in the DMN specification document

Key: DMN16-215
Status: closed
Source: International Business Machines ( Mr. Tibor Zimanyi)
Summary:
There is a bug in the specification document (1) around the attribute useAlternativeInputDataShape. Looking into the approved proposal, that added the attribute here (2), it is approved to be added to DMNDiagram. In the XSD it is correctly in the DMNDiagram. However, when you check the document, it is part of the DMNShape definition (see 13.4.5 DMNShape [Class]).

(1) https://www.omg.org/spec/DMN/1.5/Beta1/PDF
(2) https://issues.omg.org/browse/DMN15-117
Reported: DMN 1.5b1 — Mon, 20 May 2024 11:24 GMT
Disposition: Deferred — $issue.fixedSpecification.name
Disposition Summary:
This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force
Updated: Fri, 21 Jun 2024 17:56 GMT

DecisionRule, InputClause & OutputClause should have ID and label for referencing in execution logs

Key: DMN11-26
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
If a DMN engine wants to provide a history of executed rules and clauses it needs to be able to reference them explicitly and have a human-readable label for them.
Reported: DMN 1.0 — Mon, 9 Mar 2015 19:37 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Add ID & label attributes by inheriting DMNElement

Spec text, MM and XSD should be changed to...

1. Let DecisionRule, InputClause and OutputClause inherit DMNElement.
2. Add an attribute label to DMNElement
Updated: Tue, 30 Apr 2024 23:19 GMT
Attachments:
- DMN11-154-Proposal.png 82 kB (image/png)
- Fig15_DMNElement_proposal.png 44 kB (image/png)
- Fig17_Decision_proposal.png 76 kB (image/png)
- Fig18_BusinessContext_proposal.png 35 kB (image/png)
- Fig19_BusinessKnowledgeModel_proposal.png 36 kB (image/png)
- Fig20_InputData_proposal.png 24 kB (image/png)
- Fig21_KnowledgeSource_proposal.PNG 37 kB ()
- Fig26_Expression_proposal.png 74 kB (image/png)
- Fig44_DecisionTable_proposal.png 82 kB (image/png)
- Fig60_All_Expressions_proposal.PNG 38 kB ()
- Table27.png 51 kB (image/png)

DRD elements must be labeled with their name

Key: DMN12-133
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
section 6.2.1.1 allows elements such as decisions to be labeled with add'l attributes, and does not actually require a label at all. This is unnecessarily general and may cause problems for DI and for using multiple occurrences to avoid line crossings.
Reported: DMN 1.1 — Thu, 9 Feb 2017 16:36 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
~~DMN12-62~~ removes other attributes than the name from diagrams

~~DMN12-62~~ already contains a text proposal that removes other attributes than the name (or a pretty-printed version of that) from diagrams
Updated: Tue, 30 Apr 2024 23:19 GMT

Label versus name attribute

Key: DMN12-89
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Most element inherit DMNElement which includes a label.
Some elements extends NamedElement that extends DMNElement and adds a required name to it.

Some text should be added to the specification to determine how those two attributes should be used.
For example, what should be depicted on a Decision in the diagram?
It’s name or its label?
Is that label really required on all elements?
(please note that a label may contain ctrl char like carriage return where I presume the name would not)

NB (This issue also relate to the upcoming Diagram Interchange (DI) capability coming)
Reported: DMN 1.1 — Fri, 26 Aug 2016 18:40 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Clarify role of label

1. Clearly define that the name attribute is displayed in the notation
2. Explain label attributes purpose as an alternative short description and that it is not displayed and not to be confused with names, which are used for referencing
3. Should not be used on elements that already have a name
Updated: Tue, 30 Apr 2024 23:18 GMT

New Namespace URIs needed

Key: DMN15-159
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
For tools to clearly identify the version of a DMN file or FEEL expression, the XML namespaces of DMN, DMN DI, and FEEL should be updated.

Namespace URIs must be backwards compatible with the scheme applied in previous versions for tools that support multiple versions in parallel. See:
DI and DC namespaces can stay the same as DMN 1.4 DI is still based on the same DI 1.1 specification and "OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces in OMG Specifications", states explicitly:

Note: if a spec has many machine readable files, and only some of them change at a given specification version, then only the changed files should get new URIs. That could mean a mixture of URI date segment values for a given specification version..
Reported: DMN 1.4b1 — Tue, 14 Feb 2023 16:15 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Update Namespace URIs for DMN 1.5

Update namespace URIs with the following values:

XSD: https://www.omg.org/spec/DMN/20230324/MODEL/
XSD DI: https://www.omg.org/spec/DMN/20230324/DMNDI/
FEEL: https://www.omg.org/spec/DMN/20230324/FEEL/
XMI: https://www.omg.org/spec/DMN/20230324/DMN15.xmi
XMI DI: https://www.omg.org/spec/DMN/20230324/DMNDI15.xmi

All URIs conform with the OMG Policy for Specification URIs and Namespaces (smsc/2018-08-01) and are backwards-compatible with the namespace scheme applied in DMN 1.2, 1.3, and 1.4, which is important for vendors supporting multiple versions in parallel.
Updated: Fri, 26 Apr 2024 23:37 GMT

Incorrect typeRef for variables associated to BKMs

Key: DMN15-74
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The typeRef attribute in the variable attribute of Business Knowledge Models in file 'Chapter 11 Example.dmn' from the examples archive is incorrect. The values references the output type (e.g. an item definition) and not a function item (introduced in DMN 1.3).

According to DMN 1.3 (Table 14, page 57), the semantic of variable attribute is:

This attribute defines a variable that is bound to the
function defined by the FunctionDefinition, allowing
decision logic to invoke the function by name.

Hence, the typeRef attribute has to reference a FunctionItem, Any or no type at all.

The issue was reported initially by Daniel Thanner in the TCK group (https://github.com/dmn-tck/tck/issues/376) and lead to the introduction of FunctionItems.

Proposal:

There are 3 ways to address this:
1. Remove typeRef from variables in BKMs
2. Change value to Any
3. Create FunctionItems for every BKM in the dmn file and reference them
Reported: DMN 1.3 — Mon, 14 Dec 2020 18:07 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Remove typeRef from variable of BKMs

Remove typeRef from BKM variables but keep it on their encapsulatedLogic in 9 places
Updated: Mon, 22 Apr 2024 16:23 GMT

Acknowledgements for DMN 1.4 and 1.5 contributors needed

Key: DMN15-104
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
Section "4.1 Acknowledgements" is missing paragraphs to acknowledge the DMN 1.4 and 1.5 contributors, especially since some people left the task force.
Reported: DMN 1.4b1 — Tue, 24 May 2022 17:46 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Add acknowledgements for DMN 1.4 and 1.5 contributors

Add paragraphs to acknowledge the DMN 1.4 and 1.5 contributors to section "4.1 Acknowledgements" based on
taskforce membership in 1.4 and 1.5
Updated: Fri, 30 Jun 2023 20:31 GMT

Superfluous spaces after "1"

Key: DMN15-155
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
Section 10.3 contains a number of instances where a space has appeared after the numeral 1. Sometimes this makes the syntax incorrect.
Reported: DMN 1.4 — Tue, 14 Feb 2023 10:11 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Remove superfluous spaces after "1"

Replace "1 " with "1".
Updated: Fri, 30 Jun 2023 20:31 GMT

Copyright section needs update

Key: DMN15-157
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
The copyright section needs to be updated.
Reported: DMN 1.4b1 — Tue, 14 Feb 2023 11:51 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Update copyright section

Update the years of contribution based on OMG-recognized contributors and taskforce membership. See also ~~DMN13-242~~
Updated: Fri, 30 Jun 2023 20:31 GMT

Multiple empty imports using the order as a precedence is not allowed

Key: DMN15-153
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
The specification is not clear in section 6.3.3 if multiple imports into the default namespace are allowed and how the import precedence is managed.
Reported: DMN 1.4b1 — Tue, 31 Jan 2023 22:18 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Allow multiple empty imports using the order as a precedence.

As discussed for the proposal ~~DMN15-140~~, allow multiple empty imports using the order as a precedence
Updated: Fri, 30 Jun 2023 20:31 GMT

Incorrect function name in example

Key: DMN15-119
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
There are 2 typos in the examples

duraion("P0DT25H") and duraion("P0Y13M"))

Should be

duration("P0DT25H") and duraton("P0Y13M"))
Reported: DMN 1.4b1 — Tue, 11 Oct 2022 08:37 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Fix spelling of the word 'duration'

Fix spelling of the word 'duration' in two places
Updated: Fri, 30 Jun 2023 20:31 GMT

Typo in Table 66

Key: DMN15-118
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
With reference to DMN v1.4 dtc-21-12-01 pdf
Table 66 list all the properties for duration FEEL value type, the property hours (plural) is inadvertently spelled with the capital H, but it should be lower case hours
Reported: DMN 1.4b1 — Mon, 10 Oct 2022 14:17 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Change 'Hours' to 'hours'

Change the cell reading Hours with capital H to lowercase h
so that all cells in the leftmost column are in lowercase.
Updated: Fri, 30 Jun 2023 20:31 GMT

Typos in meta model

Key: DMN15-56
Status: closed
Source: Camunda GmbH ( Maciej Barelkowski)
Summary:
There are several typos in the meta model that implementers using the XMI files have to patch in their tools in order to match the XML schemas:

1. In the DMNDI13.xmi:
<packagedElement xmi:type="uml:Class" xmi:id="_18_1_f7a0369_1441612964861_428140_5975" name="DC::Style" isAbstract="true"/>
The class cannot refer to dc:Style as such class does not exist. The XSD refers to di:Style. (see also: https://github.com/omg-dmn-taskforce/omg-dmn-spec/pull/8/files)

2. In DMN14.xmi:
<ownedAttribute xmi:type="uml:Property" xmi:id="_17_0_3_1_42401a5_1375643571589_681805_3414" name="input
"
Attribute name includes an encoded newline character (`\n`) which is not present in the XSD. (see also: https://github.com/omg-dmn-taskforce/omg-dmn-spec/pull/7/files)

3. In DMN14.xmi the default value contains encoded special characters:
<defaultValue xmi:type="uml:LiteralString" xmi:id="_17_0_2_3_ea50349_1446150762540_477393_4060" value=""text/plain""/>
(see also: https://github.com/omg-dmn-taskforce/omg-dmn-spec/pull/7/files)

4. There is a typo in the contextEntry property of dmn:Context:
<packagedElement xmi:type="uml:Class" name="Context" ...> ... <ownedAttribute xmi:type="uml:Property" name="contextEnrty"...> ... </ownedAttribute> </packagedElement>
See https://github.com/omg-dmn-taskforce/omg-dmn-spec/tree/v1.3/xmi/DMN13.xmi#L1533
(see also: https://github.com/omg-dmn-taskforce/omg-dmn-spec/issues/12)

5. Waypoints property has different names in XMI (wayPoints) and XSD (waypoint)
(see also: https://github.com/omg-dmn-taskforce/omg-dmn-spec/issues/11)

6. Missing property "id" in the DC::Style aka DI::Style
(see also: https://github.com/omg-dmn-taskforce/omg-dmn-spec/issues/10)

7. Wrong packageURI for DMNDI in DMN semantic meta model
Reported: DMN 1.2 — Thu, 19 Dec 2019 13:19 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Fix meta model typos

Fix several typos in meta model (XMI) that are not consistent with the XML schema (XSD).
Updated: Fri, 30 Jun 2023 20:31 GMT
Attachments:
- Class_Diagram__DMN_Edge.svg 79 kB (image/svg+xml)
- Class_Diagram__DMN_Style.svg 198 kB (image/svg+xml)
- Class_Diagram__DMN__ExpressionsL3.svg 228 kB (image/svg+xml)

Precision on Allowed Values UnaryTests

Key: DMN15-135
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
DMN ItemDefinitions metamodel (section 7.3.3) specifies that and ItemDefinition can restrict its typeRef by using an allowedValues attribute that is defined as a UnaryTests:

An ItemDefinition element may restrict the values that are allowed from typeRef, using the allowedValues attribute. The allowedValues are an instance of unaryTests that specifies the allowed values or ranges of allowed values within the domain of the typeRef. The type of the allowed values SHALL be consistent with the containing ItemDefinition element. If an ItemDefinition element contains one or more allowedValues, the allowedValues specifies the complete range of values that this ItemDefinition represents. If an ItemDefinition element does not contain allowedValues, its range of allowed values is the full range of the referenced typeRef. In cases where the values that an ItemDefinition element represents are collections of values in the allowed range, the multiplicity can be projected into the attribute isCollection. The default value for this attribute is false.

This paragraph has a few contradictions with the spec:
- The last phrase is not clear about which attribute defaults to false, this whole paragraph talks about allowedValues and the intention must be that it refers to isCollection but that certainly confused us.
- The attribute allowedValues is a UnaryTests but its usage is not consistent with its usage in decision tables inputEntry. A UnaryTests is defined as an expression that evaluates to a boolean with an implicit argument to be tested (from its definition in section 7.3.2). However, this is not the way it is used here. Here it defines a range/enumeration of allowedValues and not an expression that is evaluated with an implicit argument.
  Our proposal would be to align the usage of UnaryTests with decision table inputs.
  This would allow extended use cases such as:
- A validation of an email address domain: allowedValues => ends with(?, “@trisotech.com”)
- Validation that depends on sibling variables values: allowedValues => if OrderType = “Type A” then [“a”,”b”,”c”] else [“c”, “d”, “e”]
- Or something even simpler like not null: allowedValues => ? != null
- Length check on strings: allowedValues => string length(?) > 10
Reported: DMN 1.4b1 — Fri, 2 Dec 2022 14:13 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Align the usage of UnaryTests with decision table inputs

Align the usage of UnaryTests with decision table inputs

UnaryTests and FEEL have become so powerful that the projection of allowedValues onto collection elements is not required any more.

XSD and Meta Model change on Figure 7-7: ItemDefintion class diagram, add a composition between ItemDefinition and UnaryTests with the cardinality 0..1 on both sides named typeConstraint. (same as allowedValues): https://github.com/omg-dmn-taskforce/omg-dmn-spec/pull/27/files
Updated: Fri, 30 Jun 2023 20:31 GMT
Attachments:
- Class_Diagram__DMN__ItemDefinition.svg 164 kB (image/svg+xml)

spec places unrealistic constraints on decision expressions and BKM parameter bindings

Key: DMN15-65
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
Section 7.1 specifies that under certain circumstances relating to BKMs a decision must have a literal expression, and BKM parameter bindings relate to decision inputs. For example:

"If a decision element requires more than one business knowledge element, its value expression must be a literal expression that specifies how the business knowledge model elements are invoked and how their results are combined into the decision's outcome."

So, in essence dictating that if a decision uses more than 1 BKM its expression must be a literal expression. In practice, a decision may use its BKMs in various ways - to populate a boxed context entry, or even not to invoke it at all and (say) pass the BKM to another BKMN or function accepting as function type parameter.

This statement should be removed from the spec.

Next: "If a decision does not require any business knowledge models, its value expression must be a literal expression or decision table that specifies the entire decision logic for deriving the output from the inputs."

Again, whether a decision uses a BKM or not has no bearing on the type of expression a decision has. A decision with no BKM may have any expression including (say) a boxed context, or a list, or indeed may return a function definition - not just a literal expression or a decision table . The above text should be removed from the spec.

Next: "Similarly, if a decision element requires only one business knowledge model element, but the logic of the decision elaborates on the logic of its required business knowledge model, the decision element must have a literal expression that specifies how the business knowledge model's value expression is invoked, and how its result is elaborated to provide the decision's outcome."

The same - this text should be removed from the spec.

Next: "In all other cases (i.e., when a decision requires exactly one business knowledge model and does not elaborate the logic), the value expression of a decision element may be a value expression of type invocation. In a value expression of type invocation, only the bindings of the business knowledge model parameters to the decisions input data need be specified: the outcome of the decision is the result returned by the business knowledge model's value expression for the values passed to its parameters."

Again, this is unnecessarily limiting how a decision may use a BKM. For example, a decision may actually return the BKM as its value. The above text should be removed from the spec.

Additionally, the following should be removed:

"At the decision logic level, a decision invokes a required business knowledge model by evaluating the business knowledge model's value expression with the parameters bound to its own input value. How this may be achieved depends on how the decision logic is partitioned between the decision and business knowledge models:"

A decision does not have to bind its input values to a BKM parameters. As a decision may have (say) contexts that evaluate in a top down manner and the binding to a BKMs parameters could be any manner of calculations in that context or results of other BKM invocations that do not strictly relate to the inputs of a decision.
Reported: DMN 1.3 — Fri, 19 Feb 2021 10:01 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Remove part of section that is erroneous

Delete part of section 7.1 that is erroneous on page 60 (PDF 66)
Updated: Fri, 30 Jun 2023 20:31 GMT

Clarification regarding equivalence of date vs date and time

Key: DMN15-44
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Section 10.3.2.3.5 date contains the following:

Where necessary, including the valuedt function (see 10.3.2.3.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00).

Is not obvious when the equaivalence should be applied.

One option is to add an implicit conversion, similar to the ones for singleton lists.
Reported: DMN 1.2 — Sun, 2 Jun 2019 13:01 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Clarify equivalence between date and date and time instances

Clarify equivalence between date and date and time instances
Updated: Fri, 30 Jun 2023 20:31 GMT

Depiction of Input Data is not harmonized with BPMN and CMMN

Key: DMN15-6
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
As OMG promotes the integrated use of DMN with BPMN and CMMN, it is proposed to change the depiction of Input in DMN to be the paper Shape with folded corner. We can envision end users wanting to embed DMN diagrams into BPMN or CMMN diagrams. This change would provide better notational alignment with Data Object and Case File Iems in BPMN and CMMN. Futhermore is would remove the notation conflict currently existing between DMN Input and CMMN Milestone.

Idea:
The classical Input Data symbol (oval) remains the default representation for backwards compatibility and is used in all examples throughout the DMN 1.5 standard. Only Tables 1 and 103, where the symbol for the Input Data is presented, the alternative representation is introduced.
Reported: DMN 1.1 — Mon, 16 May 2016 14:26 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Allow alternative representation of DMN Input Data using BPMN Data Object / CMMN Case File Item symbol

The classical Input Data symbol (oval) remains the default representation for backwards compatibility and is used in all examples throughout the DMN 1.5 standard. Only Tables 1 and 103, where the symbol for the Input Data is presented, the alternative representation is introduced.

For diagram interchange, a new property "useAlternativeInputDataShape" is added to the DMNDiagram class.

XSD & MM changes: https://github.com/omg-dmn-taskforce/omg-dmn-spec/pull/25/files
Updated: Fri, 30 Jun 2023 20:31 GMT
Attachments:
- BPMN Data Object DMN Data Input.PNG 86 kB ()
- CaseFileItem.png 0.9 kB (image/png)
- Class_Diagram__DMN_Diagram.svg 164 kB (image/svg+xml)
- Depiction of Input Data conflict with BPMN and CMMN.png 239 kB (image/png)
- InputOval.gif 3 kB (image/gif)
- Input_Data_Object.gif 1.0 kB (image/gif)
- Milestone.png 2 kB (image/png)
- bpmn-figure-087.Data Object Reference.png 0.9 kB (image/png)
- bpmn-figure-088.Data Object Reference Collection.png 0.9 kB (image/png)
- bpmn-figure-089.Data Input.png 1 kB (image/png)
- bpmn-figure-090.Data Input Collection.png 1 kB (image/png)
- bpmn-figure-091.Data Output.png 1 kB (image/png)
- bpmn-figure-092.Data Output Collection.png 1 kB (image/png)

It is not possible to use a range of Dates as an iteration context

Key: DMN15-121
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
FEEL for iteration statement context limits the iteration context (Section of 10.3.2.14 ) to integers:
"An iteration context may either be an expression that returns a list of elements, or two expressions that return integers connected by “..”. "

It would be useful to augment the iteration context to also allow dates.

This will allow to create simple decision logic that validates conditions for each date in the range and allows one to write decision logic that can validate the state on each day to calculate the number of days that meet a requirement.

An general example use case could be, how many days in the range [2021-01-01..2022-01-01] meets a certain complex logic.

A specific example of that would be to determine if the person and its spouse were both employed and living at the same address for at least the 3 of the last 5 years given a list of Job description for both (Date From, Date To, Employer) and a list of their declared residence for both (Date From, Date To, Address).

This can of course be calculated in a different way, but the logic of iterating on a date range and checking if the condition is true for every day and summing the number of days for which its true makes the logic a lot simpler to follow for a business user.
Reported: DMN 1.4b1 — Tue, 18 Oct 2022 18:39 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Add date range to iteration context

Explicitly allow date ranges and add @”2021-01-01”..@”2022-01-01” to the list of examples in section 10.3.2.14.
Updated: Fri, 30 Jun 2023 20:31 GMT

Missing FEEL function to replace items in a list

Key: DMN15-143
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
There are currently FEEL functions to manipulate lists content: append, sublist, concatenate, insert before, remove, union, distinct values and flatten but it does not define a function to replace item(s) from a list.

Our proposal is to introduce a new list replace function.
Reported: DMN 1.4b1 — Tue, 17 Jan 2023 02:33 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Add a new list replace FEEL function

Introduce a new FEEL function called list replace that allows to replace one or more elements in a list with a new value based on the list position or a matching function.
Updated: Fri, 30 Jun 2023 20:31 GMT

Lists and filters section does not provide a dot accessor "." example with null

Key: DMN15-125
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
The current para (below) does not provide an example with null which could lead to misinterpretations.

For convenience, a selection using the "." operator with a list of contexts on its left hand side returns a list of
selections, i.e. FEEL(e.f, c) = [ FEEL(f, c'), FEEL(f, c"), ... ] where FEEL(e) = [ e', e", ... ] and c' is c augmented with
the context entries of e', c" is c augmented with the context entries of e", etc. For example,
[ {x:1, y:2}, {x:2, y:3} ].y = [2,3]
Reported: DMN 1.4b1 — Fri, 21 Oct 2022 14:43 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Add an example using null to the Lists and filters section

In section 10.3.2.5 add an example
Updated: Fri, 30 Jun 2023 20:31 GMT

Improvement of Semantic Domains Specification

Key: DMN15-27
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The definition of Semantic Domains / Types in 10.3.2 does not contain:
- a metamodel
- relationships between various types
I propose adding a metamodel and the following two relationship:

1. Conforms To
A semantic domain T1 conforms to a semantic domain T2 when an instance of T1 can be substituted at each place where an instance of T2 is expected.

2. Equivalent To
A semantic domain T1 is equivalent to a domain T2 iff they have the same name and the corresponding embedded semantic domains are equivalent. (e.g. List<Number> is equivalent only to List<Number> not List <String>).

The above relationships should be defined via tables, similar to the ones used to describe the semantics of logic operators (page 119 Table 38).
Reported: DMN 1.1 — Thu, 30 Mar 2017 12:38 GMT
Disposition: Closed; No Change — DMN 1.5
Disposition Summary:
Resolved already

Resolved in an earlier version already when we introduced the type lattice.
Updated: Fri, 30 Jun 2023 20:31 GMT
Attachments:
- argo-dmn-types.png 15 kB (image/png)

data equivalence with date and time

Key: DMN15-42
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Section 10.3.2.3.5 contains the following:

Where necessary, including the valuedt function (see 10.3.2.3.6), a date value is considered to be equivalent to a date time
value in which the time of day is UTC midnight (00:00:00).

It is not very clear where this equivalence is going to be applied.

The proposal is to specify the above in a more precise manner, possibly as an implicit conversion.
Reported: DMN 1.2 — Mon, 27 May 2019 08:30 GMT
Disposition: Duplicate or Merged — DMN 1.5
Disposition Summary:
Duplicate of ~~DMN15-44~~

Duplicate of ~~DMN15-44~~
Updated: Fri, 30 Jun 2023 20:31 GMT

The "schemaLocation" relative URLs are broken

Key: DMN15-76
Status: closed
Source: Mayo Clinic ( Dr. Davide Sottara)
Summary:
In DMNDI13.xsd:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:dmndi="https://www.omg.org/spec/DMN/20191111/DMNDI/"
xmlns:dc="http://www.omg.org/spec/DMN/20180521/DC/"
xmlns:di="http://www.omg.org/spec/DMN/20180521/DI/"
targetNamespace="https://www.omg.org/spec/DMN/20191111/DMNDI/"
elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:import namespace="http://www.omg.org/spec/DMN/20180521/DC/"
schemaLocation="DC.xsd"/>
<xsd:import namespace="http://www.omg.org/spec/DMN/20180521/DI/"
schemaLocation="DI.xsd"/>

The schemaLocations for the DC/DI schemas that were introduced in DMN1.2 have not been upgraded to take into account the new URL for DMN 1.3
While the relative location worked for DMN 1.2 (v20180521), the relative URLs resolve to https://www.omg.org/spec/DMN/20191111/DC.xsd (resp DI.xsd)

This causes issues with tools such as IDEs and schema validators that try to resolve the URLs of the imports.
The schemaLocations should be updated to use full URLs
Reported: DMN 1.3 — Mon, 14 Sep 2020 22:04 GMT
Disposition: Closed; No Change — DMN 1.5
Disposition Summary:
Schema locations work when downloaded

The DMN XML Schema files are primarily designed to work when downloaded into the same folder. We have reached out to Jürgen to also place them in appropriate folders on the OMG web server.
Updated: Fri, 30 Jun 2023 20:31 GMT

Wording in section above does not match the rule 35 in grammar

Key: DMN15-120
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
After adding support for scientific notation (https://issues.omg.org/browse/DMN15-107), there are incorrect parts in section 10.3.2.3.1:

1. Literals consist of base 10 digits and an optional decimal point.
2. FEEL does not support a literal scientific notation. E.g., 1 .2e3 is not valid FEEL syntax. Use 1.2*10**3 instead.
Reported: DMN 1.4b1 — Tue, 11 Oct 2022 08:45 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Correct text about decimal numbers

Correct the statements about numbers to include scientific notation.
Updated: Fri, 30 Jun 2023 20:31 GMT

DMN 1.4 updated XMI references external file DMN14.mdxml

Key: DMN15-98
Status: closed
Source: Airbus Group ( Mr. Oliver M. Kellogg)

Summary:

The dtc/21-12-03 "DMN14.xmi updated" contains some references to a file DMN14.mdxml,

252:        <type href="DMN14.mdxml#_17_0_5_1_a250249_1518651646564_243499_3956"/>
655:        <type href="DMN14.mdxml#_17_0_2_3_ea50349_1435268843602_88699_2217"/>
656:        <association href="DMN14.mdxml#_17_0_2_3_ea50349_1435269041753_841899_2676"/>
666:        <type href="DMN14.mdxml#_17_0_2_3_ea50349_1435268832194_670602_2213"/>
667:        <association href="DMN14.mdxml#_17_0_2_3_ea50349_1435269293045_464837_2775"/>
677:        <type href="DMN14.mdxml#_17_0_2_3_ea50349_1435268824892_950814_2209"/>
678:        <association href="DMN14.mdxml#_17_0_2_3_ea50349_1435269539220_831013_2875"/>
2298:      <memberEnd href="DMN14.mdxml#_17_0_5_1_a250249_1518651855436_638563_4054"/>

Please check whether those references are intended and if so, please clarify where to obtain that file.

Reported: DMN 1.4 — Mon, 4 Apr 2022 21:56 GMT
Disposition: Closed; No Change — DMN 1.5
Disposition Summary:
No external references any more

The latest XMI file does not have such references.
Updated: Fri, 30 Jun 2023 20:31 GMT

No way to represent a black-box or incompletely defined Decision Service

Key: DMN15-36
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
As DMN gets used to produce publicly available decision services we will need some way to represent a decision service that the modeler cannot see into. They know its a side-effect free, stateless decision service and know its signature so they can add a decision to their own model that is implemented by it but they don't know what decisions, BKMs, knowledge sources etc. were used to produce it. There is currently no way to do this - a decision service can be shown collapsed but only if the model "knows" what the expanded version looks like. It feels like it would be useful to do so.
Reported: DMN 1.2 — Thu, 27 Sep 2018 01:04 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT
Attachments:
- DRD of Loan Info Service (Black Box).png 26 kB (image/png)
- DRD of Loan Info Service (Black Box).xcf 69 kB ()
- Figure 11.41 DRD of imported Loan Info Service (Black Box).png 31 kB (image/png)
- Figure 11.41 DRD of imported Loan Info Service.png 27 kB (image/png)
- Figure 11.41 DRD of imported Loan Info Service.xcf 61 kB ()
- grey-box-decision-service-sketch.png 73 kB (image/png)

Misprint in

Key: DMN15-142
Status: closed
Source: AMBESAS ( Thierry BIARD)
Summary:
In this couple of chapters, "duration" is written "duraion" (without "t" - 2 occurrences)
Reported: DMN 1.4b1 — Sun, 18 Dec 2022 11:12 GMT
Disposition: Duplicate or Merged — DMN 1.5
Disposition Summary:
Duplicate of ~~DMN15-119~~

Fixed in ~~DMN15-128~~
Updated: Fri, 30 Jun 2023 20:31 GMT

Typo - "duraion"

Key: DMN15-149
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
Sections 10.3.2.3.7 and 10.3.2.3.8 have "duraion" instead of "duration"
Reported: DMN 1.4 — Wed, 18 Jan 2023 12:32 GMT
Disposition: Duplicate or Merged — DMN 1.5
Disposition Summary:
Fixed in another issue

Fixed already in ~~DMN15-128~~
Updated: Fri, 30 Jun 2023 20:31 GMT

Clean up example xml files

Key: DMN15-45
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Sample xml files have Trisotech extension elements. These should be removed prior to publication.
Reported: DMN 1.2b1 — Tue, 28 May 2019 16:52 GMT
Disposition: Closed; No Change — DMN 1.5
Disposition Summary:
The examples don't contain extensions

The issue seems to be fixed
Updated: Fri, 30 Jun 2023 20:31 GMT

Positive unary tests lack equality operators

Key: DMN15-108
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Currently the positive unary tests support all relational operators but not the equality operators (= !=). We should support them for consistency. For example, all the above operators are supported in comparison expressions (rule 49).

Business analysts have reported that they would like to have a consistent and more readable way to write rules and test cases with many comparison operators.
Reported: DMN 1.4b1 — Tue, 31 May 2022 08:40 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Extend positive unary tests with equality operators

Extend positive unary tests with equality operators
Updated: Fri, 30 Jun 2023 20:31 GMT

UNused Requirements are considered invalid

Key: DMN15-88
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
Executive summary: by the way the DMN specification stands, the description that Requirements SHALL (== "MUST") be referenced in the expression will nullify any CL1 DMN model and any DMN model not using FEEL, as not-conformant.

In section 7.3.4 InformationItem metamodel we read:

A variable representing an instance of Decision or InputData referenced by an InformationRequirement SHALL be referenced by the value expression of the decision logic in the Decision element that contains the InformationRequirement element. A parameter in an instance of BusinessKnowledgeModel SHALL be a variable in the value expression of that BusinessKnowledgeModel element.

By side effect of this strict mandate in the specification, it is like saying an UNused requirement will fail conformance.

Example: a decision enlist A, B, C as Requirements, but in the formula we use only A and B. According to the current spec, this makes the model failing conformance and invalid.

Granted, it is always a best practice not only for BA but also for developers to avoid "unused requirements/variable"!
But here is giving a strict mandate.

Further, any DMN model which does not use FEEL "only DRG" automatically fail this constraint which is in Chapter 7.

The DMN specification should follow best-practices of Modeling AND programming languages, where is NOT a blocking issue to have "unused requirements/variables", but of course warn when those are detected; this can be easily achieved by switching SHALL to SHOULD in the identified paragraphs in chapter 7.1 and 7.3.4 per proposal.

This issue was detected in the TCK group (ref https://github.com/dmn-tck/tck/issues/487 )
Reported: DMN 1.4 — Sun, 27 Feb 2022 20:45 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Requirements SHOULD be referenced

change text in Chapter 7.1 and 7.3.4 according to the below instructions
Updated: Fri, 30 Jun 2023 20:31 GMT

Underspecified when ranges may include a qualified name for the endpoint, which resolves to null

Key: DMN15-78
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
It is underspecified when the ranges may include a qualified name for the endpoint, which resolves to null.

This was identified by Greg McCreath and Octavian Patrascoiu during TCK contributions.

Ranges' Endpoints can be either a literal or a qualified name. If the qualified name resolves to null, and the endpoint inclusivity flag is false, it is semantically equivalent to the case of single-endpoint-range. This leads to ambiguity in Table 55: Semantics of decision table syntax

This also requires the typo fix in https://issues.omg.org/browse/INBOX-1337

Example

With reference to examples in Table 42: Examples of range properties values

Instead of (1..10]
do consider (x..10]
if x resolves to null
then this is semantically equivalent to <=10.

However, Table 55, row 9, cites:
e1 in (e2..e3] is equivalent to e1 > e2 and e1<=e3 // exercise by hand.. e1 in (x..10] is equivalent to e1 > x and e1<=10 // if x resolves to null.. e1 in (null..10] is equivalent to e1 > null and e1<=10 e1 > null and e1<=10
which is NOT equivalent to e1<=10, hence the ambiguity.
Reported: DMN 1.3 — Sun, 5 Sep 2021 07:18 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Clarify edge cases and range options

Clarify that ranges are defined based on a combination of comparison and conjunction operators and therefore the result of an comparison with a range containing a null endpoint will be either false or null but never true.

Add text to the description of the range that mentions the possibility of using expressions.
Updated: Fri, 30 Jun 2023 20:31 GMT

No built-in function to support Range conversion

Key: DMN15-99
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
Current DMN Specification v1.4 does not define a Built-in function to support Range conversion.

This capability can be useful in other use-cases beyond conversion itself. For example, but not limiting to: the need to have FEEL:range as an input of the model, the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services, etc.
Reported: DMN 1.4 — Wed, 13 Apr 2022 13:07 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Add Built-in function to support Range conversion

Adds a new FEEL built-in function in Chapter 10.3.4.1 Conversion functions, to support Range conversion
Updated: Fri, 30 Jun 2023 20:31 GMT
Attachments:
- Screenshot 2022-04-13 at 15.16.18.png 300 kB (image/png)

Table 62 limited to "negative numbers"

Key: DMN15-86
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
In 10.3.2.15 Semantic mappings,
Table 62: Semantics of negative numbers

per its description is limiting to negative numbers, but by Table 59 it's possible to multiply a duration (years and months duration, days and time duration) by a number.

Hence, it's already possible to do
duration("PT1H")*-1
but formally is not allowed to do
-duration("PT1H")
It should be easier to widen the semantic of Table 62 to negate numbers AND duration to allow the second case.

This was identified in the TCK group, ref https://github.com/dmn-tck/tck/issues/482
Reported: DMN 1.4 — Sun, 27 Feb 2022 20:23 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Widen semantic of Table 62 to cover FEEL semantic

Change of text for semantic of Table 62
Updated: Fri, 30 Jun 2023 20:31 GMT

Typo in "10.3.1.2 Grammar rules" 3rd bulletpoint in the bottom

Key: DMN15-94
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
With reference to DMNv1.4 dtc-21-12-01,
section "10.3.1.2 Grammar rules",
page 104 (PDF 120)
the 3rd bulletpoint in the bottom is referring to the wrong grammar rule number.

This is likely a typo originating from the need of additional grammar rules being added in previous version of the Spec.

This can be trivially fixed editorially, with the associated proposal.
Reported: DMN 1.4 — Thu, 17 Mar 2022 17:22 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Fix 3rd bulletpoint rule reference in "10.3.1.2 Grammar rules"

Update the grammar rule reference and provide more context.
Updated: Fri, 30 Jun 2023 20:31 GMT

No support for numbers in scientific notation

Key: DMN15-107
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Currently the syntax of numeric literals does not support usage of exponents. This is quite useful when dealing with large numbers.
Reported: DMN 1.4b1 — Tue, 31 May 2022 07:59 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Support numbers in scientific notation

Extend grammar to support numbers in scientific notation
Updated: Fri, 30 Jun 2023 20:31 GMT

Allowed Values for collection item definitions

Key: DMN15-137
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
DMN ItemDefinitions metamodel (section 7.3.3) specifies that the allowedValues of a collection attribute are projected to its elements which prevents us from constraining collections.

For example:
- The collection size needs to be between 1-5 elements
- The collection can’t contain duplicates
Our proposal is to add an additional attribute to ItemDefinition named collectionAllowedValues to capture these constraints.
Reported: DMN 1.4b1 — Fri, 2 Dec 2022 14:23 GMT
Disposition: Duplicate or Merged — DMN 1.5
Disposition Summary:
Proposal merged into ~~DMN15-136~~

Proposal merged into ~~DMN15-136~~
Updated: Fri, 30 Jun 2023 20:31 GMT

Another False, or at least ignored statement by most vendors

Key: DMN15-131
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
This statement was brought to my attention via DMN TCK email:

"If a decision element requires more than one business knowledge element, its value expression must be a literal expression that specifies how the business knowledge model elements are invoked and how their results are combined into the decision's outcome. "

This statement is either false or ignored by most vendors
Reported: DMN 1.4b1 — Wed, 30 Nov 2022 17:58 GMT
Disposition: Duplicate or Merged — DMN 1.5
Disposition Summary:
Duplicate of previous issue

Duplicate of previous issue
Updated: Fri, 30 Jun 2023 20:31 GMT

False, or at least ignored statement by most if not all vendors

Key: DMN15-130
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
This statement was brought to my attention via DMN TCK email:

"If a decision does not require any business knowledge models, its value expression must be a literal expression or decision table that specifies the entire decision logic for deriving the output from the inputs."

This statement is either false or ignored by most vendors
Reported: DMN 1.4b1 — Wed, 30 Nov 2022 17:55 GMT
Disposition: Duplicate or Merged — DMN 1.5
Disposition Summary:
Duplicate of previous issue

Duplicate of previous issue
Updated: Fri, 30 Jun 2023 20:31 GMT

Clarification needed if null is passed as value for optional parameter of built in function

Key: DMN15-13
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Some built-in functions has optional parameters. Chapter 10.3.4 describes "Whenever a parameter is outside its domain, the result of the built-in is null."

Should the following call to a built-in function result to null?
replace("This is a string", "[a-z]", "#", null)
The optional parameter "flags" of the built-in function replace() is null. Parameter domain is string as stated in table 60 on page 133. Null is not in the domain of type string.

This topic was already discussed in the DMN TCK. We think that the behavior should be the same as the function is called without the optional parameter:
replace("This is a string", "[a-z]", "#", null) = replace("This is a string", "[a-z]", "#")
Clarification in the specification is appreciated.

May be we can change the sentence in chapter 10.3.4 on page 130 to: "Whenever a parameter is outside its domain, the result of the built-in is null. If null is passed as value to an optional parameter, the built-in behaves like no value is passed."
Reported: DMN 1.1 — Tue, 10 Oct 2017 14:32 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration

Key: DMN15-12
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Chapter 10.3.2.3.4 time, 10.3.2.3.5 date, 10.3.2.3.6 date-time, 10.3.2.3.7 days and time duration and chapter 10.3.2.3.8 years and months duration defines each a value function. For date time arithmetic operations it would be useful to have this value available in the FEEL semantic domain. Therefore we suggest to add a new property value that is directly available for values of this type. Return type of the value if always a number.

Table 53 should be adjusted accordingly.
Reported: DMN 1.1 — Tue, 10 Oct 2017 09:57 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Business Knowledge Model can have Information Requirements

Key: DMN15-4
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
FEEL function definitions are defined as lexical closures, which simply means that names in the function body must be in scope, and that scope includes the function parameters and, just like any other decision logic, it includes the information requirements and the knowledge requirements. This is very handy. For example, it allows the logic of a BKM to reference 100 Input Data items by name, without requiring that each invocation pass in 100 parameter bindings.

In order for this to work, the BKM would model 100 Information Requirements on the 100 Input Data items, instead of modeling them as parameters. The boxed invocations would not have 100 rows of repetitive binding information. We must extend the MM and Table 2 to allow a BKM to have information requirements.
Reported: DMN 1.0 — Thu, 23 Jul 2015 23:30 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

No notation for ItemDefinition

Key: DMN15-2
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The notion of a 'type' or ItemDefinition is in the metamodel (with some pending issues) and in the semantics and concepts, but little is in the notation. Thus, we have notation that allows you to execute an expression with actual arguments, but no notation to allow validation based on type information without actual values.

We have most of the pieces, so it should not be difficult. E.g., individual values can be number, string, date and time, etc. We can allow numeric ranges using our unary tests, e.g. '>0', '[10..30)', etc. We can allow LOVs using "abc", "def", "ghi". These can be 'simple items', and we can also define structures using something similar to boxed contexts.
Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

XSD: global context

Key: DMN15-5
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
10.3.2.9.2 says "The global context is a context provided for convenience and 'pre-compilation'. Any number of expressions can be named and represented in a FEEL context m. The syntactic description m of this context can be evaluated once, that is, mapped to the FEEL domain as m, and then re-used to evaluate many expressions." For example, you might want to put a Relation used as a multi-dimensional constant in the global context. Or you might want to put a reusable function definition in the global context. Currently the xsd does not have globals. All expressions are bound to a specific drgElement, not global. The Import element probably needs to be modified to support this also.
Reported: DMN 1.0 — Sun, 31 May 2015 16:35 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Include Test Cases in Decision Model

Key: DMN15-7
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
For interchange of test cases along with a decision model, it would be convenient to define metamodel and xsd elements for a suite of test cases, where a test case contains values for input data and expected values output decisions.
Reported: DMN 1.1 — Sat, 28 May 2016 16:25 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT
Attachments:
- testCases.xsd 3 kB (text/xml)

italics and bold used for both typographic literal notation and FEEL semantic exposition

Key: DMN15-3
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
in typographic literals, italics are strings and bold italics are date literals, but in 10.3, italics are feel syntactic elements and bold are semantic elements. Better to have different notations
Reported: DMN 1.0 — Thu, 3 Sep 2015 15:58 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Gaps: Range as input, mapping to JSON, evaluation of non-FEEL expression languages

Key: DMN15-96
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
Current DMN Specification v1.4 has a few gaps in the following areas:

1. Built-in function to support Range conversion
2. Mapping of FEEL to JSON
3. Evaluation of other expression language beyond FEEL

In addition to the above gaps, during conversations in the OMG DMN RTF group, and in other communities with DMN interests, SMEs and Vendors have reported on the missing capabilities for a complete, semantically well-defined and interoperable solution, connected to the mentioned cases. For example, but not limiting to: the need to have FEEL:range as an input of the model, the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services, etc.

The pragmatic aspects introduced in this proposal to cover the mentioned gaps above, could also be a meaningful foundational and propaedeutic work if the OMG DMN RTF group will want to pursue to eventually propose the DMN Specification to ISO, and/or the group will want to pursue to eventually refactor FEEL into its own stand-alone Specification.

Finally, the DMN Specification already provides recommendations in the Annex(es) for integrations, in the scope of BPMN, etc., for harmonised semantic and potential improved interoperability; the DMN Spec could also offer similar recommendations in the scope of gap 3 identified above.

This document advances pragmatic proposals that would both cover the existing gaps and provide the capabilities required to a well-defined and more interoperable solution.
Reported: DMN 1.4 — Fri, 25 Mar 2022 08:29 GMT
Disposition: Duplicate or Merged — DMN 1.5
Disposition Summary:
Issue has been split up

The relevant gaps are covered in the respective JIRAs ~~DMN15-99~~ and ~~DMN15-101~~
Updated: Fri, 30 Jun 2023 20:31 GMT

Typo in 6.3.7 Decision metamodel

Key: DMN15-83
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
In the chapter "6.3.7 Decision metamodel",
a reference is made to the fact a Decision's Name MUST be unique in the model, but there is likely a wrong copy-paste of a sentence from other section of the spec.

It currently reads as:

The name of an Invocable must be different from the name of any other invocable, input data, decision, or import in the decision model.

But a Decision is NOT an Invocable.

In the chapter "6.3.9 Business Knowledge Model metamodel" the same pharse is used and there is valid since a BKM is indeed an Invocable.

In the chapter "6.3.11 Input Data metamodel" the analogous phrase is correctly adapted, since it reads as:

The name of an InputData must be different from the name of any other decision, input data, business knowledge model, decision service, or import in the decision model.

Conclusion

Only in chapter chapter "6.3.7 Decision metamodel" the phrase is wrong as referring to "Invocable" when in fact it should have just used the term "Decision". The proposal will address this accordingly.
Reported: DMN 1.4 — Wed, 19 Jan 2022 12:58 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Address typo in 6.3.7 Decision metamodel instead of Invocable use proper term: Decision

In chapter "6.3.7 Decision metamodel", replace "Invocable" with "Decision" in the phrase:

The name of an Invocable must be different from the name of any other invocable, input data, decision, or import in the decision model.
Updated: Fri, 30 Jun 2023 20:31 GMT

Enumerations can only be defined as strings

Key: DMN15-18
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
Item Definitions can share constraints and these constraints are specified as unary tests. This allows definitions such as requiring a positive number ( >0) or restricting a field to a specific value ("high", "medium", "low").

However this requires enumerations to be strings and does not allow enumerations to be managed (sorted for instance). In addition, an enumerated list might be used for a set of Information Items but it must be repeated in Decision Tables when columns are meant to be restricted to the list of values.

DMN should allow for the creation and management of enumerations:
- Name
- Description (optional)
- List of enumerated values (optionally with a sort order)
These enumerations should be considered symbolic constants, not strings

FEEL functions should be created to:
Get the list of of allowed values for a specified enumeration
Check a value against an enumeration to see if it is an allowed value for that enumeration
Check the sort order of some specified values in the context of an enumeration

Decision Tables should be able to reference an enumeration by name in the value list row
Information Items should be able to be linked to an enumeration
Reported: DMN 1.1 — Thu, 26 Oct 2017 16:12 GMT
Disposition: Closed; Out Of Scope — DMN 1.5
Disposition Summary:
Not an issue in practice

It sounds like nobody is really affected by this.
Most users define a string item definition with a list of allowed values.
Developers sometimes expect to feed a Java enumeration into a string resulting in an error. But most users invoke decisions via JSON data, e.g. because of invocation via REST or JSON being the data model of a BPMN engine.
Updated: Fri, 30 Jun 2023 20:31 GMT

There are questions regarding precedence of operator between negation and exponation

Key: DMN15-109
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
in FEEL -4**2 = 16
Some may expect = -16
Reported: DMN 1.4 — Tue, 5 Jul 2022 17:03 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Add clarification about precedence

Add a warning about the different precedence and suggestions to avoid ambiguities
Updated: Fri, 30 Jun 2023 20:31 GMT

Typo in 8.3.1 Decision Table metamodel "DecsionTable"

Key: DMN15-81
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
In the paragraph of 8.3.1 Decision Table metamodel

DecisionTable inherits all the attributes and model associations from Expression. Table 32 presents the additional attributes and model associations of the DecsionTable element.
Reported: DMN 1.4 — Wed, 5 Jan 2022 08:48 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Fix typo "DecsionTable"

Fix typo
Updated: Fri, 30 Jun 2023 20:31 GMT

Business Context links go both ways

Key: DMN15-1
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In XSD, business context pointers are duplicated in both directions. E.g. decisionOwner and decisionMaker point to organizationalUnit, which in turns has pointers back the other way. This duplication adds no new information, just potential for internal inconsistency. I suggest omitting one of these directions; the other one is easily extracted from the serialization by XPATH.
Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Incorrect reference to FEEL rule

Key: DMN15-106
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
In the following bullet point:

In rule 62, the only permitted functions are the builtins date, time, date and time, and duration.

the correct reference is rule 60 where the date time literals are defined.
Reported: DMN 1.4b1 — Tue, 31 May 2022 07:56 GMT
Disposition: Duplicate or Merged — DMN 1.5
Disposition Summary:
Duplicate of ~~DMN15-94~~

Fixed in ~~DMN15-95~~
Updated: Fri, 30 Jun 2023 20:31 GMT

Typo in the DMN 1.4 XSD schema (complexType tFilter)

Key: DMN15-79
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
Typo of spurious trailing whitespace in the name of the complexType "tFilter " (notice the extra space at the end) make XSD validators to fail to validate the XML Schema itself.
Reported: DMN 1.4 — Mon, 3 Jan 2022 16:30 GMT
Disposition: Closed; No Change — DMN 1.5
Disposition Summary:
Close without change

Issue fixed already in DMN 1.4
Updated: Fri, 30 Jun 2023 20:31 GMT

Collect decision tables

Key: DMN15-31
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
(1) The spec says "Collect: returns all hits in arbitrary order. An operator (‘+’, ‘<’, ‘>’, ‘#’) can be added to apply a simple function to the outputs. If no operator is present, the result is the list of all the output entries.". This is confusing - as I understand it if an operator is present a collect hit policy does not return all hits, only the result of the operation.

(2) The spec should state clearly what result is returned by Collect decision tables when no rules fire. In particular the result of a C+ decision table is not clear, because the result of sum([]) is undefined. I think a case could be made (based on a recursive definition) that the sum of an empty list is zero, which would be a much more useful result from the decision table than null. In general, section 10.3.4.4 restricts the semantics of all list functions to non-empty lists, although some functions have natural and useful results for the empty list e.g. count([])=0, sum([])=0, sublist([],x,y)=[], append([],items)=[items], concatenate([],items)=items, reverse([])=[], union([],items)=[], distinct values([])=[], flatten([])=[].

(3) Why is the result of C+ defined as "sum of all the distinct outputs" rather than just "sum of all the outputs"? I would say that if three rules fire proposing the value 5, the C+ result should be 15, not 5.
Reported: DMN 1.1 — Thu, 13 Oct 2016 08:25 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Can an expression in user defined function body reference a name outside of it's scope?

Key: DMN15-23
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
If an expression in a user defined function body references a name outside of it's scope (for example a parent scope), this scope must be available also during invocation of the function.

Examples:
- {f:function() a, a:1, i:f()}
  possible, since name a is still available in local context (scope) during invocation
- {b:1,f:function() b}
  .f() impossible, since name b is not available outside of the context.
It would be nice if the semantic mapping and the differentiation between function definition and invocation is clearly specified in the spec. What names can be referenced? Must the scopes also be available during invocation?
Reported: DMN 1.1 — Wed, 3 May 2017 15:24 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Metamodel constraints & validation

Key: DMN15-30
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
None of the metamodels contain logic constraints. For example, the name of a decision table is the same with the name of the variable defined inside of the decision table tag (invariant at decision table level).

Ideally these constrains would be used to validate the diagrams before execution (e.g. generating code from Java). Bruce Silver's already covers some of the. We should add them and more in the spec.

I think the metamodel constraints should be described with OCL – see the UML metamodels. There should be constraints for CL1, CL2 and CL3. It’s very likely the CL3 constraints will be a superset of CL2 constraints.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:45 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Can the same Definitions/namespace be used by more than one model?

Key: DMN15-15
Status: closed Implementation work Blocked
Source: Red Hat ( Edson Tirelli)
Summary:
Please clarify if it is possible to have multiple models on the same namespace. For instance:

<definitions namespace="http://my.company/financeModels" name="Model A" ...

<definitions namespace="http://my.company/financeModels" name="Model B" ...

The current text of the specification does not say anything explicitly one way or another, so please clarify that.

In addition to this, if multiple models can use the same namespace, then the <import> element will require an additional attribute (for instance: modelName) in order to uniquely identify which model should be imported.
Reported: DMN 1.1 — Thu, 8 Mar 2018 16:20 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122

Key: DMN15-26
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
on page 122 in table 43 in row 2 and 3: "e1 in [e2, e3, ...]"
on page 109 grammar rule 51.c: expression "in" positive unary test
on page 109 grammar rule 51.c: expression "in" "(" positive unary tests ")"

The syntax with square brackets is not allowed by the grammar rules 51.c. Either table 43 or grammar definition should be changed.
Reported: DMN 1.1 — Wed, 3 May 2017 08:58 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Should name declarations in same context fail or overwrite?

Key: DMN15-24
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
As I see the spec doesn't define what should happen if in a context a name should be declared that already exists in the current context. Sample FEEL expression: "for i in [1,2,3], i in [4,5,6] return i * i" Does the second definition of i overwrite the first one or should we return null for the complete "for" expression?
Reported: DMN 1.1 — Wed, 3 May 2017 09:25 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test

Key: DMN15-25
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
For simple positive unary test(s) there are extra entry points in the FEEL grammar. Therefore why do we need simple positive unary test in grammar rule 2.i. What is the semantic mapping?
Reported: DMN 1.1 — Wed, 3 May 2017 09:11 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Semantic domain mapping for simple expressions

Key: DMN15-28
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The FEEL grammar contains simple expressions as starting terminal

page 107 6. simple expressions = simple expression ,
{ "," , simple expression }
;

I could not find a mapping to a semantics domain for it. What is the type / domain of "simple expressions"? A list with element type Any or a Tuple Type with several element types?
Reported: DMN 1.1 — Fri, 17 Mar 2017 14:42 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

No adjustment for last day in month if duration is added/subtracted to date and time value

Key: DMN15-11
Status: closed
Source: ACTICO ( Daniel Thanner)

Summary:

The specification says that the addition/subtraction of a date and time and a years and months duration value is defined as:

date and time (
   date(e1.year +/– e2.years + floor((e1.month+/– e2.months)/12),
   e1.month +/– e2.months – floor((e1.month +/– e2.months)/12) * 12,
   e1.day), 
   time(e1))

If you apply this expression to the following two values:

date and time("2017-08-30T11:00:00Z")
duration("P18M")
you would expect the following results:

date and time("2017-08-30T11:00:00Z") + duration("P18M")  --> result should be date and time("2019-02-28T11:00:00Z")
date and time("2017-08-30T11:00:00Z") - duration("P18M")  --> result should be date and time("2016-02-29T11:00:00Z")

If you apply the values to the defined formula, you get:

date and time (
   date(2017 +/– 1 + floor((8 +/– 6)/12),
   8 +/– 6 – floor((8 +/– 6)/12) * 12,
   30), 
   time("11:00:00Z"))

Addition
which results for addition into:

date and time (
   date(2018 + floor(1,1667),
   14 – floor(1,1667) * 12,
   30), 
   time("11:00:00Z"))

which is:

date and time (date(2019, 2, 30), time("11:00:00Z"))

The adjustment to the last valid day in a month is missing. 30th February is invalid, since February has only 28/29 days.

Subtraction
which results for subtraction into:

date and time (
   date(2016 + floor(0,1667),
   2 – floor(0,1667) * 12,
   30), 
   time("11:00:00Z"))

which is:

date and time (date(2016, 2, 30), time("11:00:00Z"))

The adjustment to the last valid day in a month is missing. 30th February is invalid, since February has only 28/29 days.

Recommendation:
Adjustment to last valid day in month must be added to spec.

Reported: DMN 1.1 — Mon, 2 Oct 2017 12:41 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Enhancement suggestion: make unary tests first class citizens of the FEEL language

Key: DMN15-8
Status: closed
Source: Red Hat Inc ( Edson Tirelli)
Summary:
This is a suggestion for future versions of the spec:

Add support for Unary Tests as first class citizens of the FEEL language, in a similar way as ranges and functions already are.

A unary test is really a “predicate”: a single parameter function that returns a boolean. It is syntax sugar on:

function ( x ) x in <unary_test>

FEEL already supports functions as first class citizens, so it makes sense to support Unary Tests. The following two syntaxes would then be equivalent:

is minor : < 18
is minor : function( age ) age in < 18

Invoking unary tests explicitly would be like invoking a function:

Bob is minor : is minor( bob.age )

More importantly, it would allow the implementation to actually support passing unary tests as parameters to functions and make the example on page 115 viable:

decision table (
outputs: "Applicant Risk Rating",
input expression list: [Applicant Age, Medical History],
rule list: [
[ >60, "good", "Medium" ],
[ >60, "bad", "High" ],
[ [25..60], -, "Medium" ],
[ <25, "good", "Low" ],
[ <25, "bad", "Medium" ]
],
hit policy: "Unique"
)

Unary test syntax is not ambiguous, so supporting it would mean to basically change rule 2 in the grammar to include rules 14 and 17 as possible options. The semantic mapping table on page 116 would also need to include a new FEEL value type: "unary test".
Reported: DMN 1.1 — Tue, 23 Aug 2016 01:41 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Add two new concrete numeric types, make number abstract

Key: DMN15-16
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Currently S-FEEL / FEEL contains only one single numeric type called number that matches the semantics defined in IEEE 754-2008.

This can lead to some strange constructions, such as
substring("footbar", 3.67)
perfect valid in FEEL.

It also has impact on the performance of the execution (speed).

Here is my proposal:
- keep number as an abstract type to backwards compatibility
- add a new concrete type real/float/decimal that matches the semantics of defined in IEEE 754-2008
- add a new concrete type integer
- change the signature of all built-in functions to restrict number to integer when it makes sense (e.g. index in a string and list, length of string. size of list)
- add a separate paragraph to specify the implicit conversions performed by the FEEL processor when required (e.g. function resolution). For example,
  2 + 4.5 leads to a promotion 2 -> 2.0 that adding it 4.5.
If we agree in principal all start working on it.
Reported: DMN 1.1 — Wed, 6 Dec 2017 13:44 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Lexical representation of time string has ambiguous definitons

Key: DMN15-17
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
A lexical time string is defined o page 131 by XML Schema Part 2 Datatypes (for local times and offset times) and by ISO 8601 with the extended form of a local time (for zoned times).

Unfortunately XML Schema Part 2 and ISO 8601 has different definitions. Therefore it is unclear which of them to use. Or are both of them valid?

Additionally the user should not have different lexical time string formats for a local time, an offset time or a zoned time.

The list of ambiguities:
- ISO 8601 allows a leading "T" character prefix. XML Schema Part 2 does not.
- ISO 8601 allows optional seconds. In XML Schema Part 2, the seconds are mandatory.
- ISO 8601 allows decimal fraction for seconds and minutes. XML Schema Part does not allow this.
- ISO 8601 allows 00:00:00 and 24:00:00 for midnight. XML Schema Part 2 only allows 00:00:00.
- ISO 8601 allows time offset of hours only. Minutes are optional. XML Schema Part 2 always requires minutes.
Therefore clarification is needed. Which definitions are valid for FEEL? The stricter XML Schema Part 2 or the more user friendly ISO 8601 spec?
Reported: DMN 1.1 — Mon, 13 Nov 2017 15:24 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Should encapsulated decisions of a decision service include output decisions?

Key: DMN15-10
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Figure 10 on page 25 with text "The encapsulated decisions are therefore
{Decision 1, Decision 2}
"

Figure 11 on page 26 with text "The encapsulated decisions for this services are
{Decision 1}
".

Table 20 on page 56:
- "outputDecisions: This attribute lists the instances of Decision required to be output by this DecisionService".
- "encapsulatedDecisions: If present, this attribute lists the instances of Decision to be encapsulated in this DecisionService".
For us it is unclear what decisions should be stored in the DMN model as encapsulated decisions. Must the output decisions also be included in the list of encapsulated decisions (as stated on page 25, 26)? Or does the list of encapsulated decisions only hold the decisions contained in the lower compartment of a decision service (as mentioned on 56 since encapsulatedDecisions seems to be optional)?
Reported: DMN 1.0 — Tue, 20 Mar 2018 14:49 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

How to get FEEL type if evaluation is not an option?

Key: DMN15-22
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
in chapter 10.3.2.10: "Sometimes we do not want to evalutate a FEEL expression e, we just want to know the type of e."

in table 54: column Applicability defines which row in the table to use, depending on the type of a FEEL expression.

Table 54 only makes sense if it is not allowed to pre-evaluate the expression e2, since even for a pre-evaluation context entries (for example: "item") must be declared in scope.

How do we know the type of a FEEL expression if it is not allowed to evaluate it?

Examples:
- [1,2,3][min(3,2,1)]
- {a:function() external {java: {class: "clazz", method signature: "method()"}}, b:[1,2,3][a()]}.b
- {a: 1, b: a instance of number, c: [1,2,3][b] }
Reported: DMN 1.1 — Wed, 3 May 2017 14:56 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

More Generic Ways to Define Decision Table Properties

Key: DMN15-20
Status: closed
Source: OpenRules ( Jacob Feldman)
Summary:
I described several issues with the current way of representing decision table properties and made concrete suggestions for improvement in this LinkedIn post: https://www.linkedin.com/pulse/decision-table-properties-dmn-beyond-jacob-feldman
Reported: DMN 1.1 — Sat, 20 May 2017 19:09 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

FEEL grammar readability

Key: DMN15-19
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
The grammar contains several sub-grammars each one with its own start non-terminal: expression, simple expressions, unary tests.

The grammar should be broken in several grammars, and common part to make things more obvious. It will help the CL3 implementation.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:37 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement

Key: DMN15-32
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement
Reported: DMN 1.1 — Wed, 24 Aug 2016 16:45 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Scope of decision table input/output entries is not well defined in the specification

Key: DMN15-21
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
While the scope of context entry specifically says to include the previous context entry (section 7.3.1), there is no mention for the scope of input and output entries of decision tables.
Reported: DMN 1.1 — Mon, 15 May 2017 17:59 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Improve description of built-in function string()

Key: DMN15-14
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
The expected output of the built-in function string() should be defined for each type. Otherwise it is unclear what the result for a value, for example of type time, is. Is it the string literal or the full expression with built-in function time()?
// which FEEL expression is valid? string(time("11:00:00")) = "11:00:00" string(time("11:00:00")) = "time("11:00:00")"
Recommendation: Introduce a new table that lists example outputs for all types:
- null -> null
- boolean -> "true" or "false"
- string -> "This is a string"
- number -> "-1.234"
- date -> "2017-10-11"
- time -> "11:00:00.123" or "11:00:00.123+02:00" or "11:00:00.123@Europe/Paris"
- date and time -> "2017-10-11T11:00:00.123" or "2017-10-11T11:00:00.123+02:00" or "2017-10-11T11:00:00.123@Europe/Paris"
- days and time duration -> "P2DT3H4M5.123S"
- years and months duration -> "P2Y3M"
- list -> "[1,2,3]"
- context -> "{a: true, b: false}"
- range -> "[1..100]"
- unary test -> "> 10"
- function -> null
Reported: DMN 1.1 — Wed, 11 Oct 2017 09:02 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions

Key: DMN15-9
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
In Figure 6.15 the multiplicity of output decisions for a decision service is shown as zero to many (0..), but the text below and Table 16 says the that multiplicity is one to many (1..). The figure should be correct to match the text and table.
Reported: DMN 1.1 — Fri, 3 Aug 2018 21:19 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

inconsistent date comparisons make unavoidavle paradoxes

Key: DMN15-39
Status: closed
Source: fujitsu america ( keith swenson)
Summary:
Date "=" is defined to include the time zone, and "<" and ">" does not. This causes a bunch of problems.

see: https://social-biz.org/2017/08/03/a-strange-feeling-about-dates/

Suggestion is simple: define date equality to be (date1 - date2 == 0) Eliminate the need to compare the "timezone" of the dates.

My experience with the group is that most suggestions are ignored, so I don't really want to waste any time making a more detailed proposal, but if you have questions about this problem you can contact me.
Reported: DMN 1.2 — Wed, 18 Sep 2019 10:01 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Requested additional built-in functions

Key: DMN15-29
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(from Bruce)
a. String-join(stringList, separatorString)

b. Format-number(value, formatString), where formatString (to be negotiated) generally follows Excel or xpath, maybe not all the features.

c. Format-date(value, formatString), format-dateTime(value, formatString)
Reported: DMN 1.1 — Mon, 2 Jan 2017 20:43 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Inconsistency DMNv1.2 dropping [a]=a and get entries example

Key: DMN15-52
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
Since DMNv1.2 the spec dropped the equivalence of:
[a] = a
because it does not apply to the statement that

a singleton list L, when used in an expression where a list is not expected, behaves as if L[1] is written.

So the expression
[a] = a
on DMNv1.2 is expected to return false.

However, in section 10.3.2.6 Context of the spec, it provides the following statement for the get entries function:
To retrieve a list of key,value pairs from a context m, the following built-in function may be used: get entries(m).
For example, the following is true:
get entries({key 1 : "value 1 "})[key="key 1 "].value = "value 1 "
BUT
get entries({key1 : "value1"})[key="key1"].value = "value1" by substitution: [ { key : "key1", value : "value1" } ][key="key1"].value = "value1" [ { key : "key1", value : "value1" } ].value = "value1" [ "value1" ] = "value1"
according to DMNv1.2 should be false

By the same principle that the DMNv1.2 for the following literal expression:
[123] = 123
on DMNv1.2 is expected to be false
Reported: DMN 1.2b1 — Wed, 30 Jan 2019 14:43 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Add an itemKind property to ItemDefinition

Key: DMN15-57
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
SDMN, BPMN, and CMMN have a property that specifies the kind of element that is being modeled. The set of enumerations for this property include: data, conceptual, physical, etc.
SDMN is directly referencing DMN’s ItemDefinition, but is extending the element to include this “itemKind” property.
If this property makes sense in the DMN context and is added in DMN 1.4, then SDMN would not have to extend ItemDefinition for this property.
SDMN extends ItemDefinition in other ways, which will be addressed by separate issues.
Reported: DMN 1.3b1 — Tue, 6 Apr 2021 22:11 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression

Key: DMN15-55
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression. The figure should be updated.
This is similar to the issue for Figure 6-10, which has the same problem.
Reported: DMN 1.3 — Wed, 1 Jan 2020 00:21 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

need set operations and equality in FEEL

Key: DMN15-33
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
some notes toward a proper description:
FEEL has ordered lists and some set builtins, e.g. distinct values and union. Lacks intersection and equality.

[1,2] in (1,2,[1,2], 3) is true

intersect([1,2,3], [3,1,4]) = [1,3]

set equals([1,1,3], [3,1]) is true
probably - distinct values([1,1,3]) = distinct values([3,1])
maybe change to set([1,1,3]) = set([3,1])
(set needs to both remove dups and return elements in canonical order)
what is canonical order [null, 0, {}, []]?
[1,3] = [3,1] is false

Another option is to add sets to FEEL semantic domain (along with lists, numbers, contexts, ...). And need syntax.

simpler and more biz friendly proposal - add 'contains any' and 'contains all' as boolean infix operators taking 2 lists as LHS and RHS. And allow these to be added to unary tests w/o a '?'. E.g. 1,2,3 , in (1,2,3) , contains any (1,2,3), contains all (1,2,3). First 2 are what we have now (2nd allowed for symmetry). Last 2 assume input expr is a list (set).

if we just add set oriented builtins, but no friendlier syntax, this may not solve the biz problem of allowing DTs to process sets in a user friendly way. Too many ()s and ?s
Reported: DMN 1.1 — Thu, 11 Aug 2016 15:35 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

notion of arbitrary order conflicts with lack of an unordered collection data type

Key: DMN15-34
Status: closed
Source: Signavio GmbH ( Dr. Bastian Steinert)
Summary:
Section "8.2.11 Hit policy" describes that hit policy "Collect: returns all hits in arbitrary order". This implies that the order of the results does not have to be deterministic and can also vary among different implementations. However, the standard only supports the notion of 'lists', which do have an order. The comparison of lists is also specified in a way that the order of elements is significant. The issue might get more clear when thinking about testing the interface of decisions. Strictly speaking, it is currently not feasible to define a test against a decision table with hit policy 'collect'. The expected result can only be defined using a list, whose elements do have an order. The operator to compare the 'expected' and the 'actual' result will also take order into account.

The issue could easily be resolved by replacing 'arbitrary order' with 'rule order'.
Reported: DMN 1.1 — Sun, 26 Jun 2016 10:11 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

DMN Models need a default timezone

Key: DMN15-38
Status: closed
Source: fujitsu america ( keith swenson)
Summary:
All date expressions, if the timezone is not explicitly mentioned, are interpreted as being in the timezone of the computer running the code. This means you can design a model that runs correctly in one timezone,a nd incorrectly in a different one.

Imagine you have a development team in Bangalore which makes a DMN model that runs correctly and passes all the tests. Then it is installed into the company server in London, and it fails.
Does anyone think this is a good idea?

The solution is simple: the model should have a default timezone. All date expressions that don't mention the timezone are interpreted according to this default time zone, and NOT according the timezone of the machine you are running on. Then, models will run exactly the same way no matter where it is run. That is a good idea, right?

See this: https://social-biz.org/2017/08/03/a-strange-feeling-about-dates/
Reported: DMN 1.2 — Wed, 18 Sep 2019 09:55 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Situational Data Model and Notation (SDMN)

Key: DMN15-40
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
Situational Data is the set of Data Items and their structures that are needed for the performance and understanding of a Knowledge Package Model.
The details of the Data Items will usually be a subset of the “official” complexity of those items in the environment of the Knowledge Package Model.
For example, the official definition of the Data Item for Blood Pressure (in healthcare) includes more than 50 properties. A Data Item in a Situational Data Model may need only 2 of those properties for execution of the Processes, Cases, and or Decision Services.
Semantic References can be added to link the Data Item to the “official” details.
Uses of the Data Items in BPM+ models that determine the scope of Situational Data include:
Data required for DMN Decisions
Data required for BPMN Gateways transitions
Data required to be passed to/from services invoked by BPMN and CMMN
Data required to trigger Sentries in CMMN
Etc.
Reported: DMN 1.2b1 — Tue, 10 Sep 2019 18:04 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT
Attachments:
- BMI Update - SDMN Sep 23 2019.pptx 3.94 MB (application/vnd.openxmlformats-officedocument.presentationml.presentation)

Unspecified conclusion is not supported

Key: DMN15-35
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
I remember discussions about allowing "-" in conclusions to mark an unspecified conclusion in a decision table. This would allow some of the conclusions in a multiple output decision table to be marked as "unspecified" where there was no output relevant for that conclusion for a specific rule and to allow rules in multi-hit tables to show that a particular combination of conditions had been considered but did not result in anything being added to the result set.
However the standard as written says that an output entry must adhere to the literal expression grammar, and '-' is not allowed. You have to return some FEEL value, e.g. 0, false, "N/A", null, etc.
Reported: DMN 1.1 — Mon, 13 Jun 2016 21:41 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Fix interchange of links to objects in BPMN/BMM

Key: DMN15-37
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
The current spec uses objects from BMM and BPMN. However it is not at all clear how links to these objects, and the objects at the end of the links, should be interchanged. Does the DMN file contain a snippet of BPMN? Should a separate BPMN file be generated and then referenced? If we are going to have these links then we need to show/explain how to interchange them both with tools that only support DMN (and so only have a few BPMN or BMM objects) and with those that support DMN/BPMN/BMM.
Reported: DMN 1.2 — Thu, 27 Sep 2018 01:07 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Lack of visual notation for processing of / iteration over lists in FEEL

Key: DMN15-48
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
split off from ~~DMN13-12~~
Reported: DMN 1.2 — Tue, 20 Nov 2018 17:55 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Support for recursive calls by Business Knowledge Models

Key: DMN15-49
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The definition of "well formed" for a BusinessKnowledgeModel excludes the notion of the encapulatedLogic of a BusinessKnowledgeModel being able to invoke itself to permit recursion. There is no means to define a 'self' relationship via knowledgeRequirements - the spec forbids it.

However, vendors are currently supporting BusinessKnowledgeModel recursion simply by permitting a BusinessKnowledgeModel's encapulatedLogic to invoke the contained BusinessKnowledgeModel as a function using the contained BusinessKnowledgeModel's name. I propose we formalise this in the spec.

I propose that after the definition of well-formed on page 56/57 (repeated below):

"An instance of BusinessKnowledgeModel is said to be well-formed if and only if, either it does not have any knowledgeRequirement, or all of its knowledgeRequirement elements are well-formed. That condition
entails, in particular, that the requirement subgraph of a BusinessKnowledgeModel element SHALL be acyclic, that is, that a BusinessKnowledgeModel element SHALL not require itself, directly or indirectly. "

The following paragraph is added:

"However, the encapsulatedLogic within a BusinessKnowledgeModel may invoke itself in a recursive manner by using the name of the containing BusinessKnowledgeModel as an invokable name."
Reported: DMN 1.2 — Sat, 6 Apr 2019 02:38 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

properly define type(e)

Key: DMN15-51
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
In some places the spec uses type(e) and other places type(e). These are different. The former provides a type-checking function that can validate a FEEL expression e without input data values (although some kind of scope is needed for disambiguation). The latter simply returns the datatype of the semantic domain element e. The former is more useful to implementors, but more work to specify. Essentially, all the semantic mapping tables need a new column to specify the result type given the input types, for each FEEL operator and builtin. The latter is a matter of generalizing Table 39. It must cover cases such as type([0,false]). It should be clear that type(e) as a function must return the most specific type (and there must be only 1), but informally the types also include those that are conformed to, so for example, [1,2,3] has types list<number>, list<Any>, Any.
Reported: DMN 1.2 — Tue, 27 Nov 2018 22:31 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Knowledge Package Model and Notation (KPMN)

Key: DMN15-41
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
A Knowledge Package is mechanism for packaging and distributing a set of BPM+ models (the knowledge)
A Knowledge Package references separate, but connected BPM+ models (BPMN Processes, CMMN Cases, and DMN Decision Services)
KPMN is focused solely on the BMI behavioral standards
A Knowledge Package also contains a Data Item library for the data that will be used by the BPM+ models
A Situational Data Model and Notation (SDMN) is also being proposed as a potential BMI standard to be added to the BPM+ stack (see separate presentation on this topic)
A Knowledge Package also contains metadata about the topic of the package to aid in understanding the content and to find appropriate Knowledge Packages
We are still exploring the relationships between KPMN and Provenance and Pedigree
KPMN includes a diagram to illustrate the scope of the Knowledge Package’s content (a Knowledge Model Diagram)
Reported: DMN 1.2b1 — Tue, 10 Sep 2019 17:59 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT
Attachments:
- BMI Update - KPMN Sep 23 2019.pptx.zip 6.44 MB (application/zip)

Clarification on DMN case sensitivity of timezones

Key: DMN15-50
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
DMN spec refers to usage of iana timezones. iana does not specify that timezones are case-sensitive - that is up to the implementation. https://data.iana.org/time-zones/theory.html: re zone naming:

"Do not use names that differ only in case. Although the reference implementation is case-sensitive, some other implementations are not, and they would mishandle names differing only in case."

This issue is seeking clarification via the spec as to whether DMN's usage of time zones permits case insensitivity such that "etc/utc" is the same zone as "Etc/UTC" ... or not.
Reported: DMN 1.2 — Sat, 16 Mar 2019 01:12 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

"instance of" not possible with some built-in functions

Key: DMN15-53
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
some built in functions are overloaded in that they can have multiple signatures. So, say, performing an "instance of" to compare against the function "min" is meaningless as the signature is not known unless it is invoked.

Unless the type system is to take into account overloaded functions?
Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:15 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.

Key: DMN15-54
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.
UnaryTest should be added to the diagram.
Reported: DMN 1.3 — Wed, 1 Jan 2020 00:23 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Temporal precision inconsistencies

Key: DMN15-43
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
The spec sometimes refers to the temporal precision as milliseconds and sometimes to seconds. Sections 10.3.2.3.3, 10.3.2.3.5 and 10.3.2.3.6 refer to Seconds whereas table 48 offers a semantic of Milliseconds
Reported: DMN 1.2b1 — Tue, 16 Jul 2019 14:02 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Provide better spec and examples for Equality, Identity, and Equivalence

Key: DMN15-46
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
the builtin function is() refers to this section. It should cover some pos/neg examples of equality vs. identity, and explain aggregate elements in D, e.g. list of structures.
Reported: DMN 1.2b1 — Tue, 28 May 2019 16:40 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Friendlier handling of null values

Key: DMN15-47
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
E.g. in aggregation, default for item definition, see examples in DMN-2, where filters like [item!=null] are used repeatedly
Reported: DMN 1.2b1 — Tue, 21 May 2019 16:53 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Missing semantics for multiple imports

Key: DMN15-58
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The semantics of Import is not fully specified.

In certain use cases the same DMN element (e.g. ItemDefinition or DRGElement) can be imported multiple times (e.g. transitive imports).

Lets consider the following use case:
- Model A contains the definition of an InputData for a Person (e.g. name, age etc)
- Model B imports model A. Model B contains a decisions DB that uses the Person as input
- Model C imports models A and B. Model C contains a decision DC that uses Person and DB as input
In this situation model C imports Person twice due to transitive import.

In order to evaluate DC the Person InputData has to be bound to a value. The question is how many values is the user going to provide, lets say in a Web form? A single value or one value for each import path (in this case 2)?

I am inclining towards the first option - one single value per input data. Here is my rationale:
- InputDatas / DRGElements are uniquely identified by model namespace and DRGElement.name
- InputDatas own one single variable (see 6.3. Metamodel). The semnatics for InputData.variable is in Table 18:
  The instance of InformationItem that stores the result of this InputData.
- Consistency with the import of other DMN Elements: it does not make any sense for ItemDefinitions, BKMs and DSs to have multiple variables / values when imported several times.
- If we choose the second option and the model is refactored (e.g. models are merged), but the logic does not change, the user has to fill-in different input forms. It is not very user friendly.
- I am not aware of any PL/DSL that uses the second option
Lets discuss.
Reported: DMN 1.3 — Tue, 30 Mar 2021 08:28 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

DRG requirements only state am unused knowledge requirement is illegal

Key: DMN15-61
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
Subsection "6.2.2.2 Knowledge Requirement notation" of "6.2.2 DRD Requirements" states that knowledge requirements must be utilised in the decision/BKM knowledge requirement:

"If e is a decision or a BKM in some DRD, and e contains a knowledge requirement on some invocable element b, then the logic of e must contain an invocation expression of b, including expressions for each of b's parameters."

However, this section does not mandate that Information Requirements must also be utilised by the requiring DRG element in the same way that a knowledge requirement must. If a purpose of DMN is to serve as documentation and show actual relationships between decision elements then it is paramount the DRG reflects actual usage in the model, otherwise the graph is incorrect - it may show relationships that do not reflect the decision-making reality.

I propose adding the following to section "6.2.2.1 Information Requirement notation":

"If e is a DRG element in some DRD, and e contains an information requirement on some other DRG element b, then the logic of e MUST contain a usage of the information provided by b"
Reported: DMN 1.3 — Thu, 25 Mar 2021 08:10 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Spec does not mandate that all user-defined function parameters are utilised

Key: DMN15-59
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
Section "10.3.2.13.2 User-defined functions" provides definition and invocation semantics for user defined functions but permits unused parameters.

As DMN is to be 'executable documentation' I suggest that unused parameters provide documentation that does not reflect reality.

I propose the follow additional paragraph to "10.3.2.13.2 User-defined functions" :

"The body expression of a user-defined function SHALL utilise every formal parameter. "
Reported: DMN 1.3 — Thu, 25 Mar 2021 08:35 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

No way to show relative multiplicity of decisions and their information requirements

Key: DMN15-62
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
Item Definitions are hierarchical so the top level one in an Input Data or a Decision might not be a collection while one or more of those contained are. This means that there may be a collection to process even if the Input Data or Decision is not marked as a collection (see ~~DMN14-123~~ for this separate issue). It should be possible to show both "fan in" where multiple instances of the source of the requirement are used by a single instance of a decision and "fan-out" when the source of requirement contains a collection which will be processed one at a time by the decision.
Reported: DMN 1.3 — Wed, 24 Feb 2021 05:36 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT
Attachments:
- FanProposal_JTJP.pdf 297 kB (application/pdf)

Spec does not mandate that all formal parameters are utilised.

Key: DMN15-60
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
Section "10.5.3 FunctionDefinition metamodel" does not specify that formal parameters must be utilised in the function logic . As DMN is a self-documenting decision executable this leads to a situation where (documented) parameters may be defined but unnecessary.

I propose the following paragraph is added to section "10.5.3 FunctionDefinition metamodel":

"The body expression of a FunctionDefinition SHALL utilise every formal parameter. "
Reported: DMN 1.3 — Thu, 25 Mar 2021 08:25 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

No way to tell that a Decision iterates over a collection

Key: DMN15-63
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
There is no visual way to show that a decision iterates over a collection at the top level.
Reported: DMN 1.3 — Wed, 24 Feb 2021 05:31 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

P0D == P0Y in SFEEL, but it is unclear if P0D == P0Y in FEEL

Key: DMN15-64
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
Section 9.4 says "Comparison operators are defined only when the two operands have the same type, except for years and months duration
and days and time duration, which can be compared for equality. Notice, however, that “with the exception of the zerolength
duration, no instance of xs:dayTimeDuration can ever be equal to an instance of xs:yearMonthDuration.”

Thus stating that `P0D == P0Y` despite the fact they are different types and do not comply with the type-lattice equivalency. This is as per the XPATH operation `op:duration-equal` that the spec says equality here conforms to.

It is not crystal clear if this applies to FEEL as well as SFEEL though the same sections does say:

> The semantics of S-FEEL expressions are defined in this section, in terms of the semantics of the XML Schema datatypes
and the XQuery 1.0 and XPath 2.0 Data Model datatypes, and in terms of the corresponding functions and operators
defined by XQuery 1.0 and XPath 2.0 Functions and Operators (prefixed by “op:” below). A complete stand-alone
specification of the semantics is to be found in clause 10.3.2, as part of the definition of FEEL. Within the scope of SFEEL,
the two definitions are equivalent and equally normative.

So, "Within the scope of SFEEL, the two definitions are equivalent and equally normative." seems to indicate that it does hold true for FEEL.

My recommendation is that `P0D == P0Y` does apply to FEEL because it would make sense to a business person. `1 Apple != 1 Orange`, but zero apples is really the same as zero oranges, or zero anything for that matter. And, in practice, zero days really is the same as zero years.
Reported: DMN 1.3 — Fri, 19 Feb 2021 09:31 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

the operation of is() function is not well specified

Key: DMN15-66
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The new is() function is in a spec section called "Date and time functions" but it is unclear if it related only to date and time types. The examples only show date and time. Though it would seem reasonable that is also handled datetime type as well.

Additionally, it references section 10.3.2.2 for descriptions of semantics and that section deals with ore than just date and time. It also deals with other 'primitive' types - so it is unclear if is() relates to these also. Additionally, that section does not deal with other types like range/context/function/list so it is not clear if is() deals with all types in that section, and indeed other types as well.

By example, is it not evident if is({},{}) is true, false, or illegal. Similarly for is([1], [1]) or is(1,1), or is([null..2], < 2).

Additionally, it is also unclear (to me) from the semantic description whether is(@"2021-02-19T10:10:10Z", @"2021-02-19T10:10:10@Etc/GMT") as they are both UTC forms. The spec says they are 'comparable', but does that relate to is()?
Reported: DMN 1.3 — Fri, 19 Feb 2021 10:20 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Allow for partial temporal values

Key: DMN15-69
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
It should be possible to define partial temporal values but only for trailing precisions (i.e., if you specify a day, you must also specify a year and month)
Values of type Date, the precision unit must be one of: years, months, or Days
e.g. date( 2019 ), date( 2019, 09 ), date( 2019, 09, 17)
Values of type Time, the precision unit must be one of: hours, minutes, or seconds
e.g. time( 09 ), time( 09, 55), time( 09, 55, 00)
Values of type Date and Time, the precision unit must be one of: years, months, days, hours, minutes, or seconds
e.g. date and time( date(2019,09,17), time(09,55) ), date and time( “2019-09-17T09:55”)

Operations carried out on elements with different time based precision units shall be done based on the lowest common precision unit (truncating any resulting decimal portion)
Reported: DMN 1.3 — Tue, 26 Jan 2021 22:17 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

FunctionItem `parameters` array attribute is plural, not singular in name

Key: DMN15-68
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The `parameters` attribute of the new FunctionItem introduced in DMN 1.3 is plural in name and not singular like all other array attributes described in the meta-models. This is an exception.

This leads to an XML form where each `<parameters>` element contains one parameter.

Recommendation. Change FunctionItem array attribute `parameters` to `parameter`. Another possibility is to deprecate `parameters` in favour of `parameter` and drop support in a future version.
Reported: DMN 1.3 — Tue, 2 Feb 2021 22:55 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Allow input data to be of type Interval

Key: DMN15-72
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
In many situations, it is desirable to have a data input that is an interval. Particularly when it comes to temporal logic many situations requires one to enter the "Valid Period", the "Measurement Period", the "Disccount Period" etc
To currently achieve this requires to create two data inputs (one for the start data/time and one for the end data/time) and then assembling them into an interval named "Period using a literal expression [start..end].
Reported: DMN 1.3 — Mon, 25 Jan 2021 20:17 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Ambiguous named params for before() and after() range functions

Key: DMN15-67
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The `before` and `after` range functions have ambiguous invocation when using named params. Both functions have 4 variants - take `before` as an example:

```
(a) before(point1, point2)
(b) before(point, range)
(c) before(range, point)
(d) before(range1, range2)
```

If I invoke `before(range: [1..10], point: 1)` is it for variant (b) ... or (c) ... ?

Suggest renaming the param names or making the variants separate functions.
Reported: DMN 1.3 — Tue, 2 Feb 2021 23:38 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Change to the "at literal" in FEEL

Key: DMN15-70
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Currently the at literal = "@", string literal
Rather than a string following the @ symbol we would use the ISO 8601 format.
For date : @YYYY-MM-DD e.g. @2019-09-17
For time : @THH:MM:SS e.g. @T09:55:00
For date and time : @YYYY-MM-DDTHH:MM:SS e.g. @2019-09-17T09:55:00
For duration : @P[n]Y[n]M[n]DT[n]H[n]M[n]S where [n] is a number
e.g. @P18M, @P365D, PT48H
Reported: DMN 1.3 — Tue, 26 Jan 2021 22:11 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Adding a new interval built-in function

Key: DMN15-71
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Add a new interval built-in function called: width of( Interval )
to offer the behavior as follows:
width of( (1..10] ) = 9
width of( [1..10] ) = 10
width of( (1..10) ) = 8
width of( [ time(“09:55:00”)..time(“10:35:00”) ] ) = PT40M
Reported: DMN 1.3 — Tue, 26 Jan 2021 22:03 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Links with other standards

Key: DMN15-75
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
A "bucket" for collecting related issues around external links
Reported: DMN 1.3 — Tue, 3 Nov 2020 18:17 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

No Mapping of FEEL to JSON

Key: DMN15-101
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
Current DMN Specification v1.4 does not define a mapping of FEEL to JSON, while it already provides mapping for Java, XML, PMML in chapter "10.3.2.12 Mapping between FEEL and other domains"

This capability can be useful in other use-cases beyond mapping itself. For example, but not limiting to: the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services.
Reported: DMN 1.4 — Wed, 13 Apr 2022 13:22 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT
Attachments:
- Screenshot 2022-04-13 at 15.17.46.png 267 kB (image/png)

Clarification on syntax of DMNReference

Key: DMN15-73
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
It is not very clear (see discussion on TCK https://github.com/dmn-tck/tck/pull/366) if DRGElement can be referenced in the same XML file using an absolute path.

For example,

<requiredDecision
href=”http://www.example.org/Definitions01.xml#prebureauriskDec01”/>

is a valid reference even if prebureauriskDec01 is defined in the same file with element the referenced it.
Reported: DMN 1.3 — Fri, 1 Jan 2021 11:14 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Missing InformationItem Association?

Key: DMN15-77
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
In other sections in the spec, InformationItem is described as storing the data through an ItemDefinition or Expression. Figure 6.16 shows that InformationItem has a /type association with ItemDefinition. Other figures show this also.
But the table in the section on InformationItem (7.3.4) doesn't list this association and ItemDefinition is not mentioned in the section.
Reported: DMN 1.3 — Fri, 10 Jul 2020 21:28 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Functions cannot invoke external services

Key: DMN15-91
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
The current definition of externally-defined functions only allows Java and PMML external functions. There are clear use cases for allow an external (stateless and side-effect free) service to be used in this way.
Reported: DMN 1.4 — Wed, 16 Mar 2022 19:34 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Import into default namespace is undefined

Key: DMN15-139
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
The current mechanism for importing in DMN requires a name attribute to be a prefix to imported elements names.
Importing an item definition named Person becomes import. Person when referencing it from the local model.
This is confusing to some business users.

We would like to allow the import into the default namespace by specifying an empty name.
This, of course, has the potential of creating name collisions for the imported elements.
We suggest that when a name collision occurs for one of the imported elements, the local element is kept and the imported one is discarded.
Reported: DMN 1.4b1 — Fri, 2 Dec 2022 14:35 GMT
Disposition: Resolved — DMN 1.5
Disposition Summary:
Allow the import into the default namespace by specifying an empty name.

allow the import into the default namespace by specifying an empty name.
Updated: Fri, 30 Jun 2023 20:31 GMT

Friendly enough cohersion to string

Key: DMN15-151
Status: closed
Source: camunda.com ( Mr. Nico Rehwaldt [X] (Inactive))
Summary:
Currently concatenating strings is not intuitive to users, as I always have to convert non string values to strings using the built-in `string` function.

So

```
"Today is " + now() = null
```

In order to yield the actual string you explicitly convert `now()` to its string representation:

```
"Today is " + string(now()) = "Today is 2021-12-12"
```

A more user friendly behavior would be to coherse the second argument to string if the first argument is already a string. This always yields a string representation of the thing. If it is not what I desire I can use custom stringification mechanisms explicitly.

We'd need to amend the Table 57 (page 128, https://www.omg.org/spec/DMN/1.4/Beta1/PDF) to support such cohersion.

—

Additional details on this case can be found in https://github.com/dmn-tck/tck/issues/538 (DMN TCK issue on this topic).
Reported: DMN 1.4b1 — Thu, 19 Jan 2023 12:50 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Importing libraries of functions is not business friendly

Key: DMN15-123
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
There are many different Functions that are needed to make FEEL expressive enough for tackle the logic of various contexts/industries:
e.g Financial Functions, Healthcare Functions, etc. even advanced Mathematical functions or Matrix manipulation functions.

Currently these functions need to be imported in, and then all functions need to be prefixed with a namespace.
This not ideal as the business friendly name with space such as "annual interest rate" now becomes cryptic as "financial.annual interest rate"
or "discount as percentage" becomes "financial.discount as percentage"
Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:27 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Interchanging models that use external libraries of functions is complicated

Key: DMN15-124
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Currently if a DMN model makes use of an external library of functions, the receiving tool may be challenged in also importing this library and execute on these new functions.

We should explore a way to make the interchanged model not only exchangeable but also executable.
Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:35 GMT
Disposition: Deferred — DMN 1.5
Disposition Summary:
Defer to DMN 1.6

Defer to DMN 1.6
Updated: Fri, 30 Jun 2023 20:31 GMT

Underspecified when ranges may include a qualified name for the endpoint, which resolves to null

Key: DMN14-197
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
It is underspecified when the ranges may include a qualified name for the endpoint, which resolves to null.

This was identified by Greg McCreath and Octavian Patrascoiu during TCK contributions.

Ranges' Endpoints can be either a literal or a qualified name. If the qualified name resolves to null, and the endpoint inclusivity flag is false, it is semantically equivalent to the case of single-endpoint-range. This leads to ambiguity in Table 55: Semantics of decision table syntax

This also requires the typo fix in https://issues.omg.org/browse/INBOX-1337

Example

With reference to examples in Table 42: Examples of range properties values

Instead of (1..10]
do consider (x..10]
if x resolves to null
then this is semantically equivalent to <=10.

However, Table 55, row 9, cites:
e1 in (e2..e3] is equivalent to e1 > e2 and e1<=e3 // exercise by hand.. e1 in (x..10] is equivalent to e1 > x and e1<=10 // if x resolves to null.. e1 in (null..10] is equivalent to e1 > null and e1<=10 e1 > null and e1<=10
which is NOT equivalent to e1<=10, hence the ambiguity.
Reported: DMN 1.3 — Sun, 5 Sep 2021 07:18 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force
Updated: Tue, 16 Aug 2022 08:59 GMT

New built-in function to merge/concatenate two or more contexts

Key: DMN14-182
Status: closed
Source: Camunda Services GmbH ( Mr. Philipp Ossler)
Summary:
Currently, it is not possible to merge/concatenate two or more contexts. A context can only be declared statically.

We need to model a decision that gets two or more contexts and returns a new context that includes all entries of the given contexts.

Suggestions:
- introduce a new built-in function similar to the concatenate() function of lists but for contexts
- it is named `put all` (like Java's Map#putAll function)
- it has one argument: contexts... (type: list<context<Any>>)
- it returns a new context that includes all entries from the given contexts
- it might override context entries if the keys are equal. The entries are overridden in the same order as the contexts are passed in the function
put all({x:1}, {y:2}) // returns: {x:1, y:2}
Reported: DMN 1.3 — Tue, 22 Jun 2021 03:56 GMT
Disposition: Duplicate or Merged — DMN 1.4
Disposition Summary:
Close as merged

Resolved as part of ~~DMN14-187~~
Updated: Thu, 31 Mar 2022 19:30 GMT

New built-in function to create a new context

Key: DMN14-183
Status: closed
Source: Camunda Services GmbH ( Mr. Philipp Ossler)
Summary:
Currently, it is not possible to create or modify a context dynamically. A context can only be declared statically.

We need to model a decision that gets a context, adds or removes entries, and returns a new context. For example, by using the get entries() function of a given context and modifying the entry list with a filter expression or list functions.

Suggestions:
- introduce a new conversion built-in function for context as reverse function to get entries()
- it is named `context`
- it has one argument: entries... (type: list<context<Any>>) - each context must have two entries with the keys: "key" and "value"
- it returns a new context that includes all given entries
context([{"key":"a", "value":1}, {"key":"b", "value":2}]) // returns: {a:1, b:2}
Reported: DMN 1.3 — Tue, 22 Jun 2021 04:11 GMT
Disposition: Duplicate or Merged — DMN 1.4
Disposition Summary:
Close as merged

Resolved as part of ~~DMN14-187~~
Updated: Thu, 31 Mar 2022 19:30 GMT

No function to add an entry to a context

Key: DMN14-181
Status: closed
Source: Camunda Services GmbH ( Mr. Philipp Ossler)
Summary:
Currently, it is not possible to add an entry to a given context. A context can only be declared statically.

We need to model a decision that gets a context, adds an entry, and returns the new context.

Suggestions:
- introduce a new built-in function similar to the add() function of lists but for contexts
- it is named `put` (like Java's Map#put function)
- it has three arguments: context (type: context<Any>), key (type: string), value (type: Any)
- it returns a new context that includes the new entry
- it might overwrite the value of an existing entry
put({x:1}, "y", 2) // returns {x:1, y:2}
Reported: DMN 1.3 — Tue, 22 Jun 2021 03:45 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Introduce 3 new built-in functions for context

Introduce 3 new built-in functions for context creation, context put, context merge (of several contexts).
Updated: Thu, 31 Mar 2022 19:30 GMT

New XML Namespace needed

Key: DMN14-166
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
For tools to clearly identify the version of a DMN file or FEEL expression, the XML namespaces of DMN, DMN DI, and FEEL should be updated.

DI and DC namespaces can stay the same as DMN 1.4 DI is still based on the same DI 1.1 specification.

Namespace URIs should be consistent with the scheme applied in DMN 1.2 and DMN 1.3
Reported: DMN 1.3 — Tue, 20 Apr 2021 18:49 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Update XML Namespaces for DMN 1.4

Update namespace URIs with the following values:
- DMN14.xsd: https://www.omg.org/spec/DMN/20211108/MODEL/
- FEEL: https://www.omg.org/spec/DMN/20211108/FEEL/
- DMN14.xmi: http://www.omg.org/spec/DMN/20211108/DMN14.xmi
This is consistent with the scheme applied in DMN 1.2 and DMN 1.3, and in conformance with the "OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces in OMG Specifications - Version 3" (smsc/2018-08-01), which states in particular:

Note: if a spec has many machine readable files, and only some of them change at a given specification version, then only the changed files should get new URIs. That could mean a mixture of URI date segment values for a given specification version.
Updated: Thu, 31 Mar 2022 19:30 GMT

Missing boxed expression for iterator expression

Key: DMN14-194
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
The current version of the spec is missing a boxed expression visualization and serialization for iterator expressions
Reported: DMN 1.3 — Tue, 7 Sep 2021 12:58 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Add boxed iterator expression

See attached word document and figures
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- Add boxed iterator expression.docx 79 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Boxed iterator - For example.png 8 kB (image/png)
- Boxed iterator - For.png 6 kB (image/png)
- Boxed iterator - every example.png 5 kB (image/png)
- Boxed iterator - every.png 6 kB (image/png)
- Boxed iterator - some example.png 18 kB (image/png)
- Boxed iterator - some.png 6 kB (image/png)

Missing boxed expression for filter expression

Key: DMN14-192
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
The current version of the spec is missing a boxed expression visualization and serialization for filter expression
Reported: DMN 1.3 — Tue, 7 Sep 2021 12:54 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Add boxed filter expression

See attached word document and figures
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- Add boxed filter expression.docx 25 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Boxed Filter - example.png 3 kB (image/png)
- Boxed Filter.png 4 kB (image/png)

Missing boxed expression for conditional statement

Key: DMN14-190
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
The current version of the spec is missing a boxed expression visualization and serialization for conditional statement
Reported: DMN 1.3 — Tue, 7 Sep 2021 12:46 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Add boxed conditional expression

see word document and images
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- Add boxed conditional expression.docx 41 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Boxed Conditional - Example.png 17 kB (image/png)
- Boxed Conditional.png 5 kB (image/png)

Typo Table55 row 7

Key: DMN14-196
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
From row 4 it is about syntax sugar for inequality, but is missing the >case (row7).
Reported: DMN 1.3 — Sun, 5 Sep 2021 07:10 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Fix typo

Fix typo
Updated: Thu, 31 Mar 2022 19:30 GMT

Are the names of boxed context entries unique in a given context ?

Key: DMN14-178
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The standard does not specify if a valid boxed context can contain several context entries with the same key or not.

However, it does specify that if a FEEL context is described via text (see FEEL grammar and 10.3.2.6 Context) the keys are distinct.

Also, how are the names overriden / shaded ?
Reported: DMN 1.3 — Tue, 8 Jun 2021 11:10 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Clarify that names are unique within a context

Proposal does not explicitly state that names are unique within a context - clarify.
Updated: Thu, 31 Mar 2022 19:30 GMT

Incorrect example in Table 40: Examples of equivalence and conformance relations

Key: DMN14-55
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Table 40 contains the folowing row:

date date and time False True

Based on the definition given in a previous section it should be

date date and time False False
Reported: DMN 1.2 — Sun, 2 Jun 2019 12:33 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Fix example about conformance of date and date and time

Fix example and remove empty row
Updated: Thu, 31 Mar 2022 19:30 GMT

More examples of replace() function needed

Key: DMN14-164
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
for instance append a basic down-to-Earth example like:
replace("banana","a","o") = "bonono"
as already agreed on the DMN TCK.

We found User enquiry about the behaviour of the function, and the only example listed currently is quite techy. Possibly adding a simple example first would help end-users
Reported: DMN 1.3 — Tue, 13 Apr 2021 10:16 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Add more examples of replace() function

We got User enquiries about the behaviour of the function, and the only example listed currently is quite technical. Possibly adding a simple example first, in addition to the existing technical example, would help end-users.
Updated: Thu, 31 Mar 2022 19:30 GMT

typo - incorrect indexing

Key: DMN14-117
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Second paragraph from the bottom of page 173 contains

have qualified names nbkmi and encapsulatedLogic bkmi.f.

it should be

have qualified names nbkmi and encapsulatedLogic fbkmi.

where bkmi are formatted as indexes (see description of the of the syntax for FEEL function in the naext paragraph).
Reported: DMN 1.3 — Thu, 24 Dec 2020 10:23 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Correct typo - incorrect indexing

correct indexing
Updated: Thu, 31 Mar 2022 19:30 GMT

Incorrect figure reference

Key: DMN14-185
Status: closed
Source: Sapiens Decision NA ( Mr. Gil Segal)
Summary:
On p. 155, section 10.6.1 incorrectly refers to Figure 10-2. The reference should be to Figure 10-18 which is found on p. 156.
Reported: DMN 1.3 — Tue, 29 Jun 2021 16:35 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Correct figure reference

On p. 155, section 10.6.1 incorrectly refers to Figure 10-2. The reference should be to Figure 10-18 which is found on p.156.
Updated: Thu, 31 Mar 2022 19:30 GMT

Wrong and Incomplete FEEL grammar rule 52

Key: DMN14-87
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
Grammar rule 52 is using single quote notation, and I believe this is just a typo when submitting the original change.

However DMNv1.3 also missed to exclude grammar 52 from defining Literal terminal symbol.
This is a concerning problem.
This implies rule 52 as defined in DMNv1.3 is defining additional Literal terminal symbol(s) and therefore with DMNv1.3 it is no longer formally possible to name a DRGElement for example: "list of products" or "context of business".
I believe this is an oversight in backward compatibility:
- rule 52 is only used for the technical “instance of” operator which may find limited use by business analysts
- using as a name “list …” or “context …” might be more relevant and wide-spread used, ref examples above
The proposal below addresses this problem as well, making DMNv1.3+ backward compatible again

Proposal

A total of 2 changes.

With reference to DMNv1.3 dtc-19-12-06

Chapter 10.3.1.2 Grammar rules Page 121
replace:
52. type = qualified name | 'list' '<' type '>' | 'context' '<' name ':' type { ',' name ':' type } '>' | 'function' '<' [ type { ', ' type } ] '>' '->' type ;
with:
52. type = qualified name | "list" "<" type ">" | "context" "<" name ":" type { "," name ":" type } ">" | "function" "<" [ type { ", " type } ] ">" "->" type ;
Chapter 10.3.1.4 Tokens, Names, and White space Page 122
before bullet point:

* A sequence conforming to grammar rule 28, 29, 35, or 37

insert new bullet point:

* for backward compatibility reasons, “list” and “context” from grammar rule 52 are not considered Literal terminal symbols.
Reported: DMN 1.3 — Wed, 8 Apr 2020 07:20 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Correct FEEL grammar rule 52

Replace inverted commas in rule 52 and include "52" in reference
Updated: Thu, 31 Mar 2022 19:30 GMT

the word 'decision' is misspelt.

Key: DMN14-156
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
In the following section, the world 'decision' is misspelt as 'decsion'.

"- Binding contexts in which the value of an expression is bound to a variable with associated type information
(e.g. binding actual parameters to formal parameters in an invocation, or binding the result of a decision’s logic
to the decsion’s output variable). The expression is subject to conforms to conversion."
Reported: DMN 1.3 — Sun, 28 Feb 2021 07:02 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Fix typo

Fix spelling of decision
Updated: Thu, 31 Mar 2022 19:30 GMT

Missing functions for rounding

Key: DMN14-126
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Currently the existing functions support: ceiling, flooring and even rounding.

There are uses cases where other type of rounding are needed.
Reported: DMN 1.3 — Wed, 20 Jan 2021 20:15 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Add extra functions for rounding

Add extra functions for rounding
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- DMN14-126 Rouding Functions-v2.docx 22 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Sub-decisions are referenced but not defined

Key: DMN14-167
Status: closed
Source: Sapiens Decision NA ( Mr. Gil Segal)
Summary:
The DMN 1.3 specification refers to "sub-decisions" in two places (sections 5.3.3 and 10.6.1) but this term is not defined.
Reported: DMN 1.3 — Thu, 27 May 2021 15:19 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Replace sub-decision as a term

Replace the phrases with alternative descriptions
Updated: Thu, 31 Mar 2022 19:30 GMT

Collections are not shown on diagrams

Key: DMN14-150
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
When an Input Data or Decision is represented by an InformationItem that is a collection, there is no visual annotation on the DRD, reducing the clarity of the diagram.
Reported: DMN 1.3 — Wed, 24 Feb 2021 05:26 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Annotate collections on DRDs

Revise the text to allow a decoration on Input Data and Decisions that are collections.
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- New Figure 11.34 DRD for Recommended Loan Products.png 40 kB (image/png)
- NewFigure610.png 6 kB (image/png)

instance of grammar does not support range , or context, or function

Key: DMN14-143
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The instance of grammar does not include the range type, so it is not possible to do `[1..10] instance of range<Any>`. Nor does it support either identifying something as simply a context, or simply as a function.

Please add range<type> to the grammar.

The grammar does support identifying something as simply a context. The list type can be accommodated by <Any>, such as `foo instance of list<Any>`, but the grammar for context currently requires at least one name and type, so simply checking that something is a context is not supported. That is, `foo instance of context<>` is not possible.

Please change the context grammar from `'context' '<' name ':' type
{ ',' name ':' type }
'>' to `'context' '<[' name ':' type
{ ',' name ':' type }
']>'` implying that `context<>` means a context with no entries and thus, all contexts conform to it. Though, a more preferable alternative is described below.

Also, the grammar does not support identifying something as a function, only as a function of a given type - there is no equivalent to `foo instance of function<Any> -> Any`. The statement `foo instance of function<> -> Any` is testing for a function type with no params. This is different to testing purely for a function type.

A grammar to support the above is simply to support the name of each of the types with no `<>` stuff afterwards. Such that `foo instance of list`, `foo instance of context`, `foo instance of function`, `foo instance of range` are all valid. This would be my preference.
Reported: DMN 1.3 — Sun, 21 Feb 2021 01:03 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Add range to instance of

The changes are baselined on DMN 1.3 dtc-19-12-06.pdf.
Updated: Thu, 31 Mar 2022 19:30 GMT

DMNDiagram 'Size' attribute has capital 'S' in schema definition

Key: DMN14-142
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The DMNDI13 XML schema has element child element 'Size' for DMNDiagram. Note the capital 'S'. This is an anomaly as all other element names have a lower case first char.

Additionally, the spec on page 238 incorrectly has the element as 'size' - with a lower case.

Suggestion is deprecate 'Size' in the schema, support both for a time, then drop 'Size' to support only support 'size' - to align the naming in the schema with other elements. And update the spec accordingly.
Reported: DMN 1.3 — Fri, 19 Feb 2021 10:44 GMT
Disposition: Closed; No Change — DMN 1.4
Disposition Summary:
Close without change

It is not worth breaking backward compatibility, for a purely cosmetic issue in the XML schema. The XML serialization is meant to be written and read by software and this should be a major problem for implementers. XML schema validation should easily uncover a bug in an exporter and the fix is trivial.
Updated: Thu, 31 Mar 2022 19:30 GMT

The result of product([]) is not defined

Key: DMN14-141
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The product() function may take a list but it is not defined what the return value is when the list is empty.

It could be zero, or could be null. Other list function return null like `median( [ ] ) = null`, and `stddev( [ ] ) = null`, so it seems reasonable to make `product([]) = null`, but likely more business friendly to make `product([]) = 0`. I'd go for the latte.
Reported: DMN 1.3 — Fri, 19 Feb 2021 10:29 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Define result of product([]) to be null

As discussed on the RTF meeting held 2021-03-23 for consensus (kept consistency with other functions)
Updated: Thu, 31 Mar 2022 19:30 GMT

DMNv1.3 fix DMN example files issues

Key: DMN14-74
Status: closed
Source: Red Hat ( Matteo Mortari)

Summary:

The DMN example files provided with DMNv1.3 have a few problems which need to be corrected, one issue specifically is preventing from being a correct DMN format, possibly inadvertently a result of the tinkering which happened before final release:

Chapter11 second example files are missing default xlmns
Loan Info.dmn: typo in Monthly HOA/Condo Fee
Loan Info.dmn: typo in Quallifying Monthly Payment
Recommended Loan Products.dmn: itemDefinition of "tLoanProduct" component Product Name allowedValues is not consistent with itemDefinition "tProductName"
Chapter11 first example typo in "MartitalStatus"

Proposal

The fix will require an update in the Figure 11.16 in the DMN specification document, but mostly a code change in the DMN model files.

Figure 11.16: Application risk score decision logic will need to be updated. An updated file will be attached at proposal creation time
A code change GitHub pull request will be raised to correct for the above, as below patch. Myself (Matteo Mortari) will raise it directly against the required GitHub repo.

diff --git a/examples/Chapter 11 Example 1 Originations/Chapter 11 Example.dmn b/examples/Chapter 11 Example 1 Originations/Chapter 11 Example.dmn
index deaf94a..f5a2b76 100644
--- a/examples/Chapter 11 Example 1 Originations/Chapter 11 Example.dmn	
+++ b/examples/Chapter 11 Example 1 Originations/Chapter 11 Example.dmn	
@@ -36,7 +36,7 @@
         <semantic:itemComponent isCollection="false" name="Age" id="_df3aab6f-1610-41fa-a407-09678a89d6da">
             <semantic:typeRef>number</semantic:typeRef>
         </semantic:itemComponent>
-        <semantic:itemComponent isCollection="false" name="MartitalStatus" id="_d39ad810-7781-4ffb-9644-de51d1ca7f7a">
+        <semantic:itemComponent isCollection="false" name="MaritalStatus" id="_d39ad810-7781-4ffb-9644-de51d1ca7f7a">
             <semantic:typeRef>string</semantic:typeRef>
             <semantic:allowedValues triso:constraintsType="enumeration">
                 <semantic:text>"S","M"</semantic:text>
@@ -1454,7 +1454,7 @@ else false</semantic:text>
             <semantic:binding>
                 <semantic:parameter id="_259966f2-bf40-4139-b587-6c9b989f1aa0" name="Marital Status"/>
                 <semantic:literalExpression id="_610941db-8c4e-483c-9d75-789b3d5c2333">
-                    <semantic:text>Applicant data.MartitalStatus</semantic:text>
+                    <semantic:text>Applicant data.MaritalStatus</semantic:text>
                 </semantic:literalExpression>
             </semantic:binding>
             <semantic:binding>
diff --git a/examples/Chapter 11 Example 2 Ranked Loan Products/Loan info.dmn b/examples/Chapter 11 Example 2 Ranked Loan Products/Loan info.dmn
index 64ae127..e9bd0c4 100644
--- a/examples/Chapter 11 Example 2 Ranked Loan Products/Loan info.dmn	
+++ b/examples/Chapter 11 Example 2 Ranked Loan Products/Loan info.dmn	
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<semantic:definitions xmlns:semantic="https://www.omg.org/spec/DMN/20191111/MODEL/" id="_5c8b9296-96cf-4898-bba5-3a2d21d34eed" name="Loan info" namespace="http://www.trisotech.com/definitions/_5c8b9296-96cf-4898-bba5-3a2d21d34eed" exporter="DMN Modeler" exporterVersion="6.2.2.3">
+<semantic:definitions id="_5c8b9296-96cf-4898-bba5-3a2d21d34eed" name="Loan info" namespace="http://www.trisotech.com/definitions/_5c8b9296-96cf-4898-bba5-3a2d21d34eed" exporter="DMN Modeler" exporterVersion="6.2.2.3" xmlns:semantic="https://www.omg.org/spec/DMN/20191111/MODEL/" xmlns="http://www.trisotech.com/definitions/_5c8b9296-96cf-4898-bba5-3a2d21d34eed">
 	<semantic:itemDefinition name="tBorrower" label="tBorrower">
 		<semantic:itemComponent id="_b7dcc14d-510d-4628-a510-ca774208e501" name="Full Name">
 			<semantic:typeRef>string</semantic:typeRef>
@@ -125,7 +125,7 @@
 		<semantic:itemComponent id="_aa55fa1a-3e82-4439-b422-21921c6a64b0" name="Monthly Insurance Payment">
 			<semantic:typeRef>number</semantic:typeRef>
 		</semantic:itemComponent>
-		<semantic:itemComponent id="_77f3b202-47ba-432b-9ada-e81700db445f" name="Monthly HOA/Condo Fee">
+		<semantic:itemComponent id="_77f3b202-47ba-432b-9ada-e81700db445f" name="Monthly HOA Condo Fee">
 			<semantic:typeRef>number</semantic:typeRef>
 		</semantic:itemComponent>
 	</semantic:itemDefinition>
@@ -204,7 +204,7 @@
 		<semantic:itemComponent id="_cd96db58-d312-41dc-a3e4-6fa93766b49d" name="Initial Monthly Payment" isCollection="false">
 			<semantic:typeRef>number</semantic:typeRef>
 		</semantic:itemComponent>
-		<semantic:itemComponent id="_c05792fd-417f-4662-b6b8-7cf708c26976" name="Quallifying Monthly Payment" isCollection="false">
+		<semantic:itemComponent id="_c05792fd-417f-4662-b6b8-7cf708c26976" name="Qualifying Monthly Payment" isCollection="false">
 			<semantic:typeRef>number</semantic:typeRef>
 		</semantic:itemComponent>
 		<semantic:itemComponent id="_30babadc-60b5-4879-b233-410b43349ef4" name="Points Amount">
diff --git a/examples/Chapter 11 Example 2 Ranked Loan Products/Recommended Loan Products.dmn b/examples/Chapter 11 Example 2 Ranked Loan Products/Recommended Loan Products.dmn
index 3c1983e..8a6e355 100644
--- a/examples/Chapter 11 Example 2 Ranked Loan Products/Recommended Loan Products.dmn	
+++ b/examples/Chapter 11 Example 2 Ranked Loan Products/Recommended Loan Products.dmn	
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<semantic:definitions xmlns:semantic="https://www.omg.org/spec/DMN/20191111/MODEL/" xmlns:tc="http://www.omg.org/spec/DMN/20160719/testcase" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   id="_736fa164-03d8-429f-8318-4913a548c3a6" name="Recommended Loan Products" namespace="http://www.trisotech.com/definitions/_736fa164-03d8-429f-8318-4913a548c3a6" exporter="DMN Modeler" exporterVersion="6.2.3" xmlns:include1="http://www.trisotech.com/definitions/_5c8b9296-96cf-4898-bba5-3a2d21d34eed">
+<semantic:definitions id="_736fa164-03d8-429f-8318-4913a548c3a6" name="Recommended Loan Products" namespace="http://www.trisotech.com/definitions/_736fa164-03d8-429f-8318-4913a548c3a6" exporter="DMN Modeler" exporterVersion="6.2.3" xmlns:semantic="https://www.omg.org/spec/DMN/20191111/MODEL/" xmlns:tc="http://www.omg.org/spec/DMN/20160719/testcase" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:include1="http://www.trisotech.com/definitions/_5c8b9296-96cf-4898-bba5-3a2d21d34eed" xmlns="http://www.trisotech.com/definitions/_736fa164-03d8-429f-8318-4913a548c3a6">
 	<semantic:import namespace="http://www.trisotech.com/definitions/_5c8b9296-96cf-4898-bba5-3a2d21d34eed" name="Services" importType="https://www.omg.org/spec/DMN/20191111/MODEL/"/>
 	<semantic:itemDefinition name="tBorrower" label="tBorrower">
 		<semantic:itemComponent id="_b7dcc14d-510d-4628-a510-ca774208e501" name="Full Name">
@@ -152,7 +152,7 @@
 		<semantic:itemComponent id="_68f6a641-5e2d-4b1b-9f2b-41f933976dee" name="Product Name" isCollection="false">
 			<semantic:typeRef>tProductName</semantic:typeRef>
 			<semantic:allowedValues>
-				<semantic:text>"Fixed30-NoPointsOrFees","Fixed30-Standard","Fixed30-LowestRate","Fixed15-NoPointsOrFees","Fixed15-Standard"</semantic:text>
+				<semantic:text>"Fixed30-NoPoints","Fixed30-Standard","Fixed30-LowestRate","Fixed15-NoPoints","Fixed15-Standard","ARM5/1-NoPoints","ARM5/1-Standard"</semantic:text>
 			</semantic:allowedValues>
 		</semantic:itemComponent>
 		<semantic:itemComponent id="_39c5300a-339c-4bde-8dfc-17e5d3f6f535" name="Type" isCollection="false">

Reported: DMN 1.2 — Tue, 7 Jan 2020 10:30 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Fix typos in example figure and XML files

The fix will require an update in the Figure 11.16 in the DMN specification document, but mostly a code change in the DMN model files.
- Figure 11.16: Application risk score decision logic will need to be updated
- Code change GitHub pull request: https://github.com/omg-dmn-taskforce/omg-dmn-spec/pull/6
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- correct.png 26 kB (image/png)
- wrong.png 37 kB (image/png)

There is no way to identify current date and time, e.g. now() & today()

Key: DMN14-42
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
We need to be able to compare to the current date and time
e.g.
Now() as a unitary test
or
Now() = a specified date and time
Reported: DMN 1.1 — Thu, 2 Jun 2016 15:54 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Add functions now() and today()

Add functions to be able to compare with the current data or time.
Updated: Thu, 31 Mar 2022 19:30 GMT

Expressions cannot be used as "end points"

Key: DMN14-11
Status: closed
Source: Red Hat Inc ( Edson Tirelli)
Summary:
The grammar does not allow expressions to be used as "endpoints" on ranges and unary tests.
Users have to create dummy variables in order to use expressions as "endpoints".
Reported: DMN 1.1 — Tue, 23 Aug 2016 01:32 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Extend ranges to support expressions as endpoints

Change the grammar to allow expressions to be used as "endpoints" on ranges and unary tests. E.g.:
{ Thanksgiving holiday: [ date(“2016-11-24”) .. date(“2016-11-27”) ] }
Updated: Thu, 31 Mar 2022 19:30 GMT

Lack of visual notation for processing of / iteration over lists in DRD

Key: DMN14-8
Status: closed
Source: Signavio GmbH ( Dr. Bastian Steinert)
Summary:
The processing of lists of data is fundamental to business decisions. Some kind of multiplicity should be indicated at the DRD level, and iteration should be supported visually at the decision logic level. In spite of the attached figures (meant to provoke discussion), the scope of this issue is limited to "flat" DRDs, that is, no "sub-DRDs" nested inside an outer decision or BKM. DRD proposal should specify what the multiplicity marker or other DRD notation looks like, and where it may appear, e.g. attached to head or tail of a requirement arrow, or inside a decision or BKM shape left of the name, etc.
Reported: DMN 1.1 — Wed, 4 May 2016 08:49 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- Cardinality.pdf 276 kB (application/pdf)
- FanProposal_JTJP.pdf 297 kB (application/pdf)
- MID.jpg 30 kB (image/jpeg)
- iteration.PNG 9 kB ()

LiteralExpression and textual expression seem to mean the same thing, need to use the same term

Key: DMN14-6
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
literal expression is used in MM, and textual expression is used in grammar. Let's use 1 consistently, but check that they are really the same concept.
Reported: DMN 1.0 — Thu, 16 Jul 2015 16:30 GMT
Disposition: Closed; No Change — DMN 1.4
Disposition Summary:
`textual expression` does not mean `Literal Expression`

There are no places where `textual expression` refers to the `literal expression` meta model element.

`textual expression` is used only in the FEEL grammar and in the refinement of Decision Tables when using FEEL (10.3.2.10 Decision Table) and it clearly refers to the FEEL grammar in that instance.

Each input expression SHALL be a textual expression (grammar rule 2). Each list of input values SHALL be an instance of unary tests (grammar rule 15).
Updated: Thu, 31 Mar 2022 19:30 GMT

Support for function types in metamodel and XSD

Key: DMN14-61
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)

Summary:

The DMN metamodel & the XSD schema do not support definition of function type. For example, a construction as the one below is not supported:

<functionDefinition name='add_type' returnType='number'>
         <parameters>
                <param name='a' typeRef='number'>
                <param name='b' typeRef='number'>
        </parameters>
</functionDefinition>

Reported: DMN 1.2b1 — Fri, 22 Feb 2019 11:57 GMT
Disposition: Closed; No Change — DMN 1.4
Disposition Summary:
Duplicates 13-7

Close - already fixed
Updated: Thu, 31 Mar 2022 19:30 GMT

Spec does not clarify meaning of hex value

Key: DMN14-56
Status: closed
Source: fujitsu america ( keith swenson)
Summary:
Rule #66 on page 111 says that a character in a string can be expressed as:

"\u", hex digit, hex digit, hex digit, hex digit

For example "\uD83D"

That is, exactly four hex digits. I believe the intent is that FEEL only allows exactly four digits, and does not allow the kinds of expressions that we see in the EBNF.

What is never specified is the exact meaning of that hex value. There are two possibilities:

(a) Is that value a Unicode code point? In this case it is easy, the hex value is the code point value, however because you are limited to 64K characters, and not the 1.1M character range normally considered, and not even the values that are mentioned in the spec as having significance.

(b) Or is it a UTF-16 code value? UTF-16 has encoding rules about values in the surrogate character range. In UTF-16 a high-surrogate-code value must be followed by a low-surrogate-code value or else the sequence of values is invalid and undefined. Using surrogate characters you can address the entire 1.1million characters but the user is required to understand about surrogate pairs.

The spec never mentions that UTF-16 encoding is required! It always uses "Unicode" and talks about "characters" and "code points". It does not mention anything about surrogate pairs. It never says that these values a "just like Java" or any other UTF-16 implementation.

Page 124 says that the FEEL string value is the same as java.lang.String. Should we infer from that that internal representations must be in UTF-16? however it also says that it is equivalent to an XML string (which is NOT constrained to UTF-16) and PMML string which I looked up and seems to be based on XML. XML allows characters to be expressed as &#nnnn ; That is an ampersand, a hash, a decimal number, terminated by a semicolon. In this case, the decimal value is the actual code point, and not the UTF-16 value. So page 124 does not say unambiguously that Java defines the string values that can be used.

Unicode is mentioned only in three places: on page 108 (about EBNF character ranges), page 111 that tokens are a sequence of unicode characters, page 114 in an example.

While it might be nice to be a "code point", the syntax clearly limits you to four digits leaving you no way to express larger code point values. If it was a code point you would be limited to only specifying 64,000 character (minus several thousand code points that not allowed for various reasons).

The easiest repair is to state clearly that the \u notation assumes that UTF-16 is being used to encode the strings, and that UTF-16 rules must be used when specifying hex values for characters.

I believe most implementations to date have assumed that these are UTF-16 code unit values. That is what Java does. That is what JavaScript does. I don't know of any environments that do anything different for this kind of expression.
Reported: DMN 1.2b1 — Fri, 8 Feb 2019 18:33 GMT
Disposition: Closed; No Change — DMN 1.4
Disposition Summary:
Hex values are already properly defined in DMN 1.3

The issue has been discussed and fixed in DMN 1.3 - ballot #10
https://issues.omg.org/browse/DMN13/fixforversion/14682?selectedTab=org.omg.jira.task-forces%3Ataskforce-ballot-panel

https://issues.omg.org/browse/DMN13-127
https://issues.omg.org/browse/DMN13-143
Updated: Thu, 31 Mar 2022 19:30 GMT

Definitions of overlaps functions

Key: DMN14-125
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
It looks like the logic definitions of functions overlaps and overlaps before do not produce the results expected in the Example column.

The expected results look correct to me. I believe we need to fix the second column for overlaps and overlaps before as follows:

For overlaps before:
(range1.start < range2.start or (range1.start = range2.start and (range1.start included and not(range2.start included))))
and (range1.end > range2.start or (range1.end = range2.start and range1.end included and range2.start included))
and (range1.end < range2.end or (range1.end = range2.end and (not(range1.end included) or range2.end included )))

For overlaps:
overlapsBefore(range1, range2)
or overlapsAfter(range1, range2),
or includes(range1, range2),
or includes(range2, range1)
and leave the implementation to optimize the formula if needed.
Reported: DMN 1.3 — Mon, 4 Jan 2021 11:36 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
less intrusive change to fix the "overlaps before", "overlaps" built-in functions

The less intrusive change to fix the "overlaps before" is to fix the typo at the 7th row of the formula to align it with being the analogous of the "overlaps after",

Then, the less intrusive change to fix the "overlaps" is to fix rows 5,6,7 of the formula.

This would keep the original request that each built-in is standalone if possible and not derived from other built-in.

I believe these are the minimal modifications required to fix the problem but keep the original format.
I believe in the previous cycle with all editorial discussions like the parameter renames, these things slipped through.
Big kudos to Octavian Patrascoiu for pointing it out!! +1
Updated: Thu, 31 Mar 2022 19:30 GMT

Convenience documents

Key: DMN14-45
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
This issue was used by the DMN 1.3 RTF to store the latest version of the convenience documents. The issue got rolled over to 1.4 when the 1.3 JIRA project was closed. However, it has no relevance for 1.4 and does not identify a problem with the spec that needs addressing.

Edits applied to DMN1.2 towards 1.3
Reported: DMN 1.2b1 — Mon, 29 Apr 2019 22:13 GMT
Disposition: Closed; No Change — DMN 1.4
Disposition Summary:
Close DMN 1.3 spec placeholder issue

This issue was used by the DMN 1.3 RTF to store the latest version of the convenience documents. The issue got rolled over to 1.4 when the 1.3 JIRA project was closed. However, it has no relevance for 1.4 and does not identify a problem with the spec that needs addressing.
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- DMN 1.3 AB review 1 markup.pdf 8.76 MB (application/pdf)
- DMN 1.3 AB review 1.pdf 8.67 MB (application/pdf)
- DMN 1.3 AB review 2 markup.pdf 8.85 MB (application/pdf)
- DMN 1.3 AB review 2.pdf 8.76 MB (application/pdf)
- DMN 1.3 ballot 10 markup.pdf 9.69 MB (application/pdf)
- DMN 1.3 ballot 10.pdf 9.34 MB (application/pdf)
- DMN 1.3 ballot 11 markup.pdf 9.72 MB (application/pdf)
- DMN 1.3 ballot 11.pdf 9.39 MB (application/pdf)
- DMN 1.3 ballot 12 markup.pdf 8.88 MB (application/pdf)
- DMN 1.3 ballot 12.pdf 8.80 MB (application/pdf)
- DMN 1.3 ballot 13 markup.pdf 8.75 MB (application/pdf)
- DMN 1.3 ballot 13.pdf 8.72 MB (application/pdf)
- DMN 1.3 ballot 14 markup.pdf 8.36 MB (application/pdf)
- DMN 1.3 ballot 14.pdf 8.32 MB (application/pdf)
- DMN 1.3 ballot 15 markup.pdf 8.86 MB (application/pdf)
- DMN 1.3 ballot 15.pdf 8.76 MB (application/pdf)
- DMN 1.3 ballot 7 markup.pdf 7.01 MB (application/pdf)
- DMN 1.3 ballot 7.pdf 6.78 MB (application/pdf)
- DMN 1.3 ballot 8 markup.pdf 6.67 MB (application/pdf)
- DMN 1.3 ballot 8.pdf 6.50 MB (application/pdf)
- DMN 1.3 ballot 9 markup.pdf 7.03 MB (application/pdf)
- DMN 1.3 ballot 9.pdf 6.71 MB (application/pdf)
- examples.zip 2.00 MB (application/zip)

Typo in horizontal alignment label

Key: DMN14-137
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
Spec say "labelHorizontalAlignement". Should be "labelHorizontalAlignment". The corresponding vertical property is correct at "labelVerticalAlignment".
Reported: DMN 1.3 — Fri, 19 Feb 2021 09:12 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Fix typo

Fix typo "labelHorizontalAlignement"
Updated: Thu, 31 Mar 2022 19:30 GMT

Wrong example for is() built-in function

Key: DMN14-86
Status: closed
Source: Red Hat ( Matteo Mortari)

Summary:

Executive summary

I believe the last example for the is() built-in function of DMNv1.3 is wrong.

Details

The example from DMNv1.3 which I believe is wrong is:
is(time("23:00:50z"), time("23:00:50+00:00”)) is false

Besides that is not FEEL and not consistent with the other examples, but likely it is meant to be humanly interpreted as is(time("23:00:50z"), time("23:00:50+00:00”)) = false which I argue is wrong semantically.

Accordingly to 10.3.2.3.4 time:

A time in the semantic domain is a value of the XML Schema time datatype. It can be represented by a sequence of numbers for the hour, minute, second, and an optional time offset from Universal Coordinated Time (UTC).

Understanding from this first sentence is that in the FEEL semantic domain time is defined by time: H, M, S, OFFSET?

it continues with:

If a time offset is specified, including time offset = 00:00, the time value has a UTC form and is comparable to all time values that have UTC forms.
If no time offset is specified, the time is interpreted as a local time of day at some location,

So we can have in the FEEL semantic domain a

time: H, M, S, no offset specified "local time of day at some location"
or
time: H, M, S, OFFSET

This is consistent with 10.3.4.1 Conversion functions:

time string – either
a string value in the lexical space of the time datatype specified by XML Schema Part 2 Datatypes; or
a string value that is the extended form of a local time representation as specified by ISO 8601, followed by the character "@", followed by a string value that is a time zone identifier in the IANA Time Zones Database (http://www.iana.org/time-zones)

Therefore:
if we are in the first case by XML Schema Part 2 Datatypes we will have an offset if something follow the ":ss" seconds part in the string,
otherwise,
if we use the second case "hh:mm:ss@location" form, we will not have an XML Schema Part 2 Datatypes offset, but we will interpret the time at some geographical location offset based on IANA.

Follows interpretation of a few examples of time strings, and their FEEL semantic domain projection:

time string	10.3.4.1 Conversion functions time string first or second case?	H	S	specified OFFSET?	OFFSET because XML Schema Part 2	OFFSET because IANA Time Zones Database
"23:00:50"	first case	23	50	no	null	null
"23:00:50@Europe/Rome"	second case	23	50	yes	null	Europe/Rome
"23:00:50@Europe/Paris"	second case	23	50	yes	null	Europe/Paris
"23:00:50+02:00"	first case	23	50	yes	+2	null
"23:00:50+00:00"	first case	23	50	yes	+0	null
"23:00:50Z"	first case	23	50	yes	+0	null

Accordingly to DMNv1.3 they will be all equals as in a=b (as valuet() does return the same for all of them).

Accordingly to DMNv1.3 they are all FEEL semantically domain different expect the last two, because once projected to the semantic domain they represent the same hour, minute, second, AND offset quantity, accordingly to a string value in the lexical space of the time datatype specified by XML Schema Part 2 Datatypes.

Hence, resulting in

is(time("23:00:50z"), time("23:00:50+00:00")) = true

instead.

Proposal

change last line example from:

is(time("23:00:50z"), time("23:00:50+00:00”)) is false

is(time("23:00:50z"), time("23:00:50+00:00")) = true

Reported: DMN 1.3 — Tue, 7 Apr 2020 12:58 GMT
Disposition: Resolved — DMN 1.4

Disposition Summary:

Correct table 77

change last line example from:

is(time("23:00:50z"), time("23:00:50+00:00”)) is false

is(time("23:00:50z"), time("23:00:50+00:00")) is true

Updated: Thu, 31 Mar 2022 19:30 GMT

Wrong example for distinct values() built-in function

Key: DMN14-85
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
this is a typo fix: the example is missing a closed round paren.

Proposal

with reference to DMNv1.3 dtc/19-12-06 in chapter 10.3.4.4 List functions page 161 replace:
distinct values([1,2,3,2,1] = [1,2,3]
with
distinct values([1,2,3,2,1]) = [1,2,3]
Reported: DMN 1.3 — Tue, 7 Apr 2020 08:17 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Fix typo on distinct values() function example

See revised text.
Updated: Thu, 31 Mar 2022 19:30 GMT

Wrong XSD for tDecisionService

Key: DMN14-93
Status: closed
Source: Red Hat ( Matteo Mortari)

Summary:

With refererence to DMNv1.3 dtc-19-12-06
Chapter 6.3.10 Decision service metamodel
page 64

the table
Table 17: DecisionService attributes and model associations

reports:

outputDecisions: Decision [1..*]

but the XSD schema:

<xsd:element name="outputDecision" type="tDMNElementReference" minOccurs="0" maxOccurs="unbounded"/>

Proposal

change XSD from:

<xsd:element name="outputDecision" type="tDMNElementReference" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element name="outputDecision" type="tDMNElementReference" minOccurs="1" maxOccurs="unbounded"/>

(minOccurs to 1)

Reported: DMN 1.3 — Fri, 5 Jun 2020 06:49 GMT
Disposition: Closed; No Change — DMN 1.4
Disposition Summary:
Need to allow interchange of incomplete models

No change
Updated: Thu, 31 Mar 2022 19:30 GMT

First (and priority) hit policy are unpredictable with partial input

Key: DMN14-88
Status: closed
Source: Moxio ( Merijn Wijngaard)
Summary:
A decision table with a hit policy of FIRST uses rule order to decide its output, but only among those rules which have an output. This works fine when the input is complete, but becomes unpredictable when input is partial. Higher priority rules (earlier in the order) may not have an output yet while lower priority rules do, even when higher priority rules may generate an output in the future when more input become available. This makes the FIRST hit policy (the same goes for PRIORITY) not usable in a context where the decision logic will be run on partial, incrementally expanded input (e.g. an interactive expert system).

When reading the description for the FIRST hit policy in the spec, I get the feeling that the OMG is opposed to having rule order play a role in the evaluation of a decision table. I realize there are ways around using rule order by using different hit policies and separating the logic into multiple decision tables, but I do believe that that would not improve the understandability of the logic. Having the rule order play a role in the evaluation of a decision table can definitely make them more self-contained (decision tables are smaller and/or logic is less spread out), and therefore easier to write and understand in some cases. But an implementation that uses rule order needs to be predictable, even on partial input.

Therefore I would like to propose an addition to the existing hit policies: ELIMINATE (or at least i think that term describes it well).

The ELIMINATE hit policy evaluates a decision table's rules in order:
- If a rule is validated (it matches), it produces an output and evaluation is stopped
- If a rule is invalidated (it will never match, even as more input becomes available), evaluation continues with the next rule (i.e. it is eliminated)
- If a rule cannot be invalidated (because input is partial), evaluation is stopped and the table produces no output
- A decision table with a hit policy of ELIMINATE can only ever produce a single output
I hope you will consider adding this to the spec in some form or another, since it would make working with dmn in a context of incrementally expanding input a lot easier.
Reported: DMN 1.3 — Fri, 29 May 2020 08:30 GMT
Disposition: Closed; No Change — DMN 1.4
Disposition Summary:
Hit policies work as designed with partial data

The decision services designed using DMN are meant to be stateless. Therefore when the partial data is submitted the first hit table behaves correctly, given the partial data. When the more complete data is submitted, it behaves differently but still correctly. The fact that the table behaves differently given different submitted data sets seems completely reasonable and we don't see the need for another hit policy.
Updated: Thu, 31 Mar 2022 19:30 GMT

Extend endpoints to support expressions

Key: DMN14-136
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Currently enpoints can be only simple values (e.g. simple literals such as 123 or qualified names).

This proposal is about extending the endpoints to be expressions. For example ranges such as [x, x+2) would be supported.

Proposal:

Page 120 Section 10.3.1.2. Grammar rules

Replace

16. endpoint = simple value ;

with

16. endpoint = expression ;
Reported: DMN 1.3 — Tue, 9 Feb 2021 17:38 GMT
Disposition: Duplicate or Merged — DMN 1.4
Disposition Summary:
Close as duplicate

Duplicate of ~~DMN14-11~~
Updated: Thu, 31 Mar 2022 19:30 GMT

Clarify method signature syntax for Java Function Definition

Key: DMN14-52
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
For example, java.lang.Object[]
Instead of
[Ljava.lang.Object;
Also, what if some of the argument or result types have no defined FEEL mapping. Need some kind of recursive definition.
Reported: DMN 1.2 — Mon, 20 May 2019 15:12 GMT
Disposition: Closed; No Change — DMN 1.4
Disposition Summary:
Out of date. Issue already addressed in DMN 1.3.

This ticket is out of date. Problem was already addressed in DMN 1.3.
Updated: Thu, 31 Mar 2022 19:30 GMT

DMN string join built-in function proposal

Key: DMN14-116
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
This is a proposal for a new DMN built-in function to join a list of strings, for which currently the specification does not offer any out-of-the-box support.

This is partially connected to OMG DMN RTF https://issues.omg.org/browse/DMN14-34, but it focuses only on a specific one, between of those functions.

Assessment

As of DMNv1.3 the specification is not offering any built-in support for the use-case of concatenating a list of strings into a final string.

Please notice this is not the use case of using the “+” operator as in:
first name + " " + last name
This is the use case of joining a list of strings, for example
[ "product 1", "product 2", ... ]
In the book “DMN Cookbook: 50 Decision Modeling Recipes to Accelerate Your Business Rules” by Bruce Silver and Edson Tirelli ISBN: 9780982368183, the authors are offering 3 working solutions in Chapter 4.2. This requires however the modeler to implement manually or in a “personal library” of BKMs the preferred solution.

The Signavio platform is offering it as a custom function (https://documentation.signavio.com/suite/en-us/Content/process-manager/userguide/dmn-literal-expressions.htm#concat) which however is only available on that specific platform.

It is likely other Vendors are offering this functionality in their own way.

This is an opportunity for the RTF to standardize what different people are doing differently, and not currently covered in the DMN spec.
Reported: DMN 1.3 — Tue, 15 Dec 2020 12:35 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Add String join function

This is a proposal for a new DMN built-in function to join a list of strings, for which currently the specification does not offer any out-of-the-box support.

This is partially connected to OMG DMN RTF https://issues.omg.org/browse/DMN14-34, but it focuses only on a specific one, between of those functions.

Assessment

As of DMNv1.3 the specification is not offering any built-in support for the use-case of concatenating a list of strings into a final string.

Please notice this is not the use case of using the “+” operator as in:
first name + " " + last name
This is the use case of joining a list of strings, for example
[ "product 1", "product 2", ... ]
In the book “DMN Cookbook: 50 Decision Modeling Recipes to Accelerate Your Business Rules” by Bruce Silver and Edson Tirelli ISBN: 9780982368183, the authors are offering 3 working solutions in Chapter 4.2. This requires however the modeler to implement manually or in a “personal library” of BKMs the preferred solution.

The Signavio platform is offering it as a custom function (https://documentation.signavio.com/suite/en-us/Content/process-manager/userguide/dmn-literal-expressions.htm#concat) which however is only available on that specific platform.

It is likely other Vendors are offering this functionality in their own way.

This is an opportunity for the RTF to standardize what different people are doing differently, and not currently covered in the DMN spec.
Updated: Thu, 31 Mar 2022 19:30 GMT

FEEL ambiguity

Key: DMN14-36
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
FEEL grammar is ambiguous. Rule 2.i is ambiguous for identifiers like Person, as it can lead to two parse trees, one with QualifiedName the other with Name in it. See rule for simple value.

Rule 1 is ambiguous as there is an overlap between textual expression and boxed expression. I suggest breaking the grammar in several grammars with a common part. This ambiguity will just go away as soon as we do that.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:41 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Fix FEEL grammar ambiguity

Fix some ambiguities in the FEEL grammar (several different parse trees for same inputs) For example, 123 can be a literal or simple positive unary test when the start symbol is expression.
Updated: Thu, 31 Mar 2022 19:30 GMT

Wrong character in expression for PMT function definition

Key: DMN14-20
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
The expression of the PMT function contains an invalid character and is therefore not executable. The first minus character is a dash, but shouldn't.

(amount rate/12) / (1 – (1 + rate/12)*-term)

Fixed:

(amount rate/12) / (1 - (1 + rate/12)*-term)
Reported: DMN 1.1 — Fri, 2 Feb 2018 10:32 GMT
Disposition: Closed; No Change — DMN 1.4
Disposition Summary:
Corrected by ~~DMN14-97~~

Duplicate issue - already corrected by ~~DMN14-97~~
Updated: Thu, 31 Mar 2022 19:30 GMT

BigDecimal is not the only mapping of number to Java

Key: DMN14-1
Status: closed
Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
Summary:
Clause 10.3.2.9 shows FEEL number values as mapped to XML decimal, integer, and double, but the only mapping to Java is to BigDecimal. The appropriate mapping to Java, like the appropriate mapping to XML, depends on the range and intent of the data element. BigDecimal is rarely used for anything but currency. Java int and double are much more likely to be appropriate for most data items. The mapping of number to Java should be just as flexible as the mapping to XML and PMML.
Reported: DMN 1.0 — Wed, 9 Jul 2014 21:23 GMT
Disposition: Closed; No Change — DMN 1.4
Disposition Summary:
BigDecimal is not the only mapping of numbers in Java

The use of other number types in Java can be done by implementing engine optimizations, as long as the overall semantics of FEEL numbers is supported.
Updated: Thu, 31 Mar 2022 19:30 GMT

DMN 1.3 Metamodel

Key: DMN14-46
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
This issue was used by the DMN 1.3 RTF to store the latest version of all metamodel files. The issue got rolled over to 1.4 when the 1.3 JIRA project was closed. However, it has no relevance for 1.4 and does not identify a problem with the spec that needs addressing.

Magic draw files for DMN and DMNDI (diagrams).
The ones with .mdzip suffix and with MagicDraw in the name should be equivalent (both are magic draw formats).
The ones with XMI in the name should be "clean", but some manual fiddling is usually required. I tried to do said fiddling, but no guarantees. Pete Rivett has been helpful in the past.
These were created with Magicdraw 17.0.5. It is out of date, but it's all I have a license for.
The .svg files should be used for all the class diagram figures.
Reported: DMN 1.2b1 — Mon, 7 Oct 2019 23:16 GMT
Disposition: Closed; No Change — DMN 1.4
Disposition Summary:
Close DMN 1.3 MM placeholder issue

This issue was used by the DMN 1.3 RTF to store the latest version of all metamodel files. The issue got rolled over to 1.4 when the 1.3 JIRA project was closed. However, it has no relevance for 1.4 and does not identify a problem with the spec that needs addressing.
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- Class_Diagram__DMN_DI.svg 32 kB (image/svg+xml)
- Class_Diagram__DMN_Diagram.svg 137 kB (image/svg+xml)
- Class_Diagram__DMN_Diagram_Element.svg 75 kB (image/svg+xml)
- Class_Diagram__DMN_Edge.svg 79 kB (image/svg+xml)
- Class_Diagram__DMN_Label.svg 50 kB (image/svg+xml)
- Class_Diagram__DMN_Shape.svg 140 kB (image/svg+xml)
- Class_Diagram__DMN_Style.svg 186 kB (image/svg+xml)
- Class_Diagram__DMN__BKM.svg 194 kB (image/svg+xml)
- Class_Diagram__DMN__BusinessContext.svg 166 kB (image/svg+xml)
- Class_Diagram__DMN__DMNElement.svg 325 kB (image/svg+xml)
- Class_Diagram__DMN__Decision.svg 431 kB (image/svg+xml)
- Class_Diagram__DMN__DecisionService.svg 112 kB (image/svg+xml)
- Class_Diagram__DMN__DecisionTable.svg 473 kB (image/svg+xml)
- Class_Diagram__DMN__Definitions.svg 368 kB (image/svg+xml)
- Class_Diagram__DMN__Expressions.svg 259 kB (image/svg+xml)
- Class_Diagram__DMN__ExpressionsL3.svg 209 kB (image/svg+xml)
- Class_Diagram__DMN__Extensibility.svg 95 kB (image/svg+xml)
- Class_Diagram__DMN__InputData.svg 61 kB (image/svg+xml)
- Class_Diagram__DMN__ItemDefinition.svg 149 kB (image/svg+xml)
- Class_Diagram__DMN__KnowledgeSource.svg 188 kB (image/svg+xml)
- DMN13.mdzip 169 kB ()
- DMN13.xsd 23 kB (text/xml)
- DMN13_MagicDraw.xml 821 kB (application/xml)
- DMN13_XMI.xml 153 kB (application/xml)
- DMNDI13.mdzip 87 kB ()
- DMNDI13.xsd 5 kB (text/xml)
- DMNDI13_MagicDraw.xml 256 kB (application/xml)
- DMNDI13_XMI.xml 35 kB (application/xml)

Wrong example for 10.6.1 Context Figure 10.18: Example context

Key: DMN14-73
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
This is taken from the DMN spec :
(amount *rate/12) / (1 – (1 + rate/12)**-term)
however this would fail to parse correctly as the first subtraction sign is an "en-dash" (0x2013) and not a minus/hyphen sign (0x2D)
(amount *rate/12) / (1 – (1 + rate/12)**-term) ^ (amount *rate/12) / (1 - (1 + rate/12)**-term)
this "en-dash" can be confused easily, especially depending on the font used, but as an end result cannot be copy-pasted from the PDF/Word of the DMN specification into an editor, and in essence is a wrong FEEL expression.

Proposal

with reference to DMNv1.3 dtc/19-12-06 in chapter Wrong example for 10.6.1 Context Figure 10.18: Example context page 177 replace:

(amount rate/12) / (1 – (1 + rate/12)*-term)

with

(amount rate/12) / (1 - (1 + rate/12)*-term)

(for the editor, please be aware MS Word might be tempted to replace the minus sign in "1 - ( 1 +" with an en-dash character, but this being FEEL code expression must be a minus sign)
Reported: DMN 1.2 — Tue, 7 Jan 2020 09:47 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Correct Context Figure 10.6.1

with reference to DMNv1.3 dtc/19-12-06 in chapter Wrong example for 10.6.1 Context Figure 10.18: Example context page 177 replace:

(amount * rate/12) / (1 – (1 + rate/12)**-term)

with

(amount * rate/12) / (1 - (1 + rate/12)**-term)

(for the editor, please be aware MS Word might be tempted to replace the minus sign in "1 - ( 1 +" with an en-dash character, but this being FEEL code expression must be a minus sign)
Updated: Thu, 31 Mar 2022 19:30 GMT

Wrong example for substring() builtin funciton

Key: DMN14-72
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
the example is wrong and needs a fix as it compares to "ab", besides the incorrect representation of the emoji for the horse in the PDF/Word document; proposed below

Proposal

with reference to DMNv1.3 dtc/19-12-06 in chapter 10.3.4.3 String functions
Table 74: Semantics of string functions page 158 replace:

substring("\U01F40Eab ", 2) = "ab" where "\U01F40Eab "

with

substring("\U01F40Eab", 2) = "ab" where "\U01F40Eab"

(the characters inside double-quote of the example should not end with a trailing space)

Also the "ὀ" character in the PDF/Word document is actually meant to be the emoji for the horse. JIRA does not allow to place the horse emoji in this text fields, so the emoji can be copy-pasted from here: https://emojipedia.org/horse/ inside the DMN specification new document.
Reported: DMN 1.2 — Tue, 7 Jan 2020 09:18 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Remove space from substring() example

with reference to DMNv1.3 dtc/19-12-06 in chapter 10.3.4.3 String functions
Table 74: Semantics of string functions page 158 replace:

substring("\U01F40Eab ", 2) = "ab" where "\U01F40Eab "

with

substring("\U01F40Eab", 2) = "ab" where "\U01F40Eab"

(the characters inside double-quote of the example should not end with a trailing space)

Also the "ὀ" character in the PDF/Word document is actually meant to be the emoji for the horse. JIRA does not allow to place the horse emoji in this text fields, so the emoji can be copy-pasted from here: https://emojipedia.org/horse/ inside the DMN specification new document.
Updated: Thu, 31 Mar 2022 19:30 GMT

Wrong example snippet in 10.3.2.9.4.1 Examples

Key: DMN14-75
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
this is a typo fix.
"typeRef" from XSD is meant with capital R.

Proposal

with reference to DMNv1.3 dtc/19-12-06 in chapter 10.3.2.9.4.1 Examples page 135 replace:
<variable name="decision_003" typeref="number"/>
with
<variable name="decision_003" typeRef="number"/>
Reported: DMN 1.2 — Tue, 7 Jan 2020 08:39 GMT
Disposition: Resolved — DMN 1.4
Disposition Summary:
Fix typo in XML snippet

Replace typeref with typeRef
Updated: Thu, 31 Mar 2022 19:30 GMT

Enumerations can only be defined as strings

Key: DMN14-23
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
Item Definitions can share constraints and these constraints are specified as unary tests. This allows definitions such as requiring a positive number ( >0) or restricting a field to a specific value ("high", "medium", "low").

However this requires enumerations to be strings and does not allow enumerations to be managed (sorted for instance). In addition, an enumerated list might be used for a set of Information Items but it must be repeated in Decision Tables when columns are meant to be restricted to the list of values.

DMN should allow for the creation and management of enumerations:
- Name
- Description (optional)
- List of enumerated values (optionally with a sort order)
These enumerations should be considered symbolic constants, not strings

FEEL functions should be created to:
Get the list of of allowed values for a specified enumeration
Check a value against an enumeration to see if it is an allowed value for that enumeration
Check the sort order of some specified values in the context of an enumeration

Decision Tables should be able to reference an enumeration by name in the value list row
Information Items should be able to be linked to an enumeration
Reported: DMN 1.1 — Thu, 26 Oct 2017 16:12 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Lexical representation of time string has ambiguous definitons

Key: DMN14-22
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
A lexical time string is defined o page 131 by XML Schema Part 2 Datatypes (for local times and offset times) and by ISO 8601 with the extended form of a local time (for zoned times).

Unfortunately XML Schema Part 2 and ISO 8601 has different definitions. Therefore it is unclear which of them to use. Or are both of them valid?

Additionally the user should not have different lexical time string formats for a local time, an offset time or a zoned time.

The list of ambiguities:
- ISO 8601 allows a leading "T" character prefix. XML Schema Part 2 does not.
- ISO 8601 allows optional seconds. In XML Schema Part 2, the seconds are mandatory.
- ISO 8601 allows decimal fraction for seconds and minutes. XML Schema Part does not allow this.
- ISO 8601 allows 00:00:00 and 24:00:00 for midnight. XML Schema Part 2 only allows 00:00:00.
- ISO 8601 allows time offset of hours only. Minutes are optional. XML Schema Part 2 always requires minutes.
Therefore clarification is needed. Which definitions are valid for FEEL? The stricter XML Schema Part 2 or the more user friendly ISO 8601 spec?
Reported: DMN 1.1 — Mon, 13 Nov 2017 15:24 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Add two new concrete numeric types, make number abstract

Key: DMN14-21
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Currently S-FEEL / FEEL contains only one single numeric type called number that matches the semantics defined in IEEE 754-2008.

This can lead to some strange constructions, such as
substring("footbar", 3.67)
perfect valid in FEEL.

It also has impact on the performance of the execution (speed).

Here is my proposal:
- keep number as an abstract type to backwards compatibility
- add a new concrete type real/float/decimal that matches the semantics of defined in IEEE 754-2008
- add a new concrete type integer
- change the signature of all built-in functions to restrict number to integer when it makes sense (e.g. index in a string and list, length of string. size of list)
- add a separate paragraph to specify the implicit conversions performed by the FEEL processor when required (e.g. function resolution). For example,
  2 + 4.5 leads to a promotion 2 -> 2.0 that adding it 4.5.
If we agree in principal all start working on it.
Reported: DMN 1.1 — Wed, 6 Dec 2017 13:44 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Can the same Definitions/namespace be used by more than one model?

Key: DMN14-19
Status: closed Implementation work Blocked
Source: Red Hat ( Edson Tirelli)
Summary:
Please clarify if it is possible to have multiple models on the same namespace. For instance:

<definitions namespace="http://my.company/financeModels" name="Model A" ...

<definitions namespace="http://my.company/financeModels" name="Model B" ...

The current text of the specification does not say anything explicitly one way or another, so please clarify that.

In addition to this, if multiple models can use the same namespace, then the <import> element will require an additional attribute (for instance: modelName) in order to uniquely identify which model should be imported.
Reported: DMN 1.1 — Thu, 8 Mar 2018 16:20 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Improve description of built-in function string()

Key: DMN14-18
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
The expected output of the built-in function string() should be defined for each type. Otherwise it is unclear what the result for a value, for example of type time, is. Is it the string literal or the full expression with built-in function time()?
// which FEEL expression is valid? string(time("11:00:00")) = "11:00:00" string(time("11:00:00")) = "time("11:00:00")"
Recommendation: Introduce a new table that lists example outputs for all types:
- null -> null
- boolean -> "true" or "false"
- string -> "This is a string"
- number -> "-1.234"
- date -> "2017-10-11"
- time -> "11:00:00.123" or "11:00:00.123+02:00" or "11:00:00.123@Europe/Paris"
- date and time -> "2017-10-11T11:00:00.123" or "2017-10-11T11:00:00.123+02:00" or "2017-10-11T11:00:00.123@Europe/Paris"
- days and time duration -> "P2DT3H4M5.123S"
- years and months duration -> "P2Y3M"
- list -> "[1,2,3]"
- context -> "{a: true, b: false}"
- range -> "[1..100]"
- unary test -> "> 10"
- function -> null
Reported: DMN 1.1 — Wed, 11 Oct 2017 09:02 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Clarification needed if null is passed as value for optional parameter of built in function

Key: DMN14-17
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Some built-in functions has optional parameters. Chapter 10.3.4 describes "Whenever a parameter is outside its domain, the result of the built-in is null."

Should the following call to a built-in function result to null?
replace("This is a string", "[a-z]", "#", null)
The optional parameter "flags" of the built-in function replace() is null. Parameter domain is string as stated in table 60 on page 133. Null is not in the domain of type string.

This topic was already discussed in the DMN TCK. We think that the behavior should be the same as the function is called without the optional parameter:
replace("This is a string", "[a-z]", "#", null) = replace("This is a string", "[a-z]", "#")
Clarification in the specification is appreciated.

May be we can change the sentence in chapter 10.3.4 on page 130 to: "Whenever a parameter is outside its domain, the result of the built-in is null. If null is passed as value to an optional parameter, the built-in behaves like no value is passed."
Reported: DMN 1.1 — Tue, 10 Oct 2017 14:32 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration

Key: DMN14-16
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Chapter 10.3.2.3.4 time, 10.3.2.3.5 date, 10.3.2.3.6 date-time, 10.3.2.3.7 days and time duration and chapter 10.3.2.3.8 years and months duration defines each a value function. For date time arithmetic operations it would be useful to have this value available in the FEEL semantic domain. Therefore we suggest to add a new property value that is directly available for values of this type. Return type of the value if always a number.

Table 53 should be adjusted accordingly.
Reported: DMN 1.1 — Tue, 10 Oct 2017 09:57 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Should encapsulated decisions of a decision service include output decisions?

Key: DMN14-14
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Figure 10 on page 25 with text "The encapsulated decisions are therefore
{Decision 1, Decision 2}
"

Figure 11 on page 26 with text "The encapsulated decisions for this services are
{Decision 1}
".

Table 20 on page 56:
- "outputDecisions: This attribute lists the instances of Decision required to be output by this DecisionService".
- "encapsulatedDecisions: If present, this attribute lists the instances of Decision to be encapsulated in this DecisionService".
For us it is unclear what decisions should be stored in the DMN model as encapsulated decisions. Must the output decisions also be included in the list of encapsulated decisions (as stated on page 25, 26)? Or does the list of encapsulated decisions only hold the decisions contained in the lower compartment of a decision service (as mentioned on 56 since encapsulatedDecisions seems to be optional)?
Reported: DMN 1.0 — Tue, 20 Mar 2018 14:49 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions

Key: DMN14-13
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
In Figure 6.15 the multiplicity of output decisions for a decision service is shown as zero to many (0..), but the text below and Table 16 says the that multiplicity is one to many (1..). The figure should be correct to match the text and table.
Reported: DMN 1.1 — Fri, 3 Aug 2018 21:19 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Enhancement suggestion: make unary tests first class citizens of the FEEL language

Key: DMN14-12
Status: closed
Source: Red Hat Inc ( Edson Tirelli)
Summary:
This is a suggestion for future versions of the spec:

Add support for Unary Tests as first class citizens of the FEEL language, in a similar way as ranges and functions already are.

A unary test is really a “predicate”: a single parameter function that returns a boolean. It is syntax sugar on:

function ( x ) x in <unary_test>

FEEL already supports functions as first class citizens, so it makes sense to support Unary Tests. The following two syntaxes would then be equivalent:

is minor : < 18
is minor : function( age ) age in < 18

Invoking unary tests explicitly would be like invoking a function:

Bob is minor : is minor( bob.age )

More importantly, it would allow the implementation to actually support passing unary tests as parameters to functions and make the example on page 115 viable:

decision table (
outputs: "Applicant Risk Rating",
input expression list: [Applicant Age, Medical History],
rule list: [
[ >60, "good", "Medium" ],
[ >60, "bad", "High" ],
[ [25..60], -, "Medium" ],
[ <25, "good", "Low" ],
[ <25, "bad", "Medium" ]
],
hit policy: "Unique"
)

Unary test syntax is not ambiguous, so supporting it would mean to basically change rule 2 in the grammar to include rules 14 and 17 as possible options. The semantic mapping table on page 116 would also need to include a new FEEL value type: "unary test".
Reported: DMN 1.1 — Tue, 23 Aug 2016 01:41 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Include Test Cases in Decision Model

Key: DMN14-10
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
For interchange of test cases along with a decision model, it would be convenient to define metamodel and xsd elements for a suite of test cases, where a test case contains values for input data and expected values output decisions.
Reported: DMN 1.1 — Sat, 28 May 2016 16:25 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- testCases.xsd 3 kB (text/xml)

Change depiction of Input to be harmonized with BPMN and CMMN

Key: DMN14-9
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
As OMG promotes the integrated use of DMN with BPMN and CMMN, it is proposed to change the depiction of Input in DMN to be the paper Shape with folded corner. We can envision end users wanting to embed DMN diagrams into BPMN or CMMN diagrams. This change would provide better notational alignment with Data Object and Case File Iems in BPMN and CMMN. Futhermore is would remove the notation conflict currently existing between DMN Input and CMMN Milestone.
Reported: DMN 1.1 — Mon, 16 May 2016 14:26 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- BPMN Data Object DMN Data Input.PNG 86 kB ()
- CaseFileItem.png 0.9 kB (image/png)
- Depiction of Input Data conflict with BPMN and CMMN.png 239 kB (image/png)
- Milestone.png 2 kB (image/png)
- bpmn-figure-087.Data Object Reference.png 0.9 kB (image/png)
- bpmn-figure-088.Data Object Reference Collection.png 0.9 kB (image/png)
- bpmn-figure-089.Data Input.png 1 kB (image/png)
- bpmn-figure-090.Data Input Collection.png 1 kB (image/png)
- bpmn-figure-091.Data Output.png 1 kB (image/png)
- bpmn-figure-092.Data Output Collection.png 1 kB (image/png)

XSD: global context

Key: DMN14-7
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
10.3.2.9.2 says "The global context is a context provided for convenience and 'pre-compilation'. Any number of expressions can be named and represented in a FEEL context m. The syntactic description m of this context can be evaluated once, that is, mapped to the FEEL domain as m, and then re-used to evaluate many expressions." For example, you might want to put a Relation used as a multi-dimensional constant in the global context. Or you might want to put a reusable function definition in the global context. Currently the xsd does not have globals. All expressions are bound to a specific drgElement, not global. The Import element probably needs to be modified to support this also.
Reported: DMN 1.0 — Sun, 31 May 2015 16:35 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Business Knowledge Model can have Information Requirements

Key: DMN14-5
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
FEEL function definitions are defined as lexical closures, which simply means that names in the function body must be in scope, and that scope includes the function parameters and, just like any other decision logic, it includes the information requirements and the knowledge requirements. This is very handy. For example, it allows the logic of a BKM to reference 100 Input Data items by name, without requiring that each invocation pass in 100 parameter bindings.

In order for this to work, the BKM would model 100 Information Requirements on the 100 Input Data items, instead of modeling them as parameters. The boxed invocations would not have 100 rows of repetitive binding information. We must extend the MM and Table 2 to allow a BKM to have information requirements.
Reported: DMN 1.0 — Thu, 23 Jul 2015 23:30 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

italics and bold used for both typographic literal notation and FEEL semantic exposition

Key: DMN14-4
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
in typographic literals, italics are strings and bold italics are date literals, but in 10.3, italics are feel syntactic elements and bold are semantic elements. Better to have different notations
Reported: DMN 1.0 — Thu, 3 Sep 2015 15:58 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

No notation for ItemDefinition

Key: DMN14-3
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The notion of a 'type' or ItemDefinition is in the metamodel (with some pending issues) and in the semantics and concepts, but little is in the notation. Thus, we have notation that allows you to execute an expression with actual arguments, but no notation to allow validation based on type information without actual values.

We have most of the pieces, so it should not be difficult. E.g., individual values can be number, string, date and time, etc. We can allow numeric ranges using our unary tests, e.g. '>0', '[10..30)', etc. We can allow LOVs using "abc", "def", "ghi". These can be 'simple items', and we can also define structures using something similar to boxed contexts.
Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Business Context links go both ways

Key: DMN14-2
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In XSD, business context pointers are duplicated in both directions. E.g. decisionOwner and decisionMaker point to organizationalUnit, which in turns has pointers back the other way. This duplication adds no new information, just potential for internal inconsistency. I suggest omitting one of these directions; the other one is easily extracted from the serialization by XPATH.
Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

inconsistent date comparisons make unavoidavle paradoxes

Key: DMN14-48
Status: closed
Source: fujitsu america ( keith swenson)
Summary:
Date "=" is defined to include the time zone, and "<" and ">" does not. This causes a bunch of problems.

see: https://social-biz.org/2017/08/03/a-strange-feeling-about-dates/

Suggestion is simple: define date equality to be (date1 - date2 == 0) Eliminate the need to compare the "timezone" of the dates.

My experience with the group is that most suggestions are ignored, so I don't really want to waste any time making a more detailed proposal, but if you have questions about this problem you can contact me.
Reported: DMN 1.2 — Wed, 18 Sep 2019 10:01 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Fix interchange of links to objects in BPMN/BMM

Key: DMN14-44
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
The current spec uses objects from BMM and BPMN. However it is not at all clear how links to these objects, and the objects at the end of the links, should be interchanged. Does the DMN file contain a snippet of BPMN? Should a separate BPMN file be generated and then referenced? If we are going to have these links then we need to show/explain how to interchange them both with tools that only support DMN (and so only have a few BPMN or BMM objects) and with those that support DMN/BPMN/BMM.
Reported: DMN 1.2 — Thu, 27 Sep 2018 01:07 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Now way to represent a black-box or incompletely defined Decision Service

Key: DMN14-43
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
As DMN gets used to produce publicly available decision services we will need some way to represent a decision service that the modeler cannot see into. They know its a side-effect free, stateless decision service and know its signature so they can add a decision to their own model that is implemented by it but they don't know what decisions, BKMs, knowledge sources etc were used to produce it. There is currently no way to do this - a decision service can be shown collapsed but only if the model "knows" what the expanded version looks like. It feels like it would be useful to do so.
Reported: DMN 1.2 — Thu, 27 Sep 2018 01:04 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Unspecified conclusion is not supported

Key: DMN14-41
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
I remember discussions about allowing "-" in conclusions to mark an unspecified conclusion in a decision table. This would allow some of the conclusions in a multiple output decision table to be marked as "unspecified" where there was no output relevant for that conclusion for a specific rule and to allow rules in multi-hit tables to show that a particular combination of conditions had been considered but did not result in anything being added to the result set.
However the standard as written says that an output entry must adhere to the literal expression grammar, and '-' is not allowed. You have to return some FEEL value, e.g. 0, false, "N/A", null, etc.
Reported: DMN 1.1 — Mon, 13 Jun 2016 21:41 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

notion of arbitrary order conflicts with lack of an unordered collection data type

Key: DMN14-40
Status: closed
Source: Signavio GmbH ( Dr. Bastian Steinert)
Summary:
Section "8.2.11 Hit policy" describes that hit policy "Collect: returns all hits in arbitrary order". This implies that the order of the results does not have to be deterministic and can also vary among different implementations. However, the standard only supports the notion of 'lists', which do have an order. The comparison of lists is also specified in a way that the order of elements is significant. The issue might get more clear when thinking about testing the interface of decisions. Strictly speaking, it is currently not feasible to define a test against a decision table with hit policy 'collect'. The expected result can only be defined using a list, whose elements do have an order. The operator to compare the 'expected' and the 'actual' result will also take order into account.

The issue could easily be resolved by replacing 'arbitrary order' with 'rule order'.
Reported: DMN 1.1 — Sun, 26 Jun 2016 10:11 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

need set operations and equality in FEEL

Key: DMN14-39
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
some notes toward a proper description:
FEEL has ordered lists and some set builtins, e.g. distinct values and union. Lacks intersection and equality.

[1,2] in (1,2,[1,2], 3) is true

intersect([1,2,3], [3,1,4]) = [1,3]

set equals([1,1,3], [3,1]) is true
probably - distinct values([1,1,3]) = distinct values([3,1])
maybe change to set([1,1,3]) = set([3,1])
(set needs to both remove dups and return elements in canonical order)
what is canonical order [null, 0, {}, []]?
[1,3] = [3,1] is false

Another option is to add sets to FEEL semantic domain (along with lists, numbers, contexts, ...). And need syntax.

simpler and more biz friendly proposal - add 'contains any' and 'contains all' as boolean infix operators taking 2 lists as LHS and RHS. And allow these to be added to unary tests w/o a '?'. E.g. 1,2,3 , in (1,2,3) , contains any (1,2,3), contains all (1,2,3). First 2 are what we have now (2nd allowed for symmetry). Last 2 assume input expr is a list (set).

if we just add set oriented builtins, but no friendlier syntax, this may not solve the biz problem of allowing DTs to process sets in a user friendly way. Too many ()s and ?s
Reported: DMN 1.1 — Thu, 11 Aug 2016 15:35 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement

Key: DMN14-38
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement
Reported: DMN 1.1 — Wed, 24 Aug 2016 16:45 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Collect decision tables

Key: DMN14-37
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
(1) The spec says "Collect: returns all hits in arbitrary order. An operator (‘+’, ‘<’, ‘>’, ‘#’) can be added to apply a simple function to the outputs. If no operator is present, the result is the list of all the output entries.". This is confusing - as I understand it if an operator is present a collect hit policy does not return all hits, only the result of the operation.

(2) The spec should state clearly what result is returned by Collect decision tables when no rules fire. In particular the result of a C+ decision table is not clear, because the result of sum([]) is undefined. I think a case could be made (based on a recursive definition) that the sum of an empty list is zero, which would be a much more useful result from the decision table than null. In general, section 10.3.4.4 restricts the semantics of all list functions to non-empty lists, although some functions have natural and useful results for the empty list e.g. count([])=0, sum([])=0, sublist([],x,y)=[], append([],items)=[items], concatenate([],items)=items, reverse([])=[], union([],items)=[], distinct values([])=[], flatten([])=[].

(3) Why is the result of C+ defined as "sum of all the distinct outputs" rather than just "sum of all the outputs"? I would say that if three rules fire proposing the value 5, the C+ result should be 15, not 5.
Reported: DMN 1.1 — Thu, 13 Oct 2016 08:25 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Metamodel constraints & validation

Key: DMN14-35
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
None of the metamodels contain logic constraints. For example, the name of a decision table is the same with the name of the variable defined inside of the decision table tag (invariant at decision table level).

Ideally these constrains would be used to validate the diagrams before execution (e.g. generating code from Java). Bruce Silver's already covers some of the. We should add them and more in the spec.

I think the metamodel constraints should be described with OCL – see the UML metamodels. There should be constraints for CL1, CL2 and CL3. It’s very likely the CL3 constraints will be a superset of CL2 constraints.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:45 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Requested additional built-in functions

Key: DMN14-34
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(from Bruce)
a. String-join(stringList, separatorString)

b. Format-number(value, formatString), where formatString (to be negotiated) generally follows Excel or xpath, maybe not all the features.

c. Format-date(value, formatString), format-dateTime(value, formatString)
Reported: DMN 1.1 — Mon, 2 Jan 2017 20:43 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Semantic domain mapping for simple expressions

Key: DMN14-33
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The FEEL grammar contains simple expressions as starting terminal

page 107 6. simple expressions = simple expression ,
{ "," , simple expression }
;

I could not find a mapping to a semantics domain for it. What is the type / domain of "simple expressions"? A list with element type Any or a Tuple Type with several element types?
Reported: DMN 1.1 — Fri, 17 Mar 2017 14:42 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Improvement of Semantic Domains Specification

Key: DMN14-32
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The definition of Semantic Domains / Types in 10.3.2 does not contain:
- a metamodel
- relationships between various types
I propose adding a metamodel and the following two relationship:

1. Conforms To
A semantic domain T1 conforms to a semantic domain T2 when an instance of T1 can be substituted at each place where an instance of T2 is expected.

2. Equivalent To
A semantic domain T1 is equivalent to a domain T2 iff they have the same name and the corresponding embedded semantic domains are equivalent. (e.g. List<Number> is equivalent only to List<Number> not List <String>).

The above relationships should be defined via tables, similar to the ones used to describe the semantics of logic operators (page 119 Table 38).
Reported: DMN 1.1 — Thu, 30 Mar 2017 12:38 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- argo-dmn-types.png 15 kB (image/png)

Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122

Key: DMN14-31
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
on page 122 in table 43 in row 2 and 3: "e1 in [e2, e3, ...]"
on page 109 grammar rule 51.c: expression "in" positive unary test
on page 109 grammar rule 51.c: expression "in" "(" positive unary tests ")"

The syntax with square brackets is not allowed by the grammar rules 51.c. Either table 43 or grammar definition should be changed.
Reported: DMN 1.1 — Wed, 3 May 2017 08:58 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test

Key: DMN14-30
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
For simple positive unary test(s) there are extra entry points in the FEEL grammar. Therefore why do we need simple positive unary test in grammar rule 2.i. What is the semantic mapping?
Reported: DMN 1.1 — Wed, 3 May 2017 09:11 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Should name declarations in same context fail or overwrite?

Key: DMN14-29
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
As I see the spec doesn't define what should happen if in a context a name should be declared that already exists in the current context. Sample FEEL expression: "for i in [1,2,3], i in [4,5,6] return i * i" Does the second definition of i overwrite the first one or should we return null for the complete "for" expression?
Reported: DMN 1.1 — Wed, 3 May 2017 09:25 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Can an expression in user defined function body reference a name outside of it's scope?

Key: DMN14-28
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
If an expression in a user defined function body references a name outside of it's scope (for example a parent scope), this scope must be available also during invocation of the function.

Examples:
- {f:function() a, a:1, i:f()}
  possible, since name a is still available in local context (scope) during invocation
- {b:1,f:function() b}
  .f() impossible, since name b is not available outside of the context.
It would be nice if the semantic mapping and the differentiation between function definition and invocation is clearly specified in the spec. What names can be referenced? Must the scopes also be available during invocation?
Reported: DMN 1.1 — Wed, 3 May 2017 15:24 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

How to get FEEL type if evaluation is not an option?

Key: DMN14-27
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
in chapter 10.3.2.10: "Sometimes we do not want to evalutate a FEEL expression e, we just want to know the type of e."

in table 54: column Applicability defines which row in the table to use, depending on the type of a FEEL expression.

Table 54 only makes sense if it is not allowed to pre-evaluate the expression e2, since even for a pre-evaluation context entries (for example: "item") must be declared in scope.

How do we know the type of a FEEL expression if it is not allowed to evaluate it?

Examples:
- [1,2,3][min(3,2,1)]
- {a:function() external {java: {class: "clazz", method signature: "method()"}}, b:[1,2,3][a()]}.b
- {a: 1, b: a instance of number, c: [1,2,3][b] }
Reported: DMN 1.1 — Wed, 3 May 2017 14:56 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Scope of decision table input/output entries is not well defined in the specification

Key: DMN14-26
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
While the scope of context entry specifically says to include the previous context entry (section 7.3.1), there is no mention for the scope of input and output entries of decision tables.
Reported: DMN 1.1 — Mon, 15 May 2017 17:59 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

More Generic Ways to Define Decision Table Properties

Key: DMN14-25
Status: closed
Source: OpenRules ( Jacob Feldman)
Summary:
I described several issues with the current way of representing decision table properties and made concrete suggestions for improvement in this LinkedIn post: https://www.linkedin.com/pulse/decision-table-properties-dmn-beyond-jacob-feldman
Reported: DMN 1.1 — Sat, 20 May 2017 19:09 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

FEEL grammar readbility

Key: DMN14-24
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
The grammar contains several sub-grammars each one with its own start non-terminal: expression, simple expressions, unary tests.

The grammar should be broken in several grammars, and common part to make things more obvious. It will help the CL3 implementation.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:37 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

No adjustment for last day in month if duration is added/subtracted to date and time value

Key: DMN14-15
Status: closed
Source: ACTICO ( Daniel Thanner)

Summary:

The specification says that the addition/subtraction of a date and time and a years and months duration value is defined as:

date and time (
   date(e1.year +/– e2.years + floor((e1.month+/– e2.months)/12),
   e1.month +/– e2.months – floor((e1.month +/– e2.months)/12) * 12,
   e1.day), 
   time(e1))

If you apply this expression to the following two values:

date and time("2017-08-30T11:00:00Z")
duration("P18M")
you would expect the following results:

date and time("2017-08-30T11:00:00Z") + duration("P18M")  --> result should be date and time("2019-02-28T11:00:00Z")
date and time("2017-08-30T11:00:00Z") - duration("P18M")  --> result should be date and time("2016-02-29T11:00:00Z")

If you apply the values to the defined formula, you get:

date and time (
   date(2017 +/– 1 + floor((8 +/– 6)/12),
   8 +/– 6 – floor((8 +/– 6)/12) * 12,
   30), 
   time("11:00:00Z"))

Addition
which results for addition into:

date and time (
   date(2018 + floor(1,1667),
   14 – floor(1,1667) * 12,
   30), 
   time("11:00:00Z"))

which is:

date and time (date(2019, 2, 30), time("11:00:00Z"))

The adjustment to the last valid day in a month is missing. 30th February is invalid, since February has only 28/29 days.

Subtraction
which results for subtraction into:

date and time (
   date(2016 + floor(0,1667),
   2 – floor(0,1667) * 12,
   30), 
   time("11:00:00Z"))

which is:

date and time (date(2016, 2, 30), time("11:00:00Z"))

The adjustment to the last valid day in a month is missing. 30th February is invalid, since February has only 28/29 days.

Recommendation:
Adjustment to last valid day in month must be added to spec.

Reported: DMN 1.1 — Mon, 2 Oct 2017 12:41 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Temporal precision inconsistencies

Key: DMN14-53
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
The spec sometimes refers to the temporal precision as milliseconds and sometimes to seconds. Sections 10.3.2.3.3, 10.3.2.3.5 and 10.3.2.3.6 refer to Seconds whereas table 48 offers a semantic of Milliseconds
Reported: DMN 1.2b1 — Tue, 16 Jul 2019 14:02 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Clarification regarding equivalence of date vs date and time

Key: DMN14-54
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Section 10.3.2.3.5 date contains the following:

Where necessary, including the valuedt function (see 10.3.2.3.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00).

Is not obvious when the equaivalence should be applied.

One option is to add an implicit conversion, similar to the ones for singleton lists.
Reported: DMN 1.2 — Sun, 2 Jun 2019 13:01 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- DMN14-54 Date Time Equivalence.docx 21 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Support for recursive calls by Business Knowledge Models

Key: DMN14-62
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The definition of "well formed" for a BusinessKnowledgeModel excludes the notion of the encapulatedLogic of a BusinessKnowledgeModel being able to invoke itself to permit recursion. There is no means to define a 'self' relationship via knowledgeRequirements - the spec forbids it.

However, vendors are currently supporting BusinessKnowledgeModel recursion simply by permitting a BusinessKnowledgeModel's encapulatedLogic to invoke the contained BusinessKnowledgeModel as a function using the contained BusinessKnowledgeModel's name. I propose we formalise this in the spec.

I propose that after the definition of well-formed on page 56/57 (repeated below):

"An instance of BusinessKnowledgeModel is said to be well-formed if and only if, either it does not have any knowledgeRequirement, or all of its knowledgeRequirement elements are well-formed. That condition
entails, in particular, that the requirement subgraph of a BusinessKnowledgeModel element SHALL be acyclic, that is, that a BusinessKnowledgeModel element SHALL not require itself, directly or indirectly. "

The following paragraph is added:

"However, the encapsulatedLogic within a BusinessKnowledgeModel may invoke itself in a recursive manner by using the name of the containing BusinessKnowledgeModel as an invokable name."
Reported: DMN 1.2 — Sat, 6 Apr 2019 02:38 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Clarification on DMN case sensitivity of timezones

Key: DMN14-63
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
DMN spec refers to usage of iana timezones. iana does not specify that timezones are case-sensitive - that is up to the implementation. https://data.iana.org/time-zones/theory.html: re zone naming:

"Do not use names that differ only in case. Although the reference implementation is case-sensitive, some other implementations are not, and they would mishandle names differing only in case."

This issue is seeking clarification via the spec as to whether DMN's usage of time zones permits case insensitivity such that "etc/utc" is the same zone as "Etc/UTC" ... or not.
Reported: DMN 1.2 — Sat, 16 Mar 2019 01:12 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Lack of visual notation for processing of / iteration over lists in FEEL

Key: DMN14-60
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
split off from ~~DMN13-12~~
Reported: DMN 1.2 — Tue, 20 Nov 2018 17:55 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

"instance of" not possible with some built-in functions

Key: DMN14-66
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
some built in functions are overloaded in that they can have multiple signatures. So, say, performing an "instance of" to compare against the function "min" is meaningless as the signature is not known unless it is invoked.

Unless the type system is to take into account overloaded functions?
Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:15 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Clean up example xml files

Key: DMN14-57
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Sample xml files have Trisotech extension elements. These should be removed prior to publication.
Reported: DMN 1.2b1 — Tue, 28 May 2019 16:52 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Provide better spec and examples for Equality, Identity, and Equivalence

Key: DMN14-58
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
the builtin function is() refers to this section. It should cover some pos/neg examples of equality vs. identity, and explain aggregate elements in D, e.g. list of structures.
Reported: DMN 1.2b1 — Tue, 28 May 2019 16:40 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

data equivalence with date and time

Key: DMN14-51
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Section 10.3.2.3.5 contains the following:

Where necessary, including the valuedt function (see 10.3.2.3.6), a date value is considered to be equivalent to a date time
value in which the time of day is UTC midnight (00:00:00).

It is not very clear where this equivalence is going to be applied.

The proposal is to specify the above in a more precise manner, possibly as an implicit conversion.
Reported: DMN 1.2 — Mon, 27 May 2019 08:30 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Friendlier handling of null values

Key: DMN14-59
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
E.g. in aggregation, default for item definition, see examples in DMN-2, where filters like [item!=null] are used repeatedly
Reported: DMN 1.2b1 — Tue, 21 May 2019 16:53 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.

Key: DMN14-69
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.
UnaryTest should be added to the diagram.
Reported: DMN 1.3 — Wed, 1 Jan 2020 00:23 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression

Key: DMN14-70
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression. The figure should be updated.
This is similar to the issue for Figure 6-10, which has the same problem.
Reported: DMN 1.3 — Wed, 1 Jan 2020 00:21 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Typos in the XMI files

Key: DMN14-71
Status: closed
Source: Camunda GmbH ( Maciej Barelkowski)
Summary:
I found two typos in the XMI files:
1. In the DMNDI12.xmi, lines 510-512:

```
<packagedElement xmi:type="uml:Class" xmi:id="_18_1_f7a0369_1441612964861_428140_5975"
name="DC::Style"
isAbstract="true"/>
```

The class cannot refer to dc:Style as such class does not exist. The XSD refers to di:Style.

2. In the DMN12.xmi, lines 956-958:

```
<ownedAttribute xmi:type="uml:Property" xmi:id="_17_0_3_1_42401a5_1375643571589_681805_3414"
name="input
"
visibility="public"
```

Attribute name includes an encoded newline character (`\n`) which is not present in the XSD.
Reported: DMN 1.2 — Thu, 19 Dec 2019 13:19 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

DMN Models need a default timezone

Key: DMN14-47
Status: closed
Source: fujitsu america ( keith swenson)
Summary:
All date expressions, if the timezone is not explicitly mentioned, are interpreted as being in the timezone of the computer running the code. This means you can design a model that runs correctly in one timezone,a nd incorrectly in a different one.

Imagine you have a development team in Bangalore which makes a DMN model that runs correctly and passes all the tests. Then it is installed into the company server in London, and it fails.
Does anyone think this is a good idea?

The solution is simple: the model should have a default timezone. All date expressions that don't mention the timezone are interpreted according to this default time zone, and NOT according the timezone of the machine you are running on. Then, models will run exactly the same way no matter where it is run. That is a good idea, right?

See this: https://social-biz.org/2017/08/03/a-strange-feeling-about-dates/
Reported: DMN 1.2 — Wed, 18 Sep 2019 09:55 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

Situational Data Model and Notation (SDMN)

Key: DMN14-49
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
Situational Data is the set of Data Items and their structures that are needed for the performance and understanding of a Knowledge Package Model.
The details of the Data Items will usually be a subset of the “official” complexity of those items in the environment of the Knowledge Package Model.
For example, the official definition of the Data Item for Blood Pressure (in healthcare) includes more than 50 properties. A Data Item in a Situational Data Model may need only 2 of those properties for execution of the Processes, Cases, and or Decision Services.
Semantic References can be added to link the Data Item to the “official” details.
Uses of the Data Items in BPM+ models that determine the scope of Situational Data include:
Data required for DMN Decisions
Data required for BPMN Gateways transitions
Data required to be passed to/from services invoked by BPMN and CMMN
Data required to trigger Sentries in CMMN
Etc.
Reported: DMN 1.2b1 — Tue, 10 Sep 2019 18:04 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- BMI Update - SDMN Sep 23 2019.pptx 3.94 MB (application/vnd.openxmlformats-officedocument.presentationml.presentation)

Knowledge Package Model and Notation (KPMN)

Key: DMN14-50
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
A Knowledge Package is mechanism for packaging and distributing a set of BPM+ models (the knowledge)
A Knowledge Package references separate, but connected BPM+ models (BPMN Processes, CMMN Cases, and DMN Decision Services)
KPMN is focused solely on the BMI behavioral standards
A Knowledge Package also contains a Data Item library for the data that will be used by the BPM+ models
A Situational Data Model and Notation (SDMN) is also being proposed as a potential BMI standard to be added to the BPM+ stack (see separate presentation on this topic)
A Knowledge Package also contains metadata about the topic of the package to aid in understanding the content and to find appropriate Knowledge Packages
We are still exploring the relationships between KPMN and Provenance and Pedigree
KPMN includes a diagram to illustrate the scope of the Knowledge Package’s content (a Knowledge Model Diagram)
Reported: DMN 1.2b1 — Tue, 10 Sep 2019 17:59 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT
Attachments:
- BMI Update - KPMN Sep 23 2019.pptx.zip 6.44 MB (application/zip)

Inconsistency DMNv1.2 dropping [a]=a and get entries example

Key: DMN14-65
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
Since DMNv1.2 the spec dropped the equivalence of:
[a] = a
because it does not apply to the statement that

a singleton list L, when used in an expression where a list is not expected, behaves as if L[1] is written.

So the expression
[a] = a
on DMNv1.2 is expected to return false.

However, in section 10.3.2.6 Context of the spec, it provides the following statement for the get entries function:
To retrieve a list of key,value pairs from a context m, the following built-in function may be used: get entries(m).
For example, the following is true:
get entries({key 1 : "value 1 "})[key="key 1 "].value = "value 1 "
BUT
get entries({key1 : "value1"})[key="key1"].value = "value1" by substitution: [ { key : "key1", value : "value1" } ][key="key1"].value = "value1" [ { key : "key1", value : "value1" } ].value = "value1" [ "value1" ] = "value1"
according to DMNv1.2 should be false

By the same principle that the DMNv1.2 for the following literal expression:
[123] = 123
on DMNv1.2 is expected to be false
Reported: DMN 1.2b1 — Wed, 30 Jan 2019 14:43 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

properly define type(e)

Key: DMN14-64
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
In some places the spec uses type(e) and other places type(e). These are different. The former provides a type-checking function that can validate a FEEL expression e without input data values (although some kind of scope is needed for disambiguation). The latter simply returns the datatype of the semantic domain element e. The former is more useful to implementors, but more work to specify. Essentially, all the semantic mapping tables need a new column to specify the result type given the input types, for each FEEL operator and builtin. The latter is a matter of generalizing Table 39. It must cover cases such as type([0,false]). It should be clear that type(e) as a function must return the most specific type (and there must be only 1), but informally the types also include those that are conformed to, so for example, [1,2,3] has types list<number>, list<Any>, Any.
Reported: DMN 1.2 — Tue, 27 Nov 2018 22:31 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
Defer to DMN 1.5

Defer to DMN 1.5
Updated: Thu, 31 Mar 2022 19:30 GMT

No way to show relative multiplicity of decisions and their information requirements

Key: DMN14-153
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
Item Definitions are hierarchical so the top level one in an Input Data or a Decision might not be a collection while one or more of those contained are. This means that there may be a collection to process even if the Input Data or Decision is not marked as a collection (see ~~DMN14-123~~ for this separate issue). It should be possible to show both "fan in" where multiple instances of the source of the requirement are used by a single instance of a decision and "fan-out" when the source of requirement contains a collection which will be processed one at a time by the decision.
Reported: DMN 1.3 — Wed, 24 Feb 2021 05:36 GMT
Disposition: Deferred — DMN 1.4
Disposition Summary:
This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force
Updated: Wed, 15 Dec 2021 21:12 GMT
Attachments:
- FanProposal_JTJP.pdf 297 kB (application/pdf)

Lack of visual notation for processing of / iteration over lists

Key: DMN12-27
Status: closed
Source: Signavio GmbH ( Dr. Bastian Steinert)
Summary:
The processing of lists of data is fundamental to business decisions. Some kind of multiplicity should be indicated at the DRD level, and iteration should be supported visually at the decision logic level. In spite of the attached figures (meant to provoke discussion), the scope of this issue is limited to "flat" DRDs, that is, no "sub-DRDs" nested inside an outer decision or BKM. DRD proposal should specify what the multiplicity marker or other DRD notation looks like, and where it may appear, e.g. attached to head or tail of a requirement arrow, or inside a decision or BKM shape left of the name, etc.
Reported: DMN 1.1 — Wed, 4 May 2016 08:49 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
No workable proposal after several discussions over 2 years

How should iteration be visualized at the logic level and at the requirements level?
Updated: Tue, 23 Feb 2021 17:54 GMT
Attachments:
- Cardinality.pdf 276 kB (application/pdf)
- FanProposal_JTJP.pdf 297 kB (application/pdf)
- MID.jpg 30 kB (image/jpeg)
- iteration.PNG 9 kB ()

Incorrect claim about the Unicode character range and EBNF character expressions

Key: DMN13-127
Status: closed
Source: Fujitsu ( Keith Swenson)
Summary:
This is a trivial typo, and the fix is easy.

Lower on page 108 it says: "the character range that includes all Unicode characters is [\u0-\u10FFF]." This range specified has less than 70,000 characters.

I don't think your intent is to limit implementations to 70K characters and in fact in places (e.g. grammar rule #30) character values larger than this are mentioned.

"all Unicode characters" is actually the entire range of 32-bit values (minus some control codes: hundreds of millions of characters, most of which are undefined). Instead you are defining a SUBSET of this that will be allowed.

Second, the most common implementation of Unicode uses UTF-16, and as a consequences OF THIS ENCODING, the range of representable characters is 0 through 10FFFF. Note that is six hex digits, there are four F digits. There are over a million characters in this range.

(1) Nowhere in the spec does is say you are limiting characters to the UTF-16 range. This should be explicitly stated if that is your intent.

(2) The phrase on page 108 should be changed to; "DMN allows the use of unicode characters in the range of [\u0-\u10FFFF]."

(3) The specification of EBNF character expression should be changed to allow 6 hex digits, currently it says you can only use five digits max.
Reported: DMN 1.2b1 — Mon, 31 Dec 2018 17:00 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Allow 4 or 6 hexadecimal digits for unicode code point

See attached word doc
Updated: Tue, 26 Jan 2021 20:17 GMT
Attachments:
- DMN13-127-v7.docx 19 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Should add a new unicode escape syntax

Key: DMN13-143
Status: closed
Source: fujitsu america ( keith swenson)
Summary:
On page 110, rule #66 gives these escape sequences:

string escape sequence = "\'" | "\"" | "
" | "\n" | "\r" | "\t" | "\u", hex digit, hex digit, hex digit, hex digit;

Using the hex character value notation "\uD41A" you can only four hex digits which is not enough to specify the entire Unicode character range. The spec specifically mentions that much higher values are allowed, and there should be a standard way to specify them without having to use the cryptic surrogate character pairs.

This suggestion is to add braces to allow variable length hex values in exactly the way that JavaScript allows:

"\u
{1F40E}
"

This is character 128,014 in the unicode set. To specify this character using surrogate pairs you would have to use: "\uD83D\uDC0E" which is complicated and confusing and is currently subject to discussion on whether this is valid or not within the current spec.

"A" = "\u
{41}
"

"è" = "\u
{E8}
"

"査" = "\u
{67FB}
"

"" = "\u
{1F407}
" (Jira seems to crash if I inlcude this character)

It is nice because you actually use the Unicode code point value, and because of the braces you can specify a variable number of hex digits so the entire Unicode set can be easily addressed. The precidence for this syntax is set by JavaScript (

https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

See page 218 where it defines this (slightly translated):

UnicodeEscapeSequence ::
\u Hex4Digits
\u
{ CodePoint }

This will not conflict with any existing implementation since the opening brace was not allowed in earlier implementations. The new allowed syntax could be used in DMN 1.3 and higher.
Reported: DMN 1.2b1 — Fri, 8 Feb 2019 19:06 GMT
Disposition: Duplicate or Merged — DMN 1.3
Disposition Summary:
Addressed by resolution of DMN-127

DMN-127 adds \U, 6*hex digit to address this issue as well
Updated: Tue, 26 Jan 2021 20:17 GMT

Ambiguty for the source/target of DMNEdge when there is multiple depictions of its source and target

Key: DMN13-109
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
DMN DI allows to depict element more than once. When drawing a diagram, tools need to check graphically the way points to know to which DMNShape a DMNEdge is actually connected to.
Reported: DMN 1.2 — Mon, 26 Nov 2018 22:50 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Add sourceElement and targetElement to DMNEdge

Add a sourceElement and targetElement to the DMNEdge class so the actual DMNShape used as source and target can be resolved without graphical deduction.
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- DMN13-110_DMNEdge.PNG 21 kB ()

Incorrect figure 6.10

Key: DMN13-244
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
Figure 6.10 has not been updated in line with issue ~~DMN13-140~~.
Reported: DMN 1.2b1 — Tue, 3 Dec 2019 17:14 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Correct fig 6.10 and associated text

Replace figure 6.10 & modify para 2 of section 6.3.1 so that UnaryTests is a subclass of Expression, rather than DMNElement.
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- Class_Diagram__DMN__DMNElement.svg 325 kB (image/svg+xml)

PMML invocation output value in the case of single prediction

Key: DMN13-181
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
The proposal targets the case of a PMML invocation having a single output prediction(s), for the result to be simply the value result of such single prediction, instead of a context with 1 only entry, name of the single output prediction, and value of that prediction.
Reported: DMN 1.2 — Mon, 23 Sep 2019 14:34 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Do not wrap single values returned from PMML in context

Executive summary

The proposal targets the case of a PMML invocation having a single output prediction(s), for the result to be simply the value result of such single prediction, instead of a context with 1 only entry, name of the single output prediction, and value of that prediction.
This would also align expected invocation behaviour similarly to what RTF agreed on when dealing with Decision Service, ref: https://issues.omg.org/browse/DMN13-163

Rationale and details

By the PMML specification, a ML predictive model can produce multiple outputs, so in general a (FEEL) Context is assumed to be returned by its invocation, containing a key-value pair of prediction name and value.

However,
Most PMML models have a single prediction as output.
To get an idea, can reference examples presented on PMML website: http://dmg.org/pmml/pmml_examples/index.html

Specifically to a well-known example, Iris dataset, Tree model: http://dmg.org/pmml/pmml_examples/KNIME_PMML_4.1_Examples/single_iris_dectree.xml
This would imply every time a Decision invokes a BKM for the PMML prediction, something like:
{ class : "Iris-versicolor" }
is returned, instead of simply getting back something like a FEEL string:
"Iris-versicolor"
So it would make very annoying for dependent decision the need to always access the single prediction output in the key-value pair:
result.class
instead of more simply:
result
and other analogous implications.

This proposal would align the expected behaviour to what what RTF agreed on when dealing with Decision Service, ref: https://issues.omg.org/browse/DMN13-163 for coercion of the singleton value, in the case of a single PMML output prediction.
Updated: Mon, 30 Mar 2020 19:50 GMT

A signature for the time() built in function is missing from table 66

Key: DMN13-175
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Section 10.3.2.3.4 time of the spec already says:
[..] If no time offset is specified, the time is interpreted as a local time of day at some location, whose relationship to UTC time is dependent on time zone rules for that location, and may vary from day to day. [..]

But table 66 show the signature time(hour, minute, second, offset) but does not show the signature time(hour, minute, second) which forces users to write time(08, 04, 32, null) when what they would want to write is simply time(08, 04, 32)
Reported: DMN 1.2b1 — Thu, 29 Aug 2019 12:54 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Make offset parameter optional in built-in function time()

In Table 66 page 145 change time(hour, minute, second, offset) for time(hour, minute, second, offset?)
Updated: Mon, 30 Mar 2020 19:50 GMT

Decision Logic Examples

Key: DMN13-2
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
DMN 1.1 should provide examples of all types of decision model allowed by the standard, both graphically (DRD and decision table, where appropriate) and XML serialization. Currently missing:
1. decision tables with an expression (more than a name) in inputExpression and outputExpression.
2. decision tables with inputEntry or outputEntry referencing a "name" as defined by S-FEEL, i.e. not just a literal.
3. DRD and decision table involving what Vanthienen calls "action subtables". All existing examples are "condition subtables".
4. Serialization of crosstab format tables.
5. Representation of literal values vs names in serialization.
6. Representation of PMML and FEEL in the serialization.
Reported: DMN 1.0 — Sun, 12 Apr 2015 15:39 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Add second example to Chapter 11

See attached word doc for spec changes. See attached zip file for additions to examples.zip.
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- 13-2 DMN files.zip 28 kB (application/zip)
- Issue DMN13-2 Proposal - Decision Logic Examples.docx 2.32 MB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Disambiguation for Modulo / Remainder function

Key: DMN13-125
Status: closed
Source: Red Hat ( Matteo Mortari)

Summary:

The spec defines "modulo" FEEL built-in function as: "the remainder of the division of dividend by divisor"
However, this might be subject to ambiguity in the case the Divisor or Dividend are negative, as also mentioned by Wikipedia page which list examples out of several programming languages and systems: https://en.wikipedia.org/wiki/Modulo_operation by saying that "When either a or n is negative, the naive definition breaks down and programming languages differ in how these values are defined".

FEEL aims to be a Friendly Enough expression language, and especially thinking about DMN practitioners who might be used to Spreadsheet based systems might find misleading if the definition of the FEEL "modulo" gets bind to the Java (default) definition, the following table illustrate the difference:

Dividend	Divisor	MOD() from Microsoft Excel, Google Sheets, LibreOffice Calc, Wolfram Alpha, etc.	Java % or BigDecimal#remainder or other languages default
10	4	2	2
10	-4	-2	2
-10	4	2	-2
-10	-4	-2	-2

or to other implementation languages where the definition of Modulo/Remainder is not explicit, or the default one is not consistent with Spreadsheet default one.

It is proposed therefore to change the specification in 10.3.4.5 Numeric functions Table 70 for the FEEL "modulo" built-in function
FROM: "Returns the remainder of the division of dividend by divisor."
TO: "Returns the remainder of the division of dividend by divisor. In case either dividend or divisor is negative, the result has the same sign of the DIVISOR."

This would avoid ambiguity by making a clear definition of what should be the sign in case either of the operands are negative.
This should make this consistent with Spreadsheet based system result of "MOD()" expression, which should address being Friendly Enough for DMN practitioners and DM analyst.
This would not make the result the same as the default of Java % operator or BigDecimal#remainder, but Java based implementation/Vendor can trivially address the result to be compliant with the spec.

Reported: DMN 1.2b1 — Fri, 4 Jan 2019 18:38 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Improve the specification of the modulo builtin function

The existing specification does not restrict the arguments to integers, and does not clearly define the sign of the result.
Updated: Mon, 30 Mar 2020 19:50 GMT

Add built-in functions to support Allen's interval algebra

Key: DMN13-139
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Allen's interval algebra defines possible relations between two intervals.
Namely:
before
meets
overlaps
finishes
includes
starts
coincides
after
metBy
overlappedBy
finishedBy
during
finishes

Some more info available here: https://en.wikipedia.org/wiki/Allen%27s_interval_algebra
Reported: DMN 1.2b1 — Wed, 6 Feb 2019 21:26 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Add interval builtins, range objects in semantic domain, and compact date literals

See attached word doc
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- DMN13-139-proposal-v1.pptx 63 kB (application/vnd.openxmlformats-officedocument.presentationml.presentation)
- Interval Algebra - RTF Proposal - v7.docx 110 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Incorrect grammar rule references and missing UnaryTests section in MM

Key: DMN13-140
Status: closed
Source: Red Hat ( Edson Tirelli)
Summary:
As discussed in the RTF call on Feb 5th, we need to fix:

1.Refs to grammar rules at end of ch9 are incorrect (change 14 to 12 and check others)
2. grammar rule 14 in ch10 is unused and should be removed
3. UnaryTests UML class is missing from the spec (it is shown on one diagram not the defining occurrence
Need to specify this MM class and point to the correct unary tests grammar rule that defines its syntax (this will be different for FEEL and SFEEL)
Reported: DMN 1.2b1 — Tue, 5 Feb 2019 17:53 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Fix grammar rule references and add UnaryTests MM

Specification Text
See revised text.

Metamodel
- In Figure 7.6, Change UnaryTests class to inherit from Expression rather than directly from DMNElement
- See attached Fig7_6
XML Schema
- Correct tExpression to make the typeRef attribute optional (as shown in the metamodel of Fig 7.6)
- make tUnaryTests extend tExpression instead of tDMNElement
Backward Compatibility Argument
- Expressions that do specify a typeRef will still be valid when the typeRef in the XSD is corrected to be optional
- UnaryTests that do not specify a typeRef will still be valid because the typeRef is optional
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- DMN13-140-Fig7_6.PNG 71 kB ()
- Screen Shot 2019-10-09 at 12.41.36 PM.png 90 kB (image/png)

Allegedly bug in Table Table 40 Examples of equivalence and conformance relations

Key: DMN13-141
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
The DMNv1.2 spec reports these two lines examples:
type1 type2 equivalent to conforms to

type([{"id": 1,"name":"Peter", "age": 45}])

type(Decision3)

True True

type(Decision4)

type(Decision3)

True True
However concerning the first referenced line, type1
type([{"id": 1,"name":"Peter", "age": 45}]) ^ by following the syntax used in table 39 takes the form of the type: list<context<"id": number,"name": string, "age": number>>
and type2:
type(Decision3) by following the syntax used in table 39 takes the form of the type: context<"id": number,"name": string, "age": number>
So in the first referenced line it is asserted type1 is Equivalent to type2, but a list and a context are not Equivalent by the rule described in section 10.3.2.9.1 Type Equivalence

Similarly for the second referenced line, type 1:
type(Decision4) by following the syntax used in table 39 takes the form of the type: list<context<"id": number,"name": string, "age": number>>
As for the ItemDefinition with the isCollection="true" which therefore obliges the definition that:

IsCollection: Boolean Setting this flag to true indicates that the actual values defined by this ItemDefinition are collections of allowed values.

So again by the section 10.3.2.9.1 Type Equivalence there are no "iff" rules explicited which would make a LIST Equivalent to a CONTEXT.

Analogous issue for the reported values of Conformance.

Can you kindly verify and clarify if needed, please?
Reported: DMN 1.2b1 — Fri, 1 Feb 2019 14:07 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Replace 2 rows in table 40

See attached word doc
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- DMN13-141-proposal-v1.docx 14 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

type conversions are too spread out in Ch 10

Key: DMN13-132
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The spec does not contain a section where the type conversions are described, hence they end-up spread across the spec. For example, a particular case of invocation conversion is described in 10.3.2.5:

Similarly, on a function f( p ) where the domain of the formal parameter p does not include lists, but on an invocation f( pa ) the
actual parameter pa is a singleton list where the type of pa[1] belongs to the domain of p, then pa[1] should be used instead.

Consolidating all of them in one paragraph will make the spec more readable and easier to change in the future (e.g. we want to apply conversions in other context). It will also help us to identify gaps in the spec.

It's a natural step after adding the type relationships in DMN 1.2.
Reported: DMN 1.2b1 — Wed, 30 Jan 2019 16:34 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Add extra paragraph to clarify type conversions

see attached word doc
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- DMN13-132-proposal-v5.docx 22 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Remove the limitation that the second operand of exponentiation be an integer

Key: DMN13-111
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Table 55: Semantics of exponentiation limits the second operand to be an integer. It allow any number.
Reported: DMN 1.2b1 — Tue, 27 Nov 2018 14:10 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Allow second operand of exponentiation to be a number

The second operand of exponentiation should be allowed to be a number rather than limited to an integer
Updated: Mon, 30 Mar 2020 19:50 GMT

Decision Requirement Metadata Examples

Key: DMN13-156
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Enhance the example in chapter 11 with more realistic metadata attached to the decisions, input data, knowledge sources, etc.
Reported: DMN 1.2b1 — Tue, 21 May 2019 00:52 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Enhance Chapter 11 example with additional standard metadata

Enhance Chapter 11 example with additional standard metadata, as attached.
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- DMN13-157 Files.zip 423 kB (application/zip)
- Issue DMN13-157 Proposal - Decision Requirement Metadata Examples Section.docx 401 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Decision Service output value in the case of single output Decision

Key: DMN13-163
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
Executive summary

The proposal targets the case of a Decision Service having a single output decision(s), for the result to be simply the value result of such single decision, instead of a context with 1 only entry, name of the single output decision, and value of that decision

Rationale and details

with reference to figure from the spec Figure 11.7: Routing Decision Service, the use of the decision service in a literal expression would currently require to write something like:
if Routing Decision Service( ..., ... ).Routing = "ACCEPT" then true else false
please notice specify the .Routing would sound redundant and arguably some may say user-unfriendly in the scenario of a Decision Service with a single output decision.

In the case of a Decision Service with a single output decision, we could more friendly have:
if Routing Decision Service( ..., ... ) = "ACCEPT" then true else false
In other words, the result of invoking the "Routing Decision Service" accordingly to this proposal would be:
Routing Decision Service : "ACCEPT"
and not:
Routing Decision Service : { Routing : "ACCEPT" }
as of today.

Naturally when a Decision Service contains multiple output DecisionS, then is always the context, for instance taking example from DMN Spec Figure 11.6: Bureau Strategy Decision Service the result will continue to be:
Bureau Strategy Decision Service : { Strategy : ..., Bureau call type: ... }
Proposal specification change

With reference to document formal/19-01-05, chapter "10.4 Execution Semantics of Decision Services", page 151
Replace the following:

The execution semantics of S is FEEL(F): a function that when invoked with values from the FEEL semantic domain
bound to the parameters representing input data and input decisions, returns a context consisting of all the output
decisions' output values.

with:
The execution semantics of S is FEEL(F): a function that when invoked with values from the FEEL semantic domain
bound to the parameters representing input data and input decisions, returns:
- in the case of a single output decision(s), the single decision's output value.
- in the case of multiple output decisions, a context consisting of all the output decisions' output values.
Reported: DMN 1.2 — Mon, 20 May 2019 15:30 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
clarify that single output decision service does not result in context but rather the single output value

Executive summary

The proposal targets the case of a Decision Service having a single output decision(s), for the result to be simply the value result of such single decision, instead of a context with 1 only entry, name of the single output decision, and value of that decision

Rationale and details

with reference to figure from the spec Figure 11.7: Routing Decision Service, the use of the decision service in a literal expression would currently require to write something like:
if Routing Decision Service( ..., ... ).Routing = "ACCEPT" then true else false
please notice specify the .Routing would sound redundant and arguably some may say user-unfriendly in the scenario of a Decision Service with a single output decision.

In the case of a Decision Service with a single output decision, we could more friendly have:
if Routing Decision Service( ..., ... ) = "ACCEPT" then true else false
In other words, the result of invoking the "Routing Decision Service" accordingly to this proposal would be:
Routing Decision Service : "ACCEPT"
and not:
Routing Decision Service : { Routing : "ACCEPT" }
as of today.

Naturally when a Decision Service contains multiple output DecisionS, then is always the context, for instance taking example from DMN Spec Figure 11.6: Bureau Strategy Decision Service the result will continue to be:
Bureau Strategy Decision Service : { Strategy : ..., Bureau call type: ... }
Updated: Mon, 30 Mar 2020 19:50 GMT

New FEEL URI needed

Key: DMN13-188
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
FEEL has changed in DMN 1.3. We need a way to know which version is used in a model, e.g. by using a new URI for expressionLanguage and typeLanguage.

This is also important, in case FEEL is used outside DMN, because in that case the surrounding model doesn't have any reference to a DMN version.
Reported: DMN 1.2 — Tue, 8 Oct 2019 16:18 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Update FEEL URI

Update the URI for FEEL to https://www.omg.org/spec/DMN/20191111/FEEL/ as defined in DMN13-187.
Updated: Mon, 30 Mar 2020 19:50 GMT

Functions resolution

Key: DMN13-178
Status: closed Implementation work Blocked
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
FEEL supports function invocation described in rule 40, for example f(a, b, c)

The specification doesn't describe in details how the function is resolved (name of function is bound to the function definition). For example:
- what are the DMN / FEEL artifacts that the call can be bound to (e.g. DMN invocables visible in context)
- how are the name clashes resolved (e.g. both a BKM and a buil-in function have the same signature)
- how are the binding candidates built (e.g. apply all combinations of implicit conversions) and selected (e.g. exact match takes precedence)
Reported: DMN 1.2 — Wed, 18 Sep 2019 08:08 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Specify how functions are found in scope and argument types are checked

See attached word doc
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- DMN13-178-proposal-v6.docx 11 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Update the copyright section

Key: DMN13-242
Status: closed
Source: Red Hat ( Edson Tirelli)
Summary:
Please update the copyright section to reflect contributions to the standard by RTF members.

For instance, add Red Hat, Camunda, etc.
Reported: DMN 1.2 — Tue, 22 Oct 2019 19:36 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Add OMG-confirmed contributors to copyright list

As discussed with Mr. Juergen Boldt, this proposal only adds contributors to the list of copyright holders, who explicitly requested this, got confirmed by OMG, and can show their involvement.

Red Hat represented by Edson Tirelli and Matteo Mortari made the following contributions to DMN:
- 13 Issues raised, many with proposals already included, 9 of them approved
- 3 Proposals created and approved by TF
- Primary contributor to the DMN TCK
Camunda Services GmbH represented by Mr. Falko Menge made the following contributions to DMN:
- Chapter 13 DMN Diagram Interchange (DMN DI) including Meta Model and XML Schema
- 10 Issues raised, many with proposals already included, all of them approved
- 22 Proposals created and approved by TF
- 61 commits to XML Schema, examples and other machine-readable files in GitHub
- Over 400 hours of work tracked
- Contributor to the DMN TCK
Trisotech represented by Mr. Denis Gagne made the following contributions to DMN:
- 34 Issues raised, many with proposals already included, 22 of them approved
- 10 Proposals created and approved by TF
- Contributor to the DMN TCK
This dashboard shows further activities of these contributors: https://issues.omg.org/secure/Dashboard.jspa?selectPageId=10900
Updated: Mon, 30 Mar 2020 19:50 GMT

New acknowledgments needed

Key: DMN13-195
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
The spec should keep track and acknowledge the work of all the people and companies involved.
Reported: DMN 1.2 — Tue, 15 Oct 2019 16:20 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Update acknowledgments section

Update copyright list with all participating companies
Updated: Mon, 30 Mar 2020 19:50 GMT

New XML Namespace needed

Key: DMN13-191
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
For tools to clearly identify the version of a DMN file or FEEL expression, the XML namespaces of DMN, DMN DI and FEEL should be updated.

DI and DC namespaces can stay the same as DMN 1.3 DI is still based on the same DI 1.1 specification.
Reported: DMN 1.2b1 — Fri, 11 Oct 2019 20:58 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Update XML Namespaces for DMN 1.3

Update the XML namespaces with the following values:

DMN13.xsd: https://www.omg.org/spec/DMN/20191111/MODEL/
DMNDI13.xsd: https://www.omg.org/spec/DMN/20191111/DMNDI/
FEEL: https://www.omg.org/spec/DMN/20191111/FEEL/
Updated: Mon, 30 Mar 2020 19:50 GMT

DMN v1.2 specification

Key: DMN13-21
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
Using this "issue" as a place to post new versions of the spec as we close each ballot. The track changes will be cumulative but comments will map changes to issue numbers. Also posting meta-model files.
Reported: DMN 1.1 — Tue, 23 Aug 2016 10:47 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
Close old meta-issue

This was a place to collect some files for the DMN 1.2 RTF final report and input to the 1.3 spec. It was deferred by default.
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- Class_Diagram__DMN__BKM.svg 199 kB (image/svg+xml)
- Class_Diagram__DMN__BusinessContext.svg 168 kB (image/svg+xml)
- Class_Diagram__DMN__DMNElement.svg 314 kB (image/svg+xml)
- Class_Diagram__DMN__Decision.svg 446 kB (image/svg+xml)
- Class_Diagram__DMN__DecisionTable.svg 492 kB (image/svg+xml)
- Class_Diagram__DMN__Definitions.svg 366 kB (image/svg+xml)
- Class_Diagram__DMN__Expressions.svg 326 kB (image/svg+xml)
- Class_Diagram__DMN__ExpressionsL3.svg 214 kB (image/svg+xml)
- Class_Diagram__DMN__Extensibility.svg 97 kB (image/svg+xml)
- Class_Diagram__DMN__InputData.svg 62 kB (image/svg+xml)
- Class_Diagram__DMN__KnowledgeSource.svg 194 kB (image/svg+xml)
- Class_Diagram__DecisionService.svg 115 kB (image/svg+xml)
- DC.xsd 6 kB (text/xml)
- DI.xsd 5 kB (text/xml)
- DMN 1.2_ballot10 clean 70.pdf 5.82 MB (application/pdf)
- DMN 1.2_ballot10 markup 70.pdf 6.17 MB (application/pdf)
- DMN 1.2_ballot11 clean 70.pdf 5.87 MB (application/pdf)
- DMN 1.2_ballot11 markup 70.pdf 6.43 MB (application/pdf)
- DMN 1.2_ballot12 clean 70.pdf 5.87 MB (application/pdf)
- DMN 1.2_ballot12 markup 70.pdf 6.44 MB (application/pdf)
- DMN 1.2_ballot13 clean 70.pdf 5.94 MB (application/pdf)
- DMN 1.2_ballot13 markup 70.pdf 6.53 MB (application/pdf)
- DMN 1.2_ballot15 clean 70.pdf 6.30 MB (application/pdf)
- DMN 1.2_ballot15 markup 70.pdf 7.11 MB (application/pdf)
- DMN 1.2_ballot18 clean.pdf 6.38 MB (application/pdf)
- DMN 1.2_ballot18 markup.pdf 7.21 MB (application/pdf)
- DMN 1.2_ballot19 clean.pdf 6.50 MB (application/pdf)
- DMN 1.2_ballot19 markup.pdf 7.60 MB (application/pdf)
- DMN 1.2_ballot2.pdf 5.65 MB (application/pdf)
- DMN 1.2_ballot20 clean.pdf 6.49 MB (application/pdf)
- DMN 1.2_ballot20 markup.pdf 7.42 MB (application/pdf)
- DMN 1.2_ballot3.pdf 5.72 MB (application/pdf)
- DMN 1.2_ballot4.pdf 5.78 MB (application/pdf)
- DMN 1.2_ballot5.pdf 5.89 MB (application/pdf)
- DMN 1.2_ballot6.pdf 5.91 MB (application/pdf)
- DMN 1.2_ballot7 clean 70.pdf 5.72 MB (application/pdf)
- DMN 1.2_ballot7 markup 70.pdf 6.05 MB (application/pdf)
- DMN 1.2_ballot8 clean 70.pdf 5.73 MB (application/pdf)
- DMN 1.2_ballot8 markup 70.pdf 6.06 MB (application/pdf)
- DMN 1.2_ballot9 clean 70.pdf 5.74 MB (application/pdf)
- DMN 1.2_ballot9 markup 70.pdf 6.08 MB (application/pdf)
- DMN 1.2_draft v1 clean.pdf 6.31 MB (application/pdf)
- DMN 1.2_draft v1 markup.pdf 7.40 MB (application/pdf)
- DMN 1.2_draft v2 clean.pdf 6.74 MB (application/pdf)
- DMN 1.2_draft v2 markup.pdf 7.84 MB (application/pdf)
- DMN 1.2_draft v2.odt 7.71 MB (application/vnd.oasis.opendocument.text)
- DMN 1.2_draft v3 clean.pdf 6.85 MB (application/pdf)
- DMN 1.2_draft v3 markup.pdf 7.93 MB (application/pdf)
- DMN 1.2_draft v3.odt 7.72 MB (application/vnd.oasis.opendocument.text)
- DMN 1.2_draft v4 clean.pdf 6.49 MB (application/pdf)
- DMN 1.2_draft v4 markup.pdf 7.81 MB (application/pdf)
- DMN 1.2_draft v4.odt 7.73 MB (application/vnd.oasis.opendocument.text)
- DMN 1.2_draft v5 clean.pdf 6.48 MB (application/pdf)
- DMN 1.2_draft v5 markup.pdf 7.82 MB (application/pdf)
- DMN 1.2_draft v5.odt 7.73 MB (application/vnd.oasis.opendocument.text)
- DMN 1.2_draft v6 clean.pdf 6.48 MB (application/pdf)
- DMN 1.2_draft v6 markup.pdf 7.41 MB (application/pdf)
- DMN 1.2_draft v6.odt 7.73 MB (application/vnd.oasis.opendocument.text)
- DMN 1.2_draft v7 clean.pdf 6.96 MB (application/pdf)
- DMN 1.2_draft v7 markup.pdf 7.81 MB (application/pdf)
- DMN 1.2_draft v8 clean.pdf 6.51 MB (application/pdf)
- DMN 1.2_draft v8 markup.pdf 7.73 MB (application/pdf)
- DMN12.xsd 22 kB (text/xml)
- DMN12_MagicDraw.mdzip 288 kB ()
- DMNDI.xsd 4 kB (text/xml)
- DMNDI12.xmi 33 kB ()
- DMNDI12_MagicDraw.mdzip 96 kB ()
- DMNDI12_MagicDraw.xmi 262 kB ()
- Figures - Chapter 11 - Diagrams.zip 60 kB (application/zip)
- class__DMN_DI.png 6 kB (image/png)
- class__DMN_DI.svg 42 kB (image/svg+xml)
- class__DMN_Diagram.png 22 kB (image/png)
- class__DMN_Diagram.svg 154 kB (image/svg+xml)
- class__DMN_Diagram_Element.png 16 kB (image/png)
- class__DMN_Diagram_Element.svg 94 kB (image/svg+xml)
- class__DMN_Edge.png 12 kB (image/png)
- class__DMN_Edge.svg 70 kB (image/svg+xml)
- class__DMN_Label.png 9 kB (image/png)
- class__DMN_Label.svg 63 kB (image/svg+xml)
- class__DMN_Shape.png 22 kB (image/png)
- class__DMN_Shape.svg 156 kB (image/svg+xml)
- class__DMN_Style.png 23 kB (image/png)
- class__DMN_Style.svg 217 kB (image/svg+xml)
- examples.zip 790 kB (application/zip)

ranges do not map to the semantic domain

Key: DMN13-19
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
section 10.3.2.7 Ranges says that ranges map to the semantic domain. But in DMN 1.1, ranges are unary tests and as such, do not map to the semantic domain. Also, the literal context shown is wrong, as you cannot have the entry 'soon' with value of a range (such value would have to map to the semantic domain).
Now, in DMN 1.2, perhaps we would like to map unary tests to the semantic domain, but it must be all unary tests, and not only ranges.

Proposed remove section 10.3.2.7
Reported: DMN 1.1 — Fri, 6 Apr 2018 17:36 GMT
Disposition: Duplicate or Merged — DMN 1.3
Disposition Summary:
Covered by Range builtins

See ~~DMN13-139~~
Updated: Mon, 30 Mar 2020 19:50 GMT

No item definition for function definition

Key: DMN13-7
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
If a function definition is the value expression of an information item, then that information item should have an item definition that gives the type of the function definition. E.g., the type of a function of two numeric arguments that returns their sum should be something like function(number, number) returns number but we have no way to express such an item definition
Reported: DMN 1.0 — Thu, 6 Aug 2015 22:40 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
add FunctionItem to ItemDefinition MM, XSD, and spec text

See attached word doc
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- DMN12.xsd 22 kB (text/xml)
- DMN13-7-v3.docx 86 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Need group artifact in DRD, metamodel, and XSD

Key: DMN13-6
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Group is an unfilled rectangle enclosing various elements in the DRD, with meaning defined by the modeler. It follows the usage defined by BPMN, an “artifact” with no operational semantics, simply an annotation of the model.
Reported: DMN 1.0 — Thu, 20 Aug 2015 00:13 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Add Group to spec, MM, and XSD fashioned after BPMN

See attached word doc
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- Issue DMN13-6 Proposal - Artifacts Metamodel Section (5).docx 328 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

mix up of list and non-list in filter expression example

Key: DMN13-29
Status: closed
Source: Signavio GmbH ( Dr. Bastian Steinert)
Summary:
Section 10.3.2.5 includes a few examples for the filter expression. In particular it shows the following example:
[ {x:1, y:2}, {x:2, y:3} ][x=1] = {x:1, y:2}

The result of this expression is a context (an object). I first thought this must be a mistake, as the filter expression should always return a list.

I then found the following sentence: 'Singleton lists are equal to their single item.', showing that the above expression returns a non-list value by intention.

I wonder how the need for mixing up lists and non-list (with the so called singleton list) has arisen. I have never seem something like it before and I have difficulties to see its value. In addition, I could not find a second sentence in the entire standard that also uses or describes the concept of singleton lists.

Therefore, I would like to propose removing this single sentence about singleton-lists and would like to change the example to look like this:
[ {x:1, y:2}, {x:2, y:3} ][x=1] = [{x:1, y:2}]
Reported: DMN 1.1 — Tue, 1 Nov 2016 13:03 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Correct the example in 10.3.2.5

The example on section "10.3.2.5" is missing the list operator in the result.
Updated: Mon, 30 Mar 2020 19:50 GMT

FEEL does not support named ranges

Key: DMN13-59
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
in 10.3.2.7, the literal context example shows third entry where context expression is a unary tests. This is not allowed.
Reported: DMN 1.1 — Thu, 10 Nov 2016 16:16 GMT
Disposition: Duplicate or Merged — DMN 1.3
Disposition Summary:
Covered by new Range builtins

See ~~DMN13-139~~
Updated: Mon, 30 Mar 2020 19:50 GMT

Equality for date, date and time, time and inequality for date doesn't use the value function, which make the <= and >= operations useless and = operation behaves differently as < and >

Key: DMN13-35
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Imagine the following two date and time values (note that both values are the same instant in time on the time line):
- date and time("2017-11-10T11:00@Europe/Paris")
- date and time("2017-11-10T10:00Z")
If the user uses FEEL expressions he is very surprised about the results:
date and time("2017-11-10T11:00@Europe/Paris") - date and time("2017-11-10T10:00Z") -> result is PT0S, which means same instant on time line date and time("2017-11-10T11:00@Europe/Paris") < date and time("2017-11-10T10:00Z") -> result is false date and time("2017-11-10T11:00@Europe/Paris") > date and time("2017-11-10T10:00Z") -> result is false date and time("2017-11-10T11:00@Europe/Paris") = date and time("2017-11-10T10:00Z") -> result is false
If the user wants to check if both date and time values are the same instant on the time line he must use the following FEEL expression:
(date and time("2017-11-10T11:00@Europe/Paris") - date and time("2017-11-10T10:00Z")) = Duration("PT0S")
If the user uses a combination of < or > with = the underlying operations are not really understandable:
date and time("2017-11-10T11:00@Europe/Paris") >= date and time("2017-11-10T10:00Z")
This expressions says in the curently defined semantics in FEEL: "Is the left instant of time greater than the right instant in time or are the properties of the left value equal to the properties of the right value".

This is not "Friendly Enough" to the user and the source of very many misunderstandings.

Recommendation:
- Therefore the operators =, !=, <, >, <= and >= should ALL use the defined value functions.
- Additionally we recommend to introduce an additional property "value" for date, time, date and time, years and months duration, days and time duration (see table 53 on page 126). The property returns the value of the value function using type number.
- Introduce a new built-in function "same properties(value1, value2)" that compares all properties of value1 and value2 for equality. This built-in function reflects the currently specified behaviour of equality for date, date and time, time.
Reported: DMN 1.1 — Mon, 2 Oct 2017 10:05 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
use timeline semantics for comparison of dates

see attached .docx file
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- DMN13-35-v3.docx 17 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Imprecise result for example calculation of function PMT and may be typo or rounding issue

Key: DMN13-34
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
In chapter "10.6.5 Invocation of user-defined PMT function" the expected result is mentioned as: 3975.982590125562

We think that the expected result should be: 3975.982590125552338278440100112431

If the decimal function would be used the result would be:
decimal(PMT(requested product.rate, requested product.term, requested product.amount),12) = 3975.982590125552
May be the decimal function is missing?

Additional issue: In both cases (with or without the usage of decimal()) the 11th position after the decimal point is a 5 and not a 6. Or is there a rounding mistake/issue?

3975.982590125552
Reported: DMN 1.1 — Thu, 12 Oct 2017 09:46 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
fix result of calculation

The result of the PMT calculation in Section 10.6.5 is incorrect.
Updated: Mon, 30 Mar 2020 19:50 GMT

string built-in underspecified

Key: DMN13-56
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(from Bruce)
Table 58 asserts the string constructor operates on any non-null argument, but it does not define the semantics, in particular a)string(list); b)string(complexType). These should either atomize the value and concatenate the strings of the atoms, or report an error or null. Even though Table 58 says null is not in the domain, it also says that string(null)=null. It would make more sense (to me) that string(null)=””.
Reported: DMN 1.1 — Mon, 2 Jan 2017 20:05 GMT
Disposition: Duplicate or Merged — DMN 1.3
Disposition Summary:
duplicate of dmn13-27

duplicate of dmn13-27
Updated: Mon, 30 Mar 2020 19:50 GMT

Case-aware and case-insensitive

Key: DMN13-75
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
A number of issues are considering changes to reserved words, built-ins etc. In general these changes should leave the standard case-aware (cases used by a user in naming something should be preserved) but case-insensitive (date is the same as Date and dAte). Any restrictions to names should reflect case insensitivity and interchange should maintain case.
Reported: DMN 1.1 — Mon, 18 Jul 2016 17:06 GMT
Disposition: Closed; Out Of Scope — DMN 1.3
Disposition Summary:
changing semantics of identifiers is not backward compatible

changing semantics of identifiers is not backward compatible
Updated: Mon, 30 Mar 2020 19:50 GMT

Disambiguation for Modulo / Remainder function

Key: DMN13-124
Status: closed
Source: Red Hat ( Matteo Mortari)

Summary:

Dividend	Divisor	MOD() from Microsoft Excel, Google Sheets, LibreOffice Calc, Wolfram Alpha, etc.	Java % or BigDecimal#remainder or other languages default
10	4	2	2
10	-4	-2	2
-10	4	2	-2
-10	-4	-2	-2

or to other implementation languages where the definition of Modulo/Remainder is not explicit, or the default one is not consistent with Spreadsheet default one.

Reported: DMN 1.2b1 — Fri, 4 Jan 2019 18:34 GMT
Disposition: Duplicate or Merged — DMN 1.3
Disposition Summary:
corrected in dmn13-125

corrected in dmn13-125
Updated: Mon, 30 Mar 2020 19:50 GMT

instance of clarification

Key: DMN13-144
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Table 56 describes the semantics of the instance of operator.

It does not specify the expected result if the instance of expression is incorrect. For example, there is syntactic error, the type name cannot be found (e.g. typo or missing import) or if the type expression is incorrect (e.g. list<> or context<>).
Reported: DMN 1.2 — Tue, 12 Feb 2019 10:40 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Clarify type lattice L and tie 'instance of' semantics to L

see attached word doc
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- DMN13-144-proposal-v6.docx 101 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- DMN13-144-proposal-v6.pptx 63 kB (application/vnd.openxmlformats-officedocument.presentationml.presentation)

Make explicit reference to sample standard deviation

Key: DMN13-131
Status: closed
Source: Red Hat ( Matteo Mortari)

Summary:

The specification in chapter "10.3.4.4 List functions" for built-in function stddev does not explicit if it's meant to be population or sample standard deviation.
However based on the example provided "stddev( 2, 4, 7, 5 ) = 2.0816659994661" would indicate it is meant to be the sample standard deviation --which is undefined for a single 1 sample value

In order to be explicit, it is suggested to change the table entry as:

Name(parameters)	Parameter Domain	Description	Example
stddev( list ) stddev( n 1 , ..., n n )	list is a list of number. n 1 ... n n are numbers.	Returns the (sample) standard deviation of the list of numbers. If the list is empty, returns null. If the list contains only one number item, if n is a single number returns null.	stddev( 2, 4, 7, 5 ) = 2.0816659994661 stddev( [ 47 ] ) = null stddev( 47 ) = null stddev( [ ] ) = null

Reported: DMN 1.2b1 — Fri, 18 Jan 2019 15:30 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Clarify the semantics of the stddev() function

See revised text.
Updated: Mon, 30 Mar 2020 19:50 GMT

Wrong example in chapter "10.3.1.5"

Key: DMN13-133
Status: closed
Source: Red Hat ( Matteo Mortari)

Summary:

The specification in chapter "10.3.1.5 Contexts, Lists, Qualified Names, and Context Lists"

presents the following example:

[{a: [{b: 1}, {b: [2.1, 2.2]}]}, {a: [{b: 3}, {b: 4}, {b: 5}]}].a.b =
[[{b: 1}, {b: [2.1, 2.2]}], [{b: 3}, {b: 4}, {b: 5}]].b =
[[1, [2.1, 2.1]],[ 3, 4, 5]]

However line 2 is wrong since DMNv1.2 dropped the equivalence that

a=[a]

therefore line 2 is problematic:

[[{b: 1}, {b: [2.1, 2.2]}], [{b: 3}, {b: 4}, {b: 5}]].b =
 ^ b property is not available here

as at the cursor position is not a context but two items of the root list.

It is proposed to replace the example as follows:

[{a: {b: 1}}, {a: {b: [2.1, 2.2]}}, {a: {b: 3}}, {a: {b: 4}}, {a: {b: 5}}].a.b =
[{b: 1}, {b: [2.1, 2.2]}, {b: 3}, {b: 4}, {b: 5}].b =
[1, [2.1, 2.1], 3, 4, 5]

Reported: DMN 1.2b1 — Sat, 26 Jan 2019 09:34 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Fix typo in the example on chapter 10.3.1.5

See revised text.
Updated: Mon, 30 Mar 2020 19:50 GMT

Remove reference to SQL and PMML three value logic to eliminate misinterpretation

Key: DMN13-106
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
The spec says: Three-valued logic (true, false, null) based on SQL and PMML
This statement can lead to misinterpretation (given their understanding of the SQL and/or PMML three value logic) for nothing given that we define the semantic of the FEEL three Value logic clearly below.
Reported: DMN 1.2b1 — Tue, 20 Nov 2018 17:12 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Remove reference to SQL and PMML three value logic

This reference to SQL and PMML is not needed and may lead to misinterpretation. Simply remove that reference.
Updated: Mon, 30 Mar 2020 19:50 GMT

Built-in functions only described in chapter "10.3.2.6 Context", and not described in the "10.3.4 Built-in functions"

Key: DMN13-126
Status: closed
Source: Red Hat ( Matteo Mortari)

Summary:

In section "10.3.2.6 Context" two built-in functions are described: get value(), get entries().
However these functions are not summarized later in section "10.3.4 Built-in functions"

Describing all built-in functions in latter section "10.3.4 Built-in functions" is important to agree on the function parameters name.

Agree on the function parameters name is important for invoking function and binding parameters by name, rather than positional.

I propose to add a new section inside "10.3.4 Built-in functions", with the following:

10.3.4.x Context function

Table xx defines Context functions.

Table xx: Semantics of Context functions

Name(parameters)

Parameter Domain

Description

Example

get value(m, key)

context, string

select the value of the entry named key from context m

get value({key1 : "value1"}, "key1") = "value1"
get value({key1 : "value1"}, "unexistent-key") = null

get entries(m)

context

produces a list of key,value pairs from a context m

get entries({key1 : "value1"}) = [ { key : "key1", value : "value1" } ]
get entries({key1 : "value1"})[key="key1"].value = "value1"

Reported: DMN 1.2b1 — Thu, 15 Nov 2018 15:42 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Add get entries() and get value() functions to the function tables in chapter 10

See revised text.
Updated: Mon, 30 Mar 2020 19:50 GMT

"get value" and "get entries" function not in built-in functions list

Key: DMN13-122
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The above section mentions to two context-related functions "get value" and "get entries" that are not in the built in functions list. Are they meant to be there?
Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:18 GMT
Disposition: Duplicate or Merged — DMN 1.3
Disposition Summary:
duplicate of dmn13-126

closed as duplicate
Updated: Mon, 30 Mar 2020 19:50 GMT

example shows literal inline function definition whereas grammar says function definitions only in boxed expressions.

Key: DMN13-121
Status: closed
Source: Montera Pty Ltd ( Greg McCreath)
Summary:
The spec example shows a function definition inline in a literal expression using sort(). My take on the FEEL grammar spec is that a function definition can only exist inside a boxed expression, not inside a literal expression. A function definition inside a literal expression whose body has names with spaces or additional characters makes the parsing of the entire expression before execution darn hard - we'll I haven't figured it out anyways.

In the specific case of the sort function, the type of the 'list' parameter may only be known at execution time, and thus the types of the arguments to the 'precedes' function can only be known at execution time - that is, when actually executing the sort. And to execute a sort, you need to pass it its arguments - which means a parsed function definition. If that function definition has names with spaces, then parsing can't be done until the types are known - during the sort execution. A little bit chicken an egg.

But, if I read the spec correctly, you should not be able to have a function definition inside a literal expression. In which case, it is parsed separately to its invoking function and the above is not an issue.

As a note, the given example and some tests in the TCK (which I am not sure should be there) involve simple params or simple names and can be parsed. But the scenario above is not covered by the TCK.

Happy to be guided otherwise. An all advice appreciated.
Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:00 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
change grammar rule 2.h. in ch 10 to use expression instead of textual expression

see revised text
Updated: Mon, 30 Mar 2020 19:50 GMT

Minor typos in the FEEL grammar

Key: DMN13-120
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Typo in rule

51. comparison =
a.expression , ( "=" | "!=" | "<" | "<=" | ">" | ">=" ) , expression |
b.expression , "between" , expression , "and" , expression |
c.expression , "in" , positive unary test ;
d.expression , "in" , " (", positive unary tests, ")" ;

c. should have | at the end not ;

We should replace non-terminal Boolean literal with boolean literal for consistency.
Reported: DMN 1.2b1 — Sat, 8 Dec 2018 19:36 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
fix minor typos in FEEL grammar rules

see attachment
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- DMN13-316-proposal-v1.docx 15 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Example: Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses values inverted

Key: DMN13-98
Status: closed
Source: Red Hat ( Matteo Mortari)
Summary:
Fig 11.28 on page 179 of formal-19-01-05 shows a screenshot of Applicant Data.
The values of Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses are inverted, if the end result of executing the model is for decision Routing = "ACCEPT".

In other words; currently the PDF document display as:
Applicant Data.Monthly.Income = 10000 (ten-thousands)
Applicant Data.Monthly.Expenses = 100000 (a-hundred-thousands)
but actually it should be:
Applicant Data.Monthly.Income = 100000 (a-hundred-thousands)
Applicant Data.Monthly.Expenses = 10000 (ten-thousands)
if the decision Routing should evaluate to "ACCEPT".

Also, check spelling of "Stragegy" in Fig 11.30
Reported: DMN 1.2b1 — Wed, 10 Oct 2018 13:13 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
*Replace erroneous figures *

Monthly.Income and Monthly.Expenses corrected in figure 11.28
Typo corrected in figure 11.30
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- Fig 11-28.PNG 14 kB ()
- Fig 11-30.PNG 3 kB ()

Need additional FEEL Types

Key: DMN13-40
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
It is possible for a FEEL expression to generate a value with no possible datatype (as they are currently defined). Here are some examples:

1. If x>0 then x else ‘value must be greater than 0’

2. [0,’a’]

3. [0,[1,2]]

In the first case the result is either a string or a number. In the second case it is a list (collection) where the items are of different types. In the third case, which is more borderline, the collection items include a number and a list, again not the same type. The third case also relates, I believe, to ~~DMN12-115~~.

The rules for item definition, in combination with FEEL base types, do not support any of these cases. That means a variable with these values cannot have a typeRef. Some implementations may depend on the typeRef to compile the expression properly, and/or may prevalidate to ensure that a typeRef is provided.

I suggest one or more of these as possible solutions:

1. Allow item definition to include a union of existing types, e.g. number or string

2. Allow typeRef to be a list, e.g. feel:number, feel:string

3. Add new base type, anyAtomicType, meaning any of the FEEL base types.
Reported: DMN 1.1 — Thu, 3 Nov 2016 14:54 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
We support homogeneous list types. Need better justification for heterogeneous list or union types.

DMN 1.2 adds type lattice, supports homogeneous list types like list<string>, promotes heterogeneous list types to list<Any>, which is good enough, unless more evidence to the contrary is presented.
Updated: Mon, 30 Mar 2020 19:50 GMT

Ambiguity between qualified name and path operation

Key: DMN13-41
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Qualified name and path expression uses both the dot '.' character. Therefore it is very hard to distinguish between these cases.

Example:
- {p:{name: "jack"}, persons:[p,p].name}.persons
  results to
  ["jack", "jack"]
- {p:{name: "jack"}, persons:[p,p], path : persons.name }.path
  results to
  ["jack", "jack"]
  (or is dynamic path access not possible in FEEL?)
- {p:{name: "jack"}, persons:[p,p], qn: p.name }.qn
  results to
  "jack"
Reported: DMN 1.1 — Wed, 3 May 2017 15:16 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
Not an issue

All listed FEEL examples are valid FEEL expressions. Example 1 shows a path expression, example 2 a qualified name with an implicit path expression.
Updated: Mon, 30 Mar 2020 19:50 GMT

Specification of type for instance of operator misses information

Key: DMN13-37
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
The FEEL syntax allows qualified names as type for an instance of expression. But the semantic mapping is not specified. Therefore, is this a valid FEEL expression:
{a: {b: 1}, c: 2 instance of a.b}.c
and this the corresponding result: "true"?

What types can be used for instance of? Only datatypes (like string, number, ...)? Can we use kinds (list, context, ...), too?

Since singleton lists are equal to the single element and kinds are allowed for instance of, everything is instance of list, am I right?
Reported: DMN 1.1 — Wed, 3 May 2017 09:48 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
clean up specification of types, and add syntax for parametrized context, list, and function types

see attached documents
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- DMN13-37-proposal-v3.docx 174 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- DMN13-37-proposal-v3.pptx 63 kB (application/vnd.openxmlformats-officedocument.presentationml.presentation)

Missing semantic specification for FEEL for and quantified expression

Key: DMN13-45
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
The semantic mapping is not accurately specified for the "in" expression. What datatypes, kinds can be used as iteration source. Only lists and single elements? Is it possible to iterate over context entries of a context? Are there any other datatypes that must be considered?
Reported: DMN 1.1 — Wed, 3 May 2017 09:30 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
Issue addressed by "iteration context" added in 1.2

DMN 1.2 added the notion of "iteration context" and is described in 10.3.2.14. This seems to address the issue.
Updated: Mon, 30 Mar 2020 19:50 GMT

Can listed input data option be used in encapsulated decisions of decision service?

Key: DMN13-53
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The definition of decision service in 6.2.5 says this:
_The border SHALL enclose all the
encapsulated decisions, and no other decisions or input data. The border MAY enclose other DRG elements but these
will not form part of the definition of the Decision Service._

This is a problem because it is not possible to omit the Input data if they are input to encapsulated decisions and they use the listed input data option.
Reported: DMN 1.1 — Thu, 26 Jan 2017 16:27 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
spec is clear enough

No change needed. The current spec is clear about listed input data and the use of listed input data in a decision service would be unambiguous and is clearly allowed.
Updated: Mon, 30 Mar 2020 19:50 GMT

Expressions in Input Entries

Key: DMN13-13
Status: closed
Source: Sapiens Decision NA ( Mr. Gil Ronen)
Summary:
Input Entries are defined as unary tests and as such do not allow even simple expressions. The need to exit the decision table into other FEEL constructs for simple expressions such as “Dividend Income * 0.30” makes the overall logic less readable. There are currently several tools that support expressions in decision table cells and this feature is also on Jan and James’ wishlist. The latter wrote about in more detail (http://blog.luxmagi.com/2016/04/our-dmn-2-0-wish-list-i-decision-logic/) so I won’t repeat it except to quote “This is something we see a lot of demand for by business users of DMN ‘in the field’.”
Reported: DMN 1.1 — Thu, 5 May 2016 14:34 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
Support expressions in DT input entries

This is already supported in DMN 1.2. A positive unary test can be an Expression.
Updated: Mon, 30 Mar 2020 19:50 GMT

Missing "date" FEEL type in some enumerations

Key: DMN13-66
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
FEEL date type is presented in section 10.3.2.3.5 however in some sections of the specification where all FEEL type are enumerated, the date type is omitted.
- Section 7.3.2
  If the type language is FEEL the built-in types are the FEEL built-in data types: number, string, boolean, days and time duration, years and months duration, time, and date and time.
- Section 10.3.1.3
  FEEL supports the following datatypes:
  - number
  - string
  - boolean
  - days and time duration
  - years and months duration
  - time
  - date and time
- In section 10.3.2.12, it is not part of table 42
- Date is part of S-FEEL and this paragraph from section 9.3 should probably be modified too:
  S-FEEL does not support FEEL date and time. However, it supports the date type, which is like FEEL date and time with hour, minute, and second required to be absent. The lexical and value spaces of FEEL date are the literal and value spaces of the XML Schema date datatype.
Reported: DMN 1.1 — Tue, 1 Nov 2016 14:30 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
add missing 'date' type in several places in spec

see revised text
Updated: Mon, 30 Mar 2020 19:50 GMT

Broken HTTP links

Key: DMN13-67
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
First page of spec contains broken links:

Link http://www.omg.org/spec/DMN/20151101/dmn.xmi
In the PDF document seems to be broken. It contains a space after “spec/”.

Link http://www.omg.org/spec/DMN/20151101/ch11example.xml
in the PDF document seems to be broken. It contains a space after “spec/”.
Reported: DMN 1.1 — Mon, 31 Oct 2016 19:45 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
Fixed on OMG website

This has been treated as a broken link and fixed by OMG on their website. No action needed by RTF.
Updated: Mon, 30 Mar 2020 19:50 GMT

Description of Table 44 is out of place

Key: DMN13-72
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Most is described after Table 46 Needs to be moved just after Table 44.
Reported: DMN 1.1 — Mon, 15 Aug 2016 22:53 GMT
Disposition: Resolved — DMN 1.3
Disposition Summary:
move 2 paragraphs following Table 46 to before Table 45

move indicated text
Updated: Mon, 30 Mar 2020 19:50 GMT

Remove rule#32 additional name symbols from BNF

Key: DMN13-23
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
These additional symbols do not provide much more expressiveness for name and may create a lot parsing issues
Reported: DMN 1.1 — Thu, 9 Feb 2017 16:13 GMT
Disposition: Closed; Out Of Scope — DMN 1.3
Disposition Summary:
non-backward compatible FEEL grammar change

would need 2.0 RFP
Updated: Mon, 30 Mar 2020 19:50 GMT

Missing FEEL namespace in the header of the xml sample

Key: DMN13-62
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
The sample provided at http://www.omg.org/spec/DMN/20151101/ch11example.xml contains the following namespaces defined at the root level:

xmlns:ex="http://www.omg.org/spec/DMN/20151101/ch11example.xml" xmlns="http://www.omg.org/spec/DMN/20151101/dmn.xsd" namespace="http://www.omg.org/spec/DMN/20151101/ch11example.xml"

FEEL is not included, hence when used to define types it is used as

<typeRef xmlns:ns2="http://www.omg.org/spec/FEEL/20140401">ns2:number</typeRef>

Adding it at the root will make the xml more user-friendly.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:32 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
FEEL namespace is in the header of sample XML files in DMN 1.2

please verify and let's close
Updated: Mon, 30 Mar 2020 19:50 GMT

Typo in the sample xml

Key: DMN13-61
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
The sample XML specified on the first of the spec contains a typo.

Sample is http://www.omg.org/spec/DMN/20151101/ch11example.xml

Strategy is misspelled. See below:

<itemDefinition name="Stategy" id="strategy_t">
<typeRef
xmlns:ns2="http://www.omg.org/spec/FEEL/20140401">ns2:string</typeRef>
<allowedValues>
<text>"BUREAU","DECLINE","THROUGH"</text>
</allowedValues>
</itemDefinition>
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:28 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
no "Stategy" in DMN 1.2 sample file

This seems to fixed in 1.2. Please verify, and let's close.
Updated: Mon, 30 Mar 2020 19:50 GMT

Broken HTTP links

Key: DMN13-64
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
The first page of the spec contains several HTTP links. Some of them seem to be broken due to an extra space.

Link http://www.omg.org/spec/DMN/20151101/dmn.xmi
In the PDF document seems to be broken. It contains a space after “spec/”.

Link http://www.omg.org/spec/DMN/20151101/ch11example.xml
in the PDF document seems to be broken. It contains a space after “spec/”.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:26 GMT
Disposition: Duplicate or Merged — DMN 1.3
Disposition Summary:
merge with ~~DMN13-67~~

duplicate
Updated: Mon, 30 Mar 2020 19:50 GMT

Additional name symbols

Key: DMN13-57
Status: closed Implementation work Blocked
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
SFEEL and FEEL grammar are ambiguous due to “additional name symbols”. For example,
- Person.Loan is a Name or Qualified Name?
- Loan+123 is a Name or an Expression ?
I don’t think the “additional name symbols” add much value when it comes to having business friendly name. If we want to keep them, we should use the SQL approach and disambiguate these identifiers with quotation marks. For example, ‘Loan+123’ is an identifier while Loan+123 an expression.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:39 GMT
Disposition: Closed; Out Of Scope — DMN 1.3
Disposition Summary:
non-backward compatible FEEL grammar change

would need a 2.0 RFP
Updated: Mon, 30 Mar 2020 19:50 GMT

SFEEL grammar readbility

Key: DMN13-60
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
The grammar contains several sub-grammars each one with its own start non-terminal: expression, simple expressions, simple unary tests.

The grammar should be broken in 3 grammars, and common part to make things more obvious. It will make the grammars more readable and help the CL3 implementation. The spec should also specify for each grammar where it used (e.g. unary tests are used in the Input Entries of a Decision Table etc).
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:37 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
SFEEL is deprecated

No editorial changes for SFEEL
Updated: Mon, 30 Mar 2020 19:50 GMT

Naming inconsistency

Key: DMN13-63
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
Naming inconsistency in Figure 70.

Use Pre-bureau instead of Pre-Bureau or change Post-bureau to Post-Bureau.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:35 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
Ch 11 figures are machine-generated in DMN 1.2, should be consistent

Can someone recheck Ch 11 for consistency, and if OK, let.s close this.
Updated: Mon, 30 Mar 2020 19:50 GMT

Figure 70 does not correspond to example file

Key: DMN13-77
Status: closed
Source: Mid GmbH ( Joachim Back)
Summary:
The example file http://www.omg.org/spec/DMN/20151101/ch11example.xml with document number dtc/15-11-55 does not correspond to the figure 70 on page 147 in chapter 11.3 of the DMN 1.1 specification with document number formal/2016-06-01.
The figure shows an information requirement from decision "Bureau call type" to decision "Pre-bureau risk category", while the XML has an information requirement from decision "Bureau call type" to business knowledge model "Pre-bureau risk category table" in line 972.
The figure shows a knowledge requirement from decision "Routing" to business knowledge model "Routing rules", while the XML has an authority requirement from decision "Routing" to business knowledge model "Routing rules" in lines 1331-1333.
I suggest to correct the XML example file.
Reported: DMN 1.1 — Wed, 15 Jun 2016 14:22 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
Chapter 11 example xml has been fixed

Fixed in 1.2 (generated from same tool)
Updated: Mon, 30 Mar 2020 19:50 GMT

Is really only name allowed in a FEEL path?

Key: DMN13-42
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
The FEEL syntax grammar rule 45 only allows names for a path expression. Is this the real intention or should qualified names be allowed, too?
Otherwise only top level context entries can be accessed.

If only name is allowed, the following example is not possible: "{a:{b:1}}.a.b"
Reported: DMN 1.1 — Wed, 3 May 2017 14:20 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
submitter agrees there is no issue

no issue here
Updated: Mon, 30 Mar 2020 19:50 GMT

FEEL grammar is ambiguous for grammar rule 2.i simple positive unary test when no operator is specified for an endpoint

Key: DMN13-49
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
FEEL grammar rule 2.i for simple positive unary test is ambiguous if no operator is specified. An endpoint is an simple value which can be a simple literal. Additionally the literal specification in grammar rule 2.i can be also a simple literal. This is ambiguous and should be changed.
Reported: DMN 1.1 — Wed, 3 May 2017 08:53 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
ambiguity per se is not a serious issue

there are other ambiguities that are resolved with semantic checks or other rules.
Updated: Mon, 30 Mar 2020 19:50 GMT

Page 71 states that a DT can have 0 inputs. I believe this to be incorrect

Key: DMN13-51
Status: closed Implementation work Blocked
Source: Trisotech ( Mr. Denis Gagne)
Summary:
3rd bullet enumeration on page 71 says:
A set of inputs (zero or more). Each input is made of an input expression and a number of input entries.The
specification of input expression and all input entries is referred to as the input clause.

I blieve it should read:
A set of inputs (one or more). Each input is made of an input expression and a number of input entries.The
specification of input expression and all input entries is referred to as the input clause.
Reported: DMN 1.1 — Tue, 28 Mar 2017 20:34 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
0 input tables (with collect policy) behave as relations

may be useful for level 2 implementations
Updated: Mon, 30 Mar 2020 19:50 GMT

Bug in specification of the ‘Any’ Hit Policy

Key: DMN13-54
Status: closed
Source: Sapiens Decision NA ( Mr. Gil Ronen)
Summary:
The purpose of the ‘Any’ Hit Policy is to allow for overlapping criteria in the rule conditions for the same conclusion. However, each rule also needs to allow for different additional information and messages that are specific to that rule. See attached example decision table. The current text in the specification does not allow for this.

Currently, ‘Any’ is defined in section 8.2.11 as: “Any: there may be overlap, but all of the matching rules show equal output entries for each output, so any match can be used. If the output entries are non-equal, the hit policy is incorrect and the result is undefined. “

Proposal to change the above text to: “Any: there may be overlap, but all of the matching rules show equal output entries for the left-most output column, so any match can be used. If the output entries are non-equal for the left-most output column, the hit policy is incorrect and the result is undefined.“
Reported: DMN 1.1 — Mon, 9 Jan 2017 15:03 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
DMN 1.2 provides annotation columns as well as result columns

annotation columns are not considered in hit policy semantics, they can differ for the ANY policy
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- Any example decision table.PNG 12 kB ()

BigDecimal is not the only mapping of number to Java

Key: DMN13-1
Status: closed
Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
Summary:
Clause 10.3.2.9 shows FEEL number values as mapped to XML decimal, integer, and double, but the only mapping to Java is to BigDecimal. The appropriate mapping to Java, like the appropriate mapping to XML, depends on the range and intent of the data element. BigDecimal is rarely used for anything but currency. Java int and double are much more likely to be appropriate for most data items. The mapping of number to Java should be just as flexible as the mapping to XML and PMML.
Reported: DMN 1.0 — Wed, 9 Jul 2014 21:23 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

FEEL operators in names

Key: DMN13-14
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
If FEEL variable names can contain spaces, they should not be allowed to contain operator names like and, or, etc. for example the name "make and model" in the Collections of Cars example should not be allowed. It might be possible to determine from the context whether this is a name or an expression of 2names, it's just too hard.
Reported: DMN 1.1 — Sat, 14 May 2016 23:31 GMT
Disposition: Closed; Out Of Scope — DMN 1.3
Disposition Summary:
non-backward compatible FEEL grammar change

would need 2.0 RFP
Updated: Mon, 30 Mar 2020 19:50 GMT

Decisions can be used for many things, do we need a taxonomy?

Key: DMN13-11
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Decisions in DMN are actually expressions in a formal language (by default, FEEL). These expressions describe a range of computations and calculations, including constants like 42, calculations like (x-y)/2, and decisions using decision tables. It's awkward referring to constants and math formulas as 'decisions', but most of the time, decision is the right word. Should we allow some 'decoration' of the decision rectangle (e.g. an icon) to indicate whether it is a constant, a calculation, a decision, etc.?

Another observation - InputData and BKM are not really needed to build a working DMN product. Decisions can be used instead of InputData. All your decision services would use input decisions instead of input data. Decisions can be used instead of BKMs, as there is no prohibition about a decision's logic being a FunctionDefinition. This means that decisions can invoke other decisions or simply reference them. Either way, there is an information requirement.
Reported: DMN 1.1 — Mon, 11 Apr 2016 19:42 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
withdrawn by submitter

Do not see much value here.
Updated: Mon, 30 Mar 2020 19:50 GMT

italics and bold used for both typographic literal notation and FEEL semantic exposition

Key: DMN13-5
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
in typographic literals, italics are strings and bold italics are date literals, but in 10.3, italics are feel syntactic elements and bold are semantic elements. Better to have different notations
Reported: DMN 1.0 — Thu, 3 Sep 2015 15:58 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

No notation for ItemDefinition

Key: DMN13-4
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The notion of a 'type' or ItemDefinition is in the metamodel (with some pending issues) and in the semantics and concepts, but little is in the notation. Thus, we have notation that allows you to execute an expression with actual arguments, but no notation to allow validation based on type information without actual values.

We have most of the pieces, so it should not be difficult. E.g., individual values can be number, string, date and time, etc. We can allow numeric ranges using our unary tests, e.g. '>0', '[10..30)', etc. We can allow LOVs using "abc", "def", "ghi". These can be 'simple items', and we can also define structures using something similar to boxed contexts.
Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Business Context links go both ways

Key: DMN13-3
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In XSD, business context pointers are duplicated in both directions. E.g. decisionOwner and decisionMaker point to organizationalUnit, which in turns has pointers back the other way. This duplication adds no new information, just potential for internal inconsistency. I suggest omitting one of these directions; the other one is easily extracted from the serialization by XPATH.
Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Spaces and additional characters in names / identifiers

Key: DMN13-58
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
Having spaces and additional characters in useful from a user / BA perspective. However, is not good practice when it comes to implementing / designing programming languages / DSL. That's mainly due to ambiguities introduced by this approach. This is the reason none of the main stream PL do not support this feature.

I suggest the following approach:
- use spaces and additional characters in labels to improve the usability of FEEL (display labels in DRD diagrams)
- if the name of a DMN entity (e.g. decision) contains a a space of additional character, use ' as delimiters. For example, 'A nice decision name ?'
- reference ItemDefinitions by id and not by name to avoid ambiguities.
- use the same delimiters to handle FEEL keywords as names (e.g. an OutputClause has name/label date)
The same approach has been used successfully for SQL and OCL. OCL 2.4. specification is here
http://www.omg.org/spec/OCL/2.4/
Reported: DMN 1.1 — Wed, 23 Nov 2016 10:58 GMT
Disposition: Closed; Out Of Scope — DMN 1.3
Disposition Summary:
non-backward compatible change to FEEL and metamodel

would need to wait for 2.0 RFP
Updated: Mon, 30 Mar 2020 19:50 GMT

null is not defined in the S-FEEL grammar

Key: DMN13-70
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
null is not defined in the S-FEEL grammar.
But it could be obtained as an input to a decision table so it would make sense to allow this value in the decision table as unitary test.
Reported: DMN 1.1 — Tue, 20 Sep 2016 17:42 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
we decided in DMN 1.2 to "deprecate" SFEEL.

We should not change SFEEL anymore.
Updated: Mon, 30 Mar 2020 19:50 GMT

Semantics of variable in decision table input entry

Key: DMN13-74
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(on behalf of Bruce)
On p122 it says "In Grammar Rule 51c, the qualified name must evaluate to a comparable constant value at modeling time, i.e., the endpoint must be a literal or a named constant". This says variables, except design-time constants, may not be used in decision tables. I think this constraint is not supported by the grammar and eliminates important functionality. Any name in scope should be allowed.
Reported: DMN 1.1 — Mon, 8 Aug 2016 20:37 GMT
Disposition: Closed; No Change — DMN 1.3
Disposition Summary:
No longer an issue

I don't see the prohibition against variables in the current spec. It may have been lifted by the introduction of generalized unary tests. Let's close if no longer an issue.
Updated: Mon, 30 Mar 2020 19:50 GMT

Clarification needed if null is passed as value for optional parameter of built in function

Key: DMN13-26
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Some built-in functions has optional parameters. Chapter 10.3.4 describes "Whenever a parameter is outside its domain, the result of the built-in is null."

Should the following call to a built-in function result to null?
replace("This is a string", "[a-z]", "#", null)
The optional parameter "flags" of the built-in function replace() is null. Parameter domain is string as stated in table 60 on page 133. Null is not in the domain of type string.

This topic was already discussed in the DMN TCK. We think that the behavior should be the same as the function is called without the optional parameter:
replace("This is a string", "[a-z]", "#", null) = replace("This is a string", "[a-z]", "#")
Clarification in the specification is appreciated.

May be we can change the sentence in chapter 10.3.4 on page 130 to: "Whenever a parameter is outside its domain, the result of the built-in is null. If null is passed as value to an optional parameter, the built-in behaves like no value is passed."
Reported: DMN 1.1 — Tue, 10 Oct 2017 14:32 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration

Key: DMN13-25
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Chapter 10.3.2.3.4 time, 10.3.2.3.5 date, 10.3.2.3.6 date-time, 10.3.2.3.7 days and time duration and chapter 10.3.2.3.8 years and months duration defines each a value function. For date time arithmetic operations it would be useful to have this value available in the FEEL semantic domain. Therefore we suggest to add a new property value that is directly available for values of this type. Return type of the value if always a number.

Table 53 should be adjusted accordingly.
Reported: DMN 1.1 — Tue, 10 Oct 2017 09:57 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

No adjustment for last day in month if duration is added/subtracted to date and time value

Key: DMN13-24
Status: closed
Source: ACTICO ( Daniel Thanner)

Summary:

The specification says that the addition/subtraction of a date and time and a years and months duration value is defined as:

date and time (
   date(e1.year +/– e2.years + floor((e1.month+/– e2.months)/12),
   e1.month +/– e2.months – floor((e1.month +/– e2.months)/12) * 12,
   e1.day), 
   time(e1))

If you apply this expression to the following two values:

date and time("2017-08-30T11:00:00Z")
duration("P18M")
you would expect the following results:

date and time("2017-08-30T11:00:00Z") + duration("P18M")  --> result should be date and time("2019-02-28T11:00:00Z")
date and time("2017-08-30T11:00:00Z") - duration("P18M")  --> result should be date and time("2016-02-29T11:00:00Z")

If you apply the values to the defined formula, you get:

date and time (
   date(2017 +/– 1 + floor((8 +/– 6)/12),
   8 +/– 6 – floor((8 +/– 6)/12) * 12,
   30), 
   time("11:00:00Z"))

Addition
which results for addition into:

date and time (
   date(2018 + floor(1,1667),
   14 – floor(1,1667) * 12,
   30), 
   time("11:00:00Z"))

which is:

date and time (date(2019, 2, 30), time("11:00:00Z"))

The adjustment to the last valid day in a month is missing. 30th February is invalid, since February has only 28/29 days.

Subtraction
which results for subtraction into:

date and time (
   date(2016 + floor(0,1667),
   2 – floor(0,1667) * 12,
   30), 
   time("11:00:00Z"))

which is:

date and time (date(2016, 2, 30), time("11:00:00Z"))

The adjustment to the last valid day in a month is missing. 30th February is invalid, since February has only 28/29 days.

Recommendation:
Adjustment to last valid day in month must be added to spec.

Reported: DMN 1.1 — Mon, 2 Oct 2017 12:41 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Improve description of built-in function string()

Key: DMN13-27
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
The expected output of the built-in function string() should be defined for each type. Otherwise it is unclear what the result for a value, for example of type time, is. Is it the string literal or the full expression with built-in function time()?
// which FEEL expression is valid? string(time("11:00:00")) = "11:00:00" string(time("11:00:00")) = "time("11:00:00")"
Recommendation: Introduce a new table that lists example outputs for all types:
- null -> null
- boolean -> "true" or "false"
- string -> "This is a string"
- number -> "-1.234"
- date -> "2017-10-11"
- time -> "11:00:00.123" or "11:00:00.123+02:00" or "11:00:00.123@Europe/Paris"
- date and time -> "2017-10-11T11:00:00.123" or "2017-10-11T11:00:00.123+02:00" or "2017-10-11T11:00:00.123@Europe/Paris"
- days and time duration -> "P2DT3H4M5.123S"
- years and months duration -> "P2Y3M"
- list -> "[1,2,3]"
- context -> "{a: true, b: false}"
- range -> "[1..100]"
- unary test -> "> 10"
- function -> null
Reported: DMN 1.1 — Wed, 11 Oct 2017 09:02 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

FEEL grammar readbility

Key: DMN13-36
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
The grammar contains several sub-grammars each one with its own start non-terminal: expression, simple expressions, unary tests.

The grammar should be broken in several grammars, and common part to make things more obvious. It will help the CL3 implementation.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:37 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Lexical representation of time string has ambiguous definitons

Key: DMN13-32
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
A lexical time string is defined o page 131 by XML Schema Part 2 Datatypes (for local times and offset times) and by ISO 8601 with the extended form of a local time (for zoned times).

Unfortunately XML Schema Part 2 and ISO 8601 has different definitions. Therefore it is unclear which of them to use. Or are both of them valid?

Additionally the user should not have different lexical time string formats for a local time, an offset time or a zoned time.

The list of ambiguities:
- ISO 8601 allows a leading "T" character prefix. XML Schema Part 2 does not.
- ISO 8601 allows optional seconds. In XML Schema Part 2, the seconds are mandatory.
- ISO 8601 allows decimal fraction for seconds and minutes. XML Schema Part does not allow this.
- ISO 8601 allows 00:00:00 and 24:00:00 for midnight. XML Schema Part 2 only allows 00:00:00.
- ISO 8601 allows time offset of hours only. Minutes are optional. XML Schema Part 2 always requires minutes.
Therefore clarification is needed. Which definitions are valid for FEEL? The stricter XML Schema Part 2 or the more user friendly ISO 8601 spec?
Reported: DMN 1.1 — Mon, 13 Nov 2017 15:24 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

More Generic Ways to Define Decision Table Properties

Key: DMN13-38
Status: closed
Source: OpenRules ( Jacob Feldman)
Summary:
I described several issues with the current way of representing decision table properties and made concrete suggestions for improvement in this LinkedIn post: https://www.linkedin.com/pulse/decision-table-properties-dmn-beyond-jacob-feldman
Reported: DMN 1.1 — Sat, 20 May 2017 19:09 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Scope of decision table input/output entries is not well defined in the specification

Key: DMN13-39
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
While the scope of context entry specifically says to include the previous context entry (section 7.3.1), there is no mention for the scope of input and output entries of decision tables.
Reported: DMN 1.1 — Mon, 15 May 2017 17:59 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

How to get FEEL type if evaluation is not an option?

Key: DMN13-43
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
in chapter 10.3.2.10: "Sometimes we do not want to evalutate a FEEL expression e, we just want to know the type of e."

in table 54: column Applicability defines which row in the table to use, depending on the type of a FEEL expression.

Table 54 only makes sense if it is not allowed to pre-evaluate the expression e2, since even for a pre-evaluation context entries (for example: "item") must be declared in scope.

How do we know the type of a FEEL expression if it is not allowed to evaluate it?

Examples:
- [1,2,3][min(3,2,1)]
- {a:function() external {java: {class: "clazz", method signature: "method()"}}, b:[1,2,3][a()]}.b
- {a: 1, b: a instance of number, c: [1,2,3][b] }
Reported: DMN 1.1 — Wed, 3 May 2017 14:56 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Enhancement suggestion: make unary tests first class citizens of the FEEL language

Key: DMN13-18
Status: closed
Source: Red Hat Inc ( Edson Tirelli)
Summary:
This is a suggestion for future versions of the spec:

Add support for Unary Tests as first class citizens of the FEEL language, in a similar way as ranges and functions already are.

A unary test is really a “predicate”: a single parameter function that returns a boolean. It is syntax sugar on:

function ( x ) x in <unary_test>

FEEL already supports functions as first class citizens, so it makes sense to support Unary Tests. The following two syntaxes would then be equivalent:

is minor : < 18
is minor : function( age ) age in < 18

Invoking unary tests explicitly would be like invoking a function:

Bob is minor : is minor( bob.age )

More importantly, it would allow the implementation to actually support passing unary tests as parameters to functions and make the example on page 115 viable:

decision table (
outputs: "Applicant Risk Rating",
input expression list: [Applicant Age, Medical History],
rule list: [
[ >60, "good", "Medium" ],
[ >60, "bad", "High" ],
[ [25..60], -, "Medium" ],
[ <25, "good", "Low" ],
[ <25, "bad", "Medium" ]
],
hit policy: "Unique"
)

Unary test syntax is not ambiguous, so supporting it would mean to basically change rule 2 in the grammar to include rules 14 and 17 as possible options. The semantic mapping table on page 116 would also need to include a new FEEL value type: "unary test".
Reported: DMN 1.1 — Tue, 23 Aug 2016 01:41 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Enhancement suggestion: allow for expressions to be used as "end points"

Key: DMN13-17
Status: closed
Source: Red Hat Inc ( Edson Tirelli)
Summary:
This is a suggestion for future revisions of the specification:

Change the grammar to allow expressions to be used as "end points" on ranges and unary tests. E.g.:
{ Thanksgiving holiday: [ date(“2016-11-24”) .. date(“2016-11-27”) ] }
This is extremely useful for users that no longer have to create dummy variables in order to use expressions as "end points".
Reported: DMN 1.1 — Tue, 23 Aug 2016 01:32 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Include Test Cases in Decision Model

Key: DMN13-16
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
For interchange of test cases along with a decision model, it would be convenient to define metamodel and xsd elements for a suite of test cases, where a test case contains values for input data and expected values output decisions.
Reported: DMN 1.1 — Sat, 28 May 2016 16:25 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- testCases.xsd 3 kB (text/xml)

Change depiction of Input to be harmonized with BPMN and CMMN

Key: DMN13-15
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
As OMG promotes the integrated use of DMN with BPMN and CMMN, it is proposed to change the depiction of Input in DMN to be the paper Shape with folded corner. We can envision end users wanting to embed DMN diagrams into BPMN or CMMN diagrams. This change would provide better notational alignment with Data Object and Case File Iems in BPMN and CMMN. Futhermore is would remove the notation conflict currently existing between DMN Input and CMMN Milestone.
Reported: DMN 1.1 — Mon, 16 May 2016 14:26 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- BPMN Data Object DMN Data Input.PNG 86 kB ()
- CaseFileItem.png 0.9 kB (image/png)
- Depiction of Input Data conflict with BPMN and CMMN.png 239 kB (image/png)
- Milestone.png 2 kB (image/png)
- bpmn-figure-087.Data Object Reference.png 0.9 kB (image/png)
- bpmn-figure-088.Data Object Reference Collection.png 0.9 kB (image/png)
- bpmn-figure-089.Data Input.png 1 kB (image/png)
- bpmn-figure-090.Data Input Collection.png 1 kB (image/png)
- bpmn-figure-091.Data Output.png 1 kB (image/png)
- bpmn-figure-092.Data Output Collection.png 1 kB (image/png)

Lack of visual notation for processing of / iteration over lists in DRD

Key: DMN13-12
Status: closed
Source: Signavio GmbH ( Dr. Bastian Steinert)
Summary:
The processing of lists of data is fundamental to business decisions. Some kind of multiplicity should be indicated at the DRD level, and iteration should be supported visually at the decision logic level. In spite of the attached figures (meant to provoke discussion), the scope of this issue is limited to "flat" DRDs, that is, no "sub-DRDs" nested inside an outer decision or BKM. DRD proposal should specify what the multiplicity marker or other DRD notation looks like, and where it may appear, e.g. attached to head or tail of a requirement arrow, or inside a decision or BKM shape left of the name, etc.
Reported: DMN 1.1 — Wed, 4 May 2016 08:49 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- Cardinality.pdf 276 kB (application/pdf)
- FanProposal_JTJP.pdf 297 kB (application/pdf)
- MID.jpg 30 kB (image/jpeg)
- iteration.PNG 9 kB ()

XSD: global context

Key: DMN13-10
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
10.3.2.9.2 says "The global context is a context provided for convenience and 'pre-compilation'. Any number of expressions can be named and represented in a FEEL context m. The syntactic description m of this context can be evaluated once, that is, mapped to the FEEL domain as m, and then re-used to evaluate many expressions." For example, you might want to put a Relation used as a multi-dimensional constant in the global context. Or you might want to put a reusable function definition in the global context. Currently the xsd does not have globals. All expressions are bound to a specific drgElement, not global. The Import element probably needs to be modified to support this also.
Reported: DMN 1.0 — Sun, 31 May 2015 16:35 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

LiteralExpression and textual expression seem to mean the same thing, need to use the same term

Key: DMN13-9
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
literal expression is used in MM, and textual expression is used in grammar. Let's use 1 consistently, but check that they are really the same concept.
Reported: DMN 1.0 — Thu, 16 Jul 2015 16:30 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Business Knowledge Model can have Information Requirements

Key: DMN13-8
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
FEEL function definitions are defined as lexical closures, which simply means that names in the function body must be in scope, and that scope includes the function parameters and, just like any other decision logic, it includes the information requirements and the knowledge requirements. This is very handy. For example, it allows the logic of a BKM to reference 100 Input Data items by name, without requiring that each invocation pass in 100 parameter bindings.

In order for this to work, the BKM would model 100 Information Requirements on the 100 Input Data items, instead of modeling them as parameters. The boxed invocations would not have 100 rows of repetitive binding information. We must extend the MM and Table 2 to allow a BKM to have information requirements.
Reported: DMN 1.0 — Thu, 23 Jul 2015 23:30 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Can the same Definitions/namespace be used by more than one model?

Key: DMN13-28
Status: closed Implementation work Blocked
Source: Red Hat ( Edson Tirelli)
Summary:
Please clarify if it is possible to have multiple models on the same namespace. For instance:

<definitions namespace="http://my.company/financeModels" name="Model A" ...

<definitions namespace="http://my.company/financeModels" name="Model B" ...

The current text of the specification does not say anything explicitly one way or another, so please clarify that.

In addition to this, if multiple models can use the same namespace, then the <import> element will require an additional attribute (for instance: modelName) in order to uniquely identify which model should be imported.
Reported: DMN 1.1 — Thu, 8 Mar 2018 16:20 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Add two new concrete numeric types, make number abstract

Key: DMN13-31
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Currently S-FEEL / FEEL contains only one single numeric type called number that matches the semantics defined in IEEE 754-2008.

This can lead to some strange constructions, such as
substring("footbar", 3.67)
perfect valid in FEEL.

It also has impact on the performance of the execution (speed).

Here is my proposal:
- keep number as an abstract type to backwards compatibility
- add a new concrete type real/float/decimal that matches the semantics of defined in IEEE 754-2008
- add a new concrete type integer
- change the signature of all built-in functions to restrict number to integer when it makes sense (e.g. index in a string and list, length of string. size of list)
- add a separate paragraph to specify the implicit conversions performed by the FEEL processor when required (e.g. function resolution). For example,
  2 + 4.5 leads to a promotion 2 -> 2.0 that adding it 4.5.
If we agree in principal all start working on it.
Reported: DMN 1.1 — Wed, 6 Dec 2017 13:44 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Formally define enumerations and use throughout

Key: DMN13-33
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
Item Definitions can share constraints and these constraints are specified as unary tests. This allows definitions such as requiring a positive number ( >0) or restricting a field to a specific value ("high", "medium", "low").

However this requires enumerations to be strings and does not allow enumerations to be managed (sorted for instance). In addition, an enumerated list might be used for a set of Information Items but it must be repeated in Decision Tables when columns are meant to be restricted to the list of values.

DMN should allow for the creation and management of enumerations:
- Name
- Description (optional)
- List of enumerated values (optionally with a sort order)
These enumerations should be considered symbolic constants, not strings

FEEL functions should be created to:
Get the list of of allowed values for a specified enumeration
Check a value against an enumeration to see if it is an allowed value for that enumeration
Check the sort order of some specified values in the context of an enumeration

Decision Tables should be able to reference an enumeration by name in the value list row
Information Items should be able to be linked to an enumeration
Reported: DMN 1.1 — Thu, 26 Oct 2017 16:12 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions

Key: DMN13-20
Status: closed
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
In Figure 6.15 the multiplicity of output decisions for a decision service is shown as zero to many (0..), but the text below and Table 16 says the that multiplicity is one to many (1..). The figure should be correct to match the text and table.
Reported: DMN 1.1 — Fri, 3 Aug 2018 21:19 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Should encapsulated decisions of a decision service include output decisions?

Key: DMN13-22
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Figure 10 on page 25 with text "The encapsulated decisions are therefore
{Decision 1, Decision 2}
"

Figure 11 on page 26 with text "The encapsulated decisions for this services are
{Decision 1}
".

Table 20 on page 56:
- "outputDecisions: This attribute lists the instances of Decision required to be output by this DecisionService".
- "encapsulatedDecisions: If present, this attribute lists the instances of Decision to be encapsulated in this DecisionService".
For us it is unclear what decisions should be stored in the DMN model as encapsulated decisions. Must the output decisions also be included in the list of encapsulated decisions (as stated on page 25, 26)? Or does the list of encapsulated decisions only hold the decisions contained in the lower compartment of a decision service (as mentioned on 56 since encapsulatedDecisions seems to be optional)?
Reported: DMN 1.0 — Tue, 20 Mar 2018 14:49 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Wrong character in expression for PMT function definition

Key: DMN13-30
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
The expression of the PMT function contains an invalid character and is therefore not executable. The first minus character is a dash, but shouldn't.

(amount rate/12) / (1 – (1 + rate/12)*-term)

Fixed:

(amount rate/12) / (1 - (1 + rate/12)*-term)
Reported: DMN 1.1 — Fri, 2 Feb 2018 10:32 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Requested additional built-in functions

Key: DMN13-55
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(from Bruce)
a. String-join(stringList, separatorString)

b. Format-number(value, formatString), where formatString (to be negotiated) generally follows Excel or xpath, maybe not all the features.

c. Format-date(value, formatString), format-dateTime(value, formatString)
Reported: DMN 1.1 — Mon, 2 Jan 2017 20:43 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Collect decision tables

Key: DMN13-69
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
(1) The spec says "Collect: returns all hits in arbitrary order. An operator (‘+’, ‘<’, ‘>’, ‘#’) can be added to apply a simple function to the outputs. If no operator is present, the result is the list of all the output entries.". This is confusing - as I understand it if an operator is present a collect hit policy does not return all hits, only the result of the operation.

(2) The spec should state clearly what result is returned by Collect decision tables when no rules fire. In particular the result of a C+ decision table is not clear, because the result of sum([]) is undefined. I think a case could be made (based on a recursive definition) that the sum of an empty list is zero, which would be a much more useful result from the decision table than null. In general, section 10.3.4.4 restricts the semantics of all list functions to non-empty lists, although some functions have natural and useful results for the empty list e.g. count([])=0, sum([])=0, sublist([],x,y)=[], append([],items)=[items], concatenate([],items)=items, reverse([])=[], union([],items)=[], distinct values([])=[], flatten([])=[].

(3) Why is the result of C+ defined as "sum of all the distinct outputs" rather than just "sum of all the outputs"? I would say that if three rules fire proposing the value 5, the C+ result should be 15, not 5.
Reported: DMN 1.1 — Thu, 13 Oct 2016 08:25 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

FEEL ambiguity

Key: DMN13-68
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
FEEL grammar is ambiguous. Rule 2.i is ambiguous for identifiers like Person, as it can lead to two parse trees, one with QualifiedName the other with Name in it. See rule for simple value.

Rule 1 is ambiguous as there is an overlap between textual expression and boxed expression. I suggest breaking the grammar in several grammars with a common part. This ambiguity will just go away as soon as we do that.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:41 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement

Key: DMN13-71
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement
Reported: DMN 1.1 — Wed, 24 Aug 2016 16:45 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

need set operations and equality in FEEL

Key: DMN13-73
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
some notes toward a proper description:
FEEL has ordered lists and some set builtins, e.g. distinct values and union. Lacks intersection and equality.

[1,2] in (1,2,[1,2], 3) is true

intersect([1,2,3], [3,1,4]) = [1,3]

set equals([1,1,3], [3,1]) is true
probably - distinct values([1,1,3]) = distinct values([3,1])
maybe change to set([1,1,3]) = set([3,1])
(set needs to both remove dups and return elements in canonical order)
what is canonical order [null, 0, {}, []]?
[1,3] = [3,1] is false

Another option is to add sets to FEEL semantic domain (along with lists, numbers, contexts, ...). And need syntax.

simpler and more biz friendly proposal - add 'contains any' and 'contains all' as boolean infix operators taking 2 lists as LHS and RHS. And allow these to be added to unary tests w/o a '?'. E.g. 1,2,3 , in (1,2,3) , contains any (1,2,3), contains all (1,2,3). First 2 are what we have now (2nd allowed for symmetry). Last 2 assume input expr is a list (set).

if we just add set oriented builtins, but no friendlier syntax, this may not solve the biz problem of allowing DTs to process sets in a user friendly way. Too many ()s and ?s
Reported: DMN 1.1 — Thu, 11 Aug 2016 15:35 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

notion of arbitrary order conflicts with lack of an unordered collection data type

Key: DMN13-76
Status: closed
Source: Signavio GmbH ( Dr. Bastian Steinert)
Summary:
Section "8.2.11 Hit policy" describes that hit policy "Collect: returns all hits in arbitrary order". This implies that the order of the results does not have to be deterministic and can also vary among different implementations. However, the standard only supports the notion of 'lists', which do have an order. The comparison of lists is also specified in a way that the order of elements is significant. The issue might get more clear when thinking about testing the interface of decisions. Strictly speaking, it is currently not feasible to define a test against a decision table with hit policy 'collect'. The expected result can only be defined using a list, whose elements do have an order. The operator to compare the 'expected' and the 'actual' result will also take order into account.

The issue could easily be resolved by replacing 'arbitrary order' with 'rule order'.
Reported: DMN 1.1 — Sun, 26 Jun 2016 10:11 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Unspecified conclusion

Key: DMN13-78
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
I remember discussions about allowing "-" in conclusions to mark an unspecified conclusion in a decision table. This would allow some of the conclusions in a multiple output decision table to be marked as "unspecified" where there was no output relevant for that conclusion for a specific rule and to allow rules in multi-hit tables to show that a particular combination of conditions had been considered but did not result in anything being added to the result set.
However the standard as written says that an output entry must adhere to the literal expression grammar, and '-' is not allowed. You have to return some FEEL value, e.g. 0, false, "N/A", null, etc.
Reported: DMN 1.1 — Mon, 13 Jun 2016 21:41 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

We need a way to identify current date and time. I propose Now()

Key: DMN13-79
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
We need to be able to compare to the current date and time
e.g.
Now() as a unitary test
or
Now() = a specified date and time
Reported: DMN 1.1 — Thu, 2 Jun 2016 15:54 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Fix interchange of links to objects in BPMN/BMM

Key: DMN13-91
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
The current spec uses objects from BMM and BPMN. However it is not at all clear how links to these objects, and the objects at the end of the links, should be interchanged. Does the DMN file contain a snippet of BPMN? Should a separate BPMN file be generated and then referenced? If we are going to have these links then we need to show/explain how to interchange them both with tools that only support DMN (and so only have a few BPMN or BMM objects) and with those that support DMN/BPMN/BMM.
Reported: DMN 1.2 — Thu, 27 Sep 2018 01:07 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Allow representation of black-box Decision Service

Key: DMN13-90
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
As DMN gets used to produce publicly available decision services we will need some way to represent a decision service that the modeler cannot see into. They know its a side-effect free, stateless decision service and know its signature so they can add a decision to their own model that is implemented by it but they don't know what decisions, BKMs, knowledge sources etc were used to produce it. There is currently no way to do this - a decision service can be shown collapsed but only if the model "knows" what the expanded version looks like. It feels like it would be useful to do so.
Reported: DMN 1.2 — Thu, 27 Sep 2018 01:04 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Can an expression in user defined function body reference a name outside of it's scope?

Key: DMN13-44
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
If an expression in a user defined function body references a name outside of it's scope (for example a parent scope), this scope must be available also during invocation of the function.

Examples:
- {f:function() a, a:1, i:f()}
  possible, since name a is still available in local context (scope) during invocation
- {b:1,f:function() b}
  .f() impossible, since name b is not available outside of the context.
It would be nice if the semantic mapping and the differentiation between function definition and invocation is clearly specified in the spec. What names can be referenced? Must the scopes also be available during invocation?
Reported: DMN 1.1 — Wed, 3 May 2017 15:24 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Should name declarations in same context fail or overwrite?

Key: DMN13-46
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
As I see the spec doesn't define what should happen if in a context a name should be declared that already exists in the current context. Sample FEEL expression: "for i in [1,2,3], i in [4,5,6] return i * i" Does the second definition of i overwrite the first one or should we return null for the complete "for" expression?
Reported: DMN 1.1 — Wed, 3 May 2017 09:25 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test

Key: DMN13-47
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
For simple positive unary test(s) there are extra entry points in the FEEL grammar. Therefore why do we need simple positive unary test in grammar rule 2.i. What is the semantic mapping?
Reported: DMN 1.1 — Wed, 3 May 2017 09:11 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122

Key: DMN13-48
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
on page 122 in table 43 in row 2 and 3: "e1 in [e2, e3, ...]"
on page 109 grammar rule 51.c: expression "in" positive unary test
on page 109 grammar rule 51.c: expression "in" "(" positive unary tests ")"

The syntax with square brackets is not allowed by the grammar rules 51.c. Either table 43 or grammar definition should be changed.
Reported: DMN 1.1 — Wed, 3 May 2017 08:58 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Improvement of Semantic Domains Specification

Key: DMN13-50
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The definition of Semantic Domains / Types in 10.3.2 does not contain:
- a metamodel
- relationships between various types
I propose adding a metamodel and the following two relationship:

1. Conforms To
A semantic domain T1 conforms to a semantic domain T2 when an instance of T1 can be substituted at each place where an instance of T2 is expected.

2. Equivalent To
A semantic domain T1 is equivalent to a domain T2 iff they have the same name and the corresponding embedded semantic domains are equivalent. (e.g. List<Number> is equivalent only to List<Number> not List <String>).

The above relationships should be defined via tables, similar to the ones used to describe the semantics of logic operators (page 119 Table 38).
Reported: DMN 1.1 — Thu, 30 Mar 2017 12:38 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT
Attachments:
- argo-dmn-types.png 15 kB (image/png)

Semantic domain mapping for simple expressions

Key: DMN13-52
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The FEEL grammar contains simple expressions as starting terminal

page 107 6. simple expressions = simple expression ,
{ "," , simple expression }
;

I could not find a mapping to a semantics domain for it. What is the type / domain of "simple expressions"? A list with element type Any or a Tuple Type with several element types?
Reported: DMN 1.1 — Fri, 17 Mar 2017 14:42 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Metamodel constraints & validation

Key: DMN13-65
Status: closed
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
None of the metamodels contain logic constraints. For example, the name of a decision table is the same with the name of the variable defined inside of the decision table tag (invariant at decision table level).

Ideally these constrains would be used to validate the diagrams before execution (e.g. generating code from Java). Bruce Silver's already covers some of the. We should add them and more in the spec.

I think the metamodel constraints should be described with OCL – see the UML metamodels. There should be constraints for CL1, CL2 and CL3. It’s very likely the CL3 constraints will be a superset of CL2 constraints.
Reported: DMN 1.1 — Sun, 30 Oct 2016 11:45 GMT
Disposition: Deferred — DMN 1.3
Disposition Summary:
RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT

Generalized Unary Tests

Key: DMN12-29
Status: closed
Source: Sapiens Decision NA ( Mr. Gil Ronen)
Summary:
Modeling with collections of items is fundamental to much business processing (as was noted in various LinkedIn threads). Simple comparisons such as ‘does A,B contain A’ should be done in decision tables using dedicated operators and not require exiting to FEEL and structures external to the decision tables. Several tools already support these operators. While you can write these expressions in FEEL it is useful that a table segregates each row as a rule so that one row matches "list contains both a and b", the next row matches "list contains c, d, and e", etc. We find these representations of the logic to be both common and easily understood by business folks. The proposal is to add ‘Is In’, ‘Contains’ and ‘Contains Any’ operators and their negation (symbols can be used instead of the full operator textual name).

Attached images show this feature used in a business setting.

Examples below of how these operators work (1st element is the Input Expression result and the 2nd is an Input Entry):
{A,B} Contains A returns True {A,B,C} Contains {A,B}
returns True
{A,B,C} Contains {A,D} returns False
{A,B} Contains Any A returns True{A,B,C}
Contains Any
{A,D}
returns True
{A,B} Contains Any C returns False

A Is In {A,B}
returns True
{A,B} Is In {A,B,C} returns True{A,B}
Is In
{A,C}
returns False
Reported: DMN 1.1 — Thu, 5 May 2016 14:28 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Expanding the definition of unary test to allow boolean literal expressions

Change section 10.3.1.2 Grammar Rules (for FEEL) as follows:
Add a grammar rule 17d, a 'generalized unary test' as a 4th option for 'unary tests'.
Define 'generalized unary test' in a new grammar rule: generalized unary test = literal expression
In the Semantics section (probably in 10.3.2.8) add:
The name '?' refers to the value of the corresponding input expression, and add another grammar rule (not a syntactic one) that restricts the generalized unary test to a Boolean result:

grammar rule 17.d: FEEL(t')=true, where t' is t with every occurrence of the symbol ? in t substituted with e.

Will require some occurrences of 'unarytests' and 'unary tests' in the spec to be changed to 'generalized unary tests'. Will need examples showing 'generalized unary test' in decision tables, probably in the decision table chapter.

Examples:
1. The Input Expression Order.Total that evaluates to 5, combined with the Input Entry “>0” will result in the evaluation of “5>0” and a “true” result.

2. The Input Expression Order.Total that evaluates to 5, combined with the Input Entry “?>0” will result in the evaluation of “5>0” and a “true” result.

3. The Input Expression 'List of Codes' that evaluates to [“red”, “blue”], combined with the Input Entry “list contains (?,”green”)” will evaluate as “list contains ([“red”, “blue”],”green”) resulting in “false”.

4. The Input Expression Tax.Threshold that evaluates to 100000 combined with the Input Entry “?>gross pay*0.7” will result in the evaluation of “100000>gross pay*0.7” where gross pay is another Information Requirement.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- Contains Any with Info Req.png 23 kB (image/png)
- Contains Any.png 48 kB (image/png)
- DMN12-71_proposal_v3.docx 19 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Is Not In.PNG 152 kB ()
- Set operations in FEEL.docx 32 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

semantics of import is unspecified

Key: DMN12-188
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
for example, if 'lib' is the name of an imported model, and Input1 is an input data in that model, then one can refer to the input in FEEL using lib.Input1, but this is not specified in 10.4
Reported: DMN 1.1 — Thu, 14 Sep 2017 15:18 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
improve specification of import and qualified names

see attached word doc
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- import-semantics (2).docx 17 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Execution Semantics of Decision Services does not explain imported elements

Key: DMN12-131
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The semantics in 10.4 provides a mapping from a decision service to a function definition (which already has execution semantics defined earlier in Ch 10). The mapping does not explicitly consider imported elements. E.g. we could map an imported definition named 're-use this' to a nested context with the same name in the top context.
Reported: DMN 1.1 — Thu, 2 Feb 2017 15:54 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
resolved as ~~DMN12-188~~

duplicate issue
Updated: Wed, 3 Oct 2018 14:17 GMT

Confusing semantics of ItemDefinitons

Key: DMN12-216
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
According to the ItemDefinition specification, an ItemDefinition can be defined in two ways:
- reference to a built-in or imported typeRef
- composition of ItemDefinition via itemComponents
According to the metamodel in Figure 7.6 and Table 23 typeRef is optional and itemComponent has [0..*] cardinality.

That means an ItemDefinition can be defined as

<itemDefinition id="1234" name="name"/>

What is the actual semantics of this type? Is it some sort of a root type in a type system?

To make the semantics more readable and fix some some typos or missing info, I suggest the following:
1. Add missing cardinality for ItemDefintion.itemComponent in Figure 7.6. (missing info)
2. In Table 23 change cardinality of typeRef to be [0..1] to match the metamodel (typo).
3. Add an extra constraint in Table 23 itemComponent row:
When typeRef is missing, itemComponent has at least one ItemDefinition.
Reported: DMN 1.1 — Wed, 6 Dec 2017 13:13 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Improve type checking semantics

see attached word doc v8
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-216_proposal_v8.docx 112 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- feel lattice.jpg 77 kB (image/jpeg)

Formatting problems in Ballot 15 convenience doc

Key: DMN12-250
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Number for section 10.5 is missing, and title 'Metamodel' is small font

(additional issues, if any, can be added here)
Reported: DMN 1.1 — Tue, 20 Mar 2018 16:53 GMT
Disposition: Closed; No Change — DMN 1.2
Disposition Summary:
not an issue in the official spec

this is a tracking issue about producing a convenience document.
Updated: Wed, 3 Oct 2018 14:17 GMT

Missing type names in FEEL functions (user and external)

Key: DMN12-183
Status: closed Implementation work Blocked
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Currently there are three kind of functions in DMN / FEEL:
- builtin functions (see page 130), strongly typed with optional parameters and var args, with static typing.
- DMN functions defined in the metamodel (see functionDefinition element in xsd schema), strongly typed, with static binding
- FEEL functions defined in FEEL (see grammar rule 57), weakly typed with dynamic typing.
Mixing both static typing and dynamic typing in the same language is not a great idea from the execution point of view.

I am not a fan of dynamic typing mainly because it pushes semantic rules in the dynamic semantics and diminishes the quality of software products (e.g. increases maintenance costs) .

Imagine for example a context that contains an entry x with
function(a, b) a + b
and another one calling
x(1, 2)
The semantic analyzer cannot type check and infer the return type of the definition, it has to wait until the function is invoked. The type of x is partial (unknown parameter types and return types) for the rest of execution.

On top of that the function can be used both for numbers and strings. If the intended behavior changes over time for one use case the user has to write another function anyway.

It gets even harder to handle type checking for external functions.

I suggest adding an a parameter type in rule 58

formal parameter = parameter name ":" type name

where type name is a FEEL type or a complex type (defined via a typeRef)
Reported: DMN 1.1 — Fri, 25 Aug 2017 09:12 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
part of improved types/itemdefinitions

~~DMN12-216~~ adds optional types to FEEL functions
Updated: Wed, 3 Oct 2018 14:17 GMT

Support for function calls in unary tests

Key: DMN12-119
Status: closed Implementation work Blocked
Source: Goldman Sachs ( Octavian Patrascoiu)
Summary:
Endpoints in SFEEL grammar are

endpoint = simple value ;
simple value = qualified name | simple literal ;

Adding an extra alternative to support function calls will be useful, especially for tests on strings and lists.

A Prolog-like notation can be used to specify the position of the input entry. For example,
contains(?, "abc")
Reported: DMN 1.1 — Wed, 23 Nov 2016 10:43 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
covered by generalized unary tests

the boolean expression containing '?' can invoke functions
Updated: Wed, 3 Oct 2018 14:17 GMT

Missing RuleAnnotation attributes and model associations table

Key: DMN12-280
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Section 8.3.3 Decision rule metamodel do not list the attribute in a table for RuleAnnotation as it is usually done.
Reported: DMN 1.1 — Mon, 23 Apr 2018 17:51 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Add table RuleAnnotation attributes and model associations

Add the following table to section 8.3.3
Updated: Wed, 3 Oct 2018 14:17 GMT

Limitations of FEEL for..in..return

Key: DMN12-223
Status: closed
Source: Red Hat ( Edson Tirelli)
Summary:
Iteration is supported in DMN1.1 using the for..in..return operator, such as

for j in myList return myFunction(j,…)

But this only handles the case where each iteration of myFunction depends only on the value of j, the nth item in myList. It excludes cases where the iteration depends on:

1. The n-1st item in the list, or
2. The nth item of another list, or
3. The result of the n-1st iteration

These are all very common iteration use cases.
Reported: DMN 1.1 — Thu, 4 Jan 2018 14:46 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
add iteration context and 'partial' keyword to for..in..return

Proposal

The solution requires two simple enhancements to the for..in..return operator.

1. Loop on index. Following “in”, instead of the list variable myList use the range syntax a..b, where expressions a and b are integers, for example:

for n in 1..N return myFunction(n, myList,…)

Most often N will be the count of myList and n an index into myList:

for n in 1..count(myList) return myFunction(myList[n],…)

2. Include partial results in the iteration. Much like the built-in variable item is defined for filter expressions, we introduce a new built-in variable partial for iteration, a list variable holding the results of previous iterations, for example:

for n in 1..N return myFunction(n, myList, partial, …)

Typically this would be used in an expression like

for n in 1..count(myList) return myFunction(myList[n], partial, …)

These two small changes allow for..in..return to handle all 3 iteration use cases.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-223_proposal_v3.docx 83 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

add richer variety of DT examples in Ch 11

Key: DMN12-18
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
We lack examples of input expressions that are not simple names, input entries that reference variables, and output entries that are more than simple values.
For example, could change fig 67, Eligibility column, from Eligibility||INELIGIBLE|ELIGIBLE to Eligibility=ELIGIBLE||false|true
In Fig 71, add a context entry with name 'Adult' and value '18'. Change the entry <18 to <Adult.
In Fig 83, rename to Adjusted Disposable Income. Add parameter list (Risk Category, Disposable Income). Change output entries to 0.6 * Disposable Income, 0.7 * Disposable Income, 0.8 * Disposable Income, change invocation entry in Fig 82 name to Adjusted Disposable Income and pass Disposable Income. Change Affordability calculation to 'if Adjusted Disposable Income > Required Monthly Installment'
Reported: DMN 1.0 — Tue, 7 Jul 2015 21:19 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
add more examples

more suggested examples
Updated: Wed, 3 Oct 2018 14:17 GMT

Typo in sublist() function example

Key: DMN12-79
Status: closed
Source: Red Hat Inc ( Edson Tirelli)
Summary:
There is a typo in the sublist() function example on page 134. It states:

sublist([1,2,3], 1, 2) = [2]

But the correct would be:

sublist([1,2,3], 1, 2) = [1, 2]
Reported: DMN 1.1 — Tue, 23 Aug 2016 01:28 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
issue subsumed by ~~DMN12-74~~

issue subsumed by ~~DMN12-74~~
Updated: Wed, 3 Oct 2018 14:17 GMT

FEEL + operator semantics operand-dependent

Key: DMN12-41
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(from Bruce)
It means addition for most operand types but concatenation for strings. This is another implementation barrier because the mapping from FEEL to another language requires evaluation of operands to determine their datatype. Making + addition only and adding a string concat function would simplify implementation.
Reported: DMN 1.1 — Sat, 14 May 2016 23:30 GMT
Disposition: Closed; Out Of Scope — DMN 1.2
Disposition Summary:
changes to FEEL (even small ones) would not be backward compatible

out of scope for RTF to change meaning of "foo" + "bar"
Updated: Wed, 3 Oct 2018 14:17 GMT

Spaces in FEEL builtin functions

Key: DMN12-40
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(from Bruce)
one barrier to FEEL implementation is parsing when both variables and built in function names contain spaces. Modelers and tools can elect not to use spaces in variable names but the functions are defined in the spec. Eliminating spaces in builtin function names would simplify parsing. E.g., distinct-values() instead of distinct values(). Xpath does it this way.
Reported: DMN 1.1 — Sat, 14 May 2016 23:29 GMT
Disposition: Closed; Out Of Scope — DMN 1.2
Disposition Summary:
changing names of built-ins is not backward compatible

Changing names would not be backward compatible and hence is out of scope for an RTF; and there should be a higher bar to standardize multiple names for the same builtin.
Updated: Wed, 3 Oct 2018 14:17 GMT

Chapter 11 example serialization has many errors

Key: DMN12-70
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Bruce reports there are many errors in this document:
http://www.omg.org/spec/DMN/20151101/ch11example.xml
Reported: DMN 1.1 — Wed, 20 Jul 2016 00:29 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
new example xml file is part of ~~DMN12-229~~

Close this as duplicate.
Updated: Wed, 3 Oct 2018 14:17 GMT

Supporting text about Expression lists non-existing name attribute

Key: DMN12-155
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
On page 64 (PDF 68) the supporting text says:

Expression is an abstract specialization of DMNElement, from which it inherits the name, and optional id, description, and label attributes.

However, DMNElement does not have a name attribute.
Reported: DMN 1.1 — Fri, 31 Mar 2017 08:48 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Remove name from attribute list of Expression

See revised text.
Updated: Wed, 3 Oct 2018 14:17 GMT

Inconsistencies between metamodel and xsd schema

Key: DMN12-143
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
The DMN metamodel doesn't seem to match the XSD schema:

Page 37. DMNElement.extensionAttribute[0..*] in metamodel vs otherAttributes in XSD

Page 39: Definitions.collection[0..*] in metamodel vs elementCollection in XSD

Definitions.decisionService[0..*] in metamodel, missing in xsd.

Page 64: ItemDefinition.itemComponents[0..] in metamodel ItemDefinition.itemComponent[0..] in XSD (extra s in metamodel)
Reported: DMN 1.1 — Tue, 14 Mar 2017 10:28 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Align names in MM with XSD for Definitions/@elementCollection and ItemDefinition/@itemComponent

In MM:
- rename 'collections' to 'elementCollection' in Figure 19: "Definitions Class Diagram"
- rename 'itemComponents' to 'itemComponent' in Figure 31: "Expression class diagram".
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-151-Definitions.PNG 65 kB ()
- DMN12-151-Expressions.PNG 69 kB ()

Expected behavior for list/sort built-in functions in combination with singleton lists

Key: DMN12-210
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
The DMN specification says about singleton lists:
- Chapter 10.3.1.4 on page 110: "A singleton list is equal to its single item, i.e., [e] = e for all FEEL expressions e."
- Chapter 10.3.2.5 on page 113: “Therefore, any function or operator that expects a list as input but instead receives a non-list semantic domain element e behaves as if it had received [e] as input.”
This works for most expressions and built-in functions, but for list built-in functions and the sort built-in function the behavior is ambiguous. This leads to different possible valid results for a FEEL expression. The problem here is that the further processing of this result (in DMN and/or other FEEL expressions) leads to different behavior/results of subsequent (boxed) expressions.

Examples of ambiguous FEEL expressions:
- distinct values(["a", ["a"]])
  - possible results: ["a"] or [["a"]] or ["a", ["a"]]
- union(["a"], [["a"]])
  - possible results: ["a"] or ["a", ["a"]]
- index of(["a", ["a"]], "a")
  - possible results: [1,2] or [1]
- count([[]])
  - possible results: 0 or 1
- list contains(["a", ["b"]], "b")
  - possible results: true or false
- min([1],2)
  - possible results: [1] or 1
- flatten([“a”, [], [[]]])
  - possible results: [“a”] or [“a”, []]
Therefore we think, the specification must be detailed to ensure cross vendor interoperability.

Our proposal for DMN 1.2 is not a change of the existing behavior, but a more detailed description of the expected behavior:

Add the following 5 bullet points to chapter 10.3.4.4 List functions before table 61:
- List built-in functions work on the passed lists as they are. A single element may be converted to a singleton list where the parameter domain requires this. (For example count(), list con-tains(), index of()).
- If a built-in function returns a list, any list item originating from the parameters are pre-served, i.e. singleton lists remain (for example reverse(), sort(), min()).
- To operate on list items, singleton lists may be resolved to their single item (for example min(), and(), mean()).
- If a list built-in function identifies list items, FEEL equality is used (for example index of(), list contains()).
- If FEEL equality matches two or more list elements and the built-in function has to decide which equal element should be returned, the function MUST return the element with the lowest position. (For example distinct values())
Additionally the description of the flatten() built-in function should be changed to:

“flatten nested lists and removes empty and nested empty lists”

Additionally it may be helpful to categorize the list built-in functions to the following categories:
- Functions searching for list items:
  list contains(), index of()
- Functions creating a new list with additional or removed items:
  sublist(), append(), concatenate(), insert before(), remove()
- Functions changing the list order of items:
  reverse(), sort()
- Functions operating on list items and calculating a result:
  count(), min(), max(), sum(), mean(), and(), or()
- Set theory functions:
  distinct values(), flatten(), union()
We could add a new column “category” to table 61 or divide table 61 into more tables.

Examples for the above FEEL expressions with the new applied specification changes:
- distinct values(["a", ["a"]]) = [“a”]
- union(["a"], [["a"]]) = [“a”]
- index of(["a", ["a"]], "a") = [1, 2]
- count([[]]) = 1
- list contains(["a", ["b"]], "b") = true
- min([1],2) = [1]
- flatten([“a”, [], [[]]]) = [“a”]
Even more examples

list contains([], []) = false // processes passed list as is. This list is empty and cannot contain items.
list contains([[]], []) = true // note: different result as for []
list contains("a", "a") = true // automatic conversion from first parameter "a" to ["a"]
list contains(["a"], "a") = true
list contains([["a"]], "a") = true // FEEL equality is applied where [e] = e
list contains(["a", "b", []], []) = true
list contains(["a", "b", [[]]], []) = true

index of([], []) = [] // processes passed list as is. This list is empty and cannot contain items.
index of([[]], []) = [1] // note: different result as for []
index of("a", "a") = [1] // automatic conversion from first parameter "a" to ["a"]
index of(["a"], "a") = [1]
index of([["a"]], "a") = [1] // FEEL equality is applied where [e] = e
index of(["a", "b", []], []) = [3]
index of (["a", "b", [[]]], []) = [3]

sublist([],1,1) = null // invalid position
sublist([[]],1,1) = [[]]
sublist("a", 1, 1) = ["a"] // automatic conversion from first parameter "a" to ["a"]
sublist(["a"], 1, 1) = ["a"]
sublist([["a"]], 1, 1) = [["a"]]
sublist(["a", "b", []], 3, 1) = [[]]

append([], 1) = [1]
append([[]], 1) = [[], 1]
append("a", 1) = ["a", 1] // automatic conversion from first parameter "a" to ["a"]
append(["a"], 1) = ["a", 1]
append([["a"]], 1) = [["a"], 1]

concatenate([], []) = []
concatenate([[]], []) = [[]]
concatenate("a", []) = ["a"] // automatic conversion from first parameter "a" to ["a"]
concatenate(["a"], []) = ["a"]
concatenate([["a"]], []) = [["a"]]

insert before([], 1, "a") = null // invalid position
insert before([[]], 1, "a") = ["a", []]
insert before("a", 1, "b") = ["b", "a"] // automatic conversion from first parameter "a" to ["a"]
insert before(["a"], 1, "b") = ["b", "a"]
insert before([["a"]], 1, "b") = ["b", ["a"]]

remove([], 1) = null // invalid position
remove([[]], 1) = []
remove("a", 1) = [] // automatic conversion from first parameter "a" to ["a"]
remove(["a"], 1) = []
remove([["a"]], 1) = []

sort([[[]], [], ["a"], [["a"]]], function (x,y) count(x) > count(y) ) = [[[]], ["a"], [["a"]], []]

reverse([]) = []
reverse([[]]) = [[]]
reverse("a") = ["a"] // automatic conversion from first parameter "a" to ["a"]
reverse(["a"]) = ["a"]
reverse([["a"]]) = [["a"]]

min([1], [2]) = [1] // return list item
max([1], [2]) = [2] // return list item

// mean(), sum(), and(), or() do arithmetic operations and therefore do never return a list

count([]) = 0
count([[]]) = 1 // note: different result as for []
count("a") = 1 // automatic conversion from first parameter "a" to ["a"]
count(["a"]) = 1
count([["a"]]) = 1

distinct values([[[]], [], "a", ["a"], [["a"]]]) = [[[]], "a"] // uses FEEL equality, preserves items, chooses for equal list items item with lower list position

flatten([[[]], [], "a", ["a"], [["a"]]]) = ["a", "a", "a"] // removes empty lists

union([[], [[]], "a", ["a"], [["a"]]], [[["a"]], ["a"], "a", [[]], []]) = [[], "a"]
// uses distinct values(concatenate())
Reported: DMN 1.1 — Thu, 19 Oct 2017 14:27 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Replace e=[e] with implicit de-listing to avoid argument domain error

See attached word doc
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-210_proposal_v2.docx 17 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Typo error on Business Knowledge Model

Key: DMN12-9
Legacy Issue Number: 19843
Status: closed
Source: Anonymous
Summary:
Here is a slight one (typo error) table 6.1, first row: an « e » is missing into « Knowledge ».

N.B. It is more elegant to not cut a table on several pages, as it was done before, but it is another matter.
Reported: DMN 1.0 — Sun, 1 Nov 2015 04:00 GMT
Disposition: Closed; No Change — DMN 1.2
Disposition Summary:
Unable to find the issue

I do not see a table 6.1 in the spec, nor do I find a 'Knowledge' with missing 'e'.
Updated: Wed, 3 Oct 2018 14:17 GMT

Missing attribute isExpanded for DecisionService DI

Key: DMN12-248
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
There is three ways to depict a decision service in DMN 1.2:
Expanded with the divider line
Expanded without the divider line.
Collapsed with the plus maker

However, in the lastest version of the specification (from Ballot 15) in the Decision Service section only 2 depictions are shown: the expanded one, with and without divider line.

To have the last one, we need to add an isExpanded attribute to DMNShape.
Reported: DMN 1.1 — Fri, 16 Mar 2018 18:56 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Add isCollapsed attribute to DMNShape

See revised text.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- class__DMN_Shape.png 22 kB (image/png)
- class__DMN_Shape.svg 156 kB (image/svg+xml)
- collapsedDecisionService.png 2 kB (image/png)

Chapter 11 example in specification does not match file ch11example.xml and ch11example.xml contains errors

Key: DMN12-229
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
The figures in chapter 11 does not match the ch11example.xml file. There are missing requirements, typos and undefined functions.

In order to be able to execute the ch11example.xml file the following erors must be fixed:
- Missing information requirement from "Applicant data" to "Application risk score"
- Missing information requirement from "Applicant data" to "Post-bureau affordability"
- "Bureau call type" decision should have an information requirement from "Pre-bureau risk category" decision and knowledge requirement from
  "Pre-bureau risk category table" should be removed.
- Missing information requirement from "Application risk score" to "Post-bureau risk category"
- Missing information requirement from "Post-bureau risk category" to "Post-bureau affordability"
- Missing information requirement from "Required monthly installment" to "Post-bureau affordability"
- Typo in BKM "Application risk score model": Parameter name should be "Marital Status" (with space)
- Inside "Pre-bureau risk category table" rule 2 and 3 contains wrong expressions for input clause "Application Risk Score". It should be ".." instead of "-" inside ranges
- For the "Bureau call type" decision "Pre-Bureau Risk Category" should be renamed as "Pre-bureau risk category" (as the decision name) on the right.
- For BKM "Affordability calculation" "Disposible Income" should be renamed as "Disposable Income" and for the first context entry "-" minus should be used (not an invalid character)
- In case of "Strategy" decision the input clauses should be corrected as "Eligibility" and "Bureau Call Type" instead of "eligibility" and "bureauCallType"
- For "Post-bureau risk category" decision remove invalid characters from the name of "Application Risk Score"
- The external function "PMT" should be declared. We recommend to add a new business knowledge model "PMT" with a knowledge requirement from that business knowledge model "PMT" to "Installment calculation"
Other issues with already reported errors concerning the chapter 11 example:
Reported: DMN 1.1 — Fri, 2 Feb 2018 10:00 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Revision of Chapter 11 example

What has changed?
- All decisions and business knowledge model names were uniformized to lower case
- Decision table "Application risk score model" Age input entries were modified to be complete (ie [18..21], [22..25] were changed to [18..22), [22..26) )
- Everything was recaptured to make sure we had the proper naming in parameters in the decision logic
- XML was generated with DMN 1.2 namespace and the complete DI. There is 6 diagrams corresponding to figure 11.2 to 11.7
- PMT function that is invoked in "Installment calculation decision logic" is now defined in its own file (Chapter 11 Example - Financial.dmn) and this file is imported by Chapter 11 Example. The imported BKM was also added to the proper diagrams.
- A figure of the PMT function was added
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- Chapter 11 changes v3.docx 17 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- V3 Chapter 11 DMN 1.2.zip 755 kB (application/zip)

Wrong length range check for built-in function sublist() and substring()

Key: DMN12-186
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Footnote 2 of table 61 contains wrong check, therefore change footnote 2, to: "length must be in the range [1..E], where E is L - start position + 1 if start position is positive, and -start position otherwise."

The "+ 1" is important!

Example: sublist([1,2,3],1,3)
--> length must be in the range from [1..3] not [1..2]

Same applies to built-in function substring(), table 60 page 133, footnote 1, second sentence.
Reported: DMN 1.1 — Thu, 31 Aug 2017 14:14 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
correct the range of the length arg of 2 builtins

see revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

Wrong numbering in S-FEEL syntax

Key: DMN12-46
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
It is said that the numbering of S-FEEL is the same than FEEL specified in section 10.3.1.2, but from rule 33 to 39 it is not the case anymore.

S-FEEL

33 simple literal = numeric literal | string literal | Boolean literal | date time literal ; (should be 34)
34 string literal = '"' ,
{ character – ('"' | vertical space) }, '"' ; (should be 35)
35 Boolean literal = "true" | "false" ; (should be 36)
36 numeric literal = [ "-" ] , ( digits , [ ".", digits ] | "." , digits ) ; (should be 37)
37 digit = [0-9] ; (should be 38)
38 digits = digit , {digit} ; (should be 39)
39 date time literal = ("date" | "time" | "duration" ) , "(" , string literal , ")" ; (this seems to be a rewrite of rule 62)

FEEL

33. literal = simple literal | "null" ;
34. simple literal = numeric literal | string literal | Boolean literal | date time literal ;
35. string literal = '"' , { character – ('"' | vertical space) }
, '"' ;
36. Boolean literal = "true" | "false" ;
37. numeric literal = [ "-" ] , ( digits , [ ".", digits ] | "." , digits ) ;
38. digit = [0-9] ;
39. digits = digit ,
{digit}
;
51. comparison =
a. expression , ( "=" | "!=" | "<" | "<=" | ">" | ">=" ) , expression |
62. date time literal = ( "date" | "time" | "date and time" | "duration" ) , "(" , string literal , ")" ;
Reported: DMN 1.1 — Mon, 16 May 2016 21:24 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Number the SFEEL grammar rules consecutively.

See revised text. Change is editorial only. Does not change the grammar.
Updated: Wed, 3 Oct 2018 14:17 GMT

Remove tight coupling with BPMN and BMM

Key: DMN12-45
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
The DMN metamodel has Decision with M:N relations that point to BPMN and BMM. This may/will create undesirable referencing issues. While it It is desirable to maintain "loose coupling" between DMN and these external sources (BPMN, BMM, and even CMMN) to do so normally requires these kinds of relations be defined in the caller (or source) rather than the callee (or target). In the particular context of DMN, with respect to BPMN, BMM and event CMMN, the Decision will mostly likely be the target (and not the source). It is recommended to remove the BPMN20::Process, the BPMN20::Task, the BMM::Objective elements from the metamodel and their associated relations and rather make sure that a BPMN, BMM and/or CMMN models can point to a Decision that it uses rather than a DMN Decision pointing to (the potentially not enumerable) places where it is used.
Reported: DMN 1.1 — Mon, 16 May 2016 15:37 GMT
Disposition: Closed; Out Of Scope — DMN 1.2
Disposition Summary:
Cannot remove objects from meta-model, would not be backward compatible.

DMN 1.1 models may reference BPMN or BMM elements. These models must also be valid in DMN 1.2. As I understand backward compatibility requirements, this issue is out of scope for an RTF.
Updated: Wed, 3 Oct 2018 14:17 GMT

Add Diagram Interchange to DMN

Key: DMN12-20
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
This may include both the DRD and boxed expressions (decision tables, etc)
Reported: DMN 1.0 — Thu, 21 May 2015 15:42 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Add Diagram Interchange Chapter and XSD

Add DI chapter and necessary changes to existing spec text.

XSD Changes based on CMMN 1.1 DI:
https://github.com/omg-dmn-taskforce/omg-dmn-spec/commit/d0f469e69a12ccd268c0e24e6d278f7dc6ca9ad9

A more detailed changelog can be found in this Git branch:
https://github.com/omg-dmn-taskforce/omg-dmn-spec/commits/fm-dmn12-62-diagram-interchange
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- 2018-02-15 DMN Diagram Interchange (based on CMMN).doc 319 kB (application/msword)
- Definitions_Class_Diagram.PNG 69 kB ()
- class__DMN_DI.png 6 kB (image/png)
- class__DMN_DI.svg 42 kB (image/svg+xml)
- class__DMN_Diagram.png 22 kB (image/png)
- class__DMN_Diagram.svg 154 kB (image/svg+xml)
- class__DMN_Diagram_Element.png 16 kB (image/png)
- class__DMN_Diagram_Element.svg 94 kB (image/svg+xml)
- class__DMN_Edge.png 12 kB (image/png)
- class__DMN_Edge.svg 70 kB (image/svg+xml)
- class__DMN_Label.png 9 kB (image/png)
- class__DMN_Label.svg 63 kB (image/svg+xml)
- class__DMN_Shape.png 21 kB (image/png)
- class__DMN_Shape.svg 140 kB (image/svg+xml)
- class__DMN_Style.png 23 kB (image/png)
- class__DMN_Style.svg 217 kB (image/svg+xml)
- edge-association-bidirectional.png 0.7 kB (image/png)
- edge-association-one-direction.png 0.7 kB (image/png)
- edge-association-undirected.png 0.5 kB (image/png)
- edge-authority-requirement.jpg 1 kB (image/jpeg)
- edge-information-requirement.jpg 0.8 kB (image/jpeg)
- edge-knowledge-requirement.jpg 1 kB (image/jpeg)
- shape-business-knowledge-model.jpg 2 kB (image/jpeg)
- shape-decision-service-with-divider-line.jpg 28 kB (image/jpeg)
- shape-decision-service.jpg 25 kB (image/jpeg)
- shape-decision-with-listed-input-data.jpg 3 kB (image/jpeg)
- shape-decision.jpg 2 kB (image/jpeg)
- shape-input-data.jpg 2 kB (image/jpeg)
- shape-knowledge-source.jpg 3 kB (image/jpeg)
- shape-text-annotation.jpg 15 kB (image/jpeg)

Attributes in tables 29a and 29b do not correspond to metamodel Fig 51

Key: DMN12-55
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
the tables are using 'inputEntry' and 'outputEntry' whereas the MM uses 'inputValues' and 'outputValues'. The MM is correct.
Reported: DMN 1.1 — Thu, 23 Jun 2016 21:27 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
*change inputEntry to inputValues and outputEntry to outputValues *

Apply editing instructions in Revised Text.
Updated: Wed, 3 Oct 2018 14:17 GMT

typeRef from tables 10 and 15 not in figures 20 and 23

Key: DMN12-23
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
according to the UML diagrams in the figures, Decision and InputData do not have typeRefs. They have variables, which are InformationItems, and it is the InformationItems that have the typeRef. Propose to remove typeRef from tables 10 and 15.
Reported: DMN 1.1 — Fri, 12 Feb 2016 17:58 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
remove typeRef from tables 10 and 15

Apply editing instructions in Revised Text.
Updated: Wed, 3 Oct 2018 14:17 GMT

Decision Table hit policies C and C# should not return null when there are no matches

Key: DMN12-176
Status: closed
Source: Red Hat ( Edson Tirelli)
Summary:
In DMN, null seems to be used mostly to indicate absence of a value or the presence of an error.

When using the Decision Table hit policies C and C#, failure to match rules in the decision table does not mean either. In such cases, the most appropriate and expected result should be:
- for hit policy C: an empty list
- for hit policy C#: the value 0
Reported: DMN 1.1 — Tue, 18 Jul 2017 19:01 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
hit policies C and C# do not return null when there are no matches

See attached Word file
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- Collect hit policies default values (Issue 176) - OMG Proposal (version 2).docx 16 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

FEEL versions cannot be distinguished

Key: DMN12-286
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
FEEL has changed between DMN 1.0, 1.1 and 1.2. We need a way to know which version is used in a model, e.g. by using a new URI for expressionLanguage and typeLanguage.

This is also important, in case FEEL is used outside DMN, because in that case the surrounding model doesn't have any reference to a DMN version.
Reported: DMN 1.1 — Thu, 26 Apr 2018 11:05 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
New URI for FEEL 1.2

In accordance with the "OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces in OMG Specifications – Version 2" (smsc/2015-3-06) and the DMN 1.2 namespace URIs introduced together with Diagram Interchange, new namespace should be:
http://www.omg.org/spec/DMN/20180521/FEEL/
Updated: Wed, 3 Oct 2018 14:17 GMT

DMN built-in functions are missing to ensure business friendliness

Key: DMN12-190
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
A lot of use cases of decision logic involve date and time manipulations (e.g. some decision based on the age of an invoice or a person). The current list of DMN functions is too limited to express the logic in a business friendly way.

For example:
floor((today()-Past Date).days/365.25) to compute the age in years of a person, an invoice, a client account etc. (where 'Past Date' is a date)

or worst

floor(((date and time(Past Date,time("00:00")) + duration("P" + string(floor((today()-Past Date).days/365.25)) +"Y") +duration("P1Y")) - now()) /duration("PT24H")) to compute the number of day until the yearly anniversary of person, an invoice, a client account etc.

A list of additional required built-in functions will be submitted as proposal to this issue
Reported: DMN 1.1 — Wed, 20 Sep 2017 20:03 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Add more built-in functions

Add more built-in functions
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-190_proposal_v4.docx 15 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Import is lacking extension capability

Key: DMN12-231
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
It would be useful to save some custom information on import declaration but no extensions are offered on import.

ExtensionAttributes should be added and potentially ExtensionElements.
Reported: DMN 1.1 — Wed, 14 Feb 2018 22:29 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Make Import MM class inherit from NamedElement

Revise 6.3.3. Import metamodel and Table 6 Import attributes and model associations to reflect Import as subclass of NamedElement.

Make corresponding changes to the XSD.

Backward Compatibility Argument
The new attributes inherited from NamedElement are optional. Import elements that are valid before the change are also valid after the change.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- Import.PNG 68 kB ()

Problem with QName usage in typeRef

Key: DMN12-94
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
typeRef is a QName which has 2 parts, an optional namespace and a local name.
In XML local name is typed as an xsd:NCName and thus cannot have spaces in it.

In the CH11 example of the spec,
There is a serialization error that lead to confusion about Qname…
ex: line 447 there is a formal parameter with a typeRef to "ex:RiskCategory" but its definition at line 84 is:
<itemDefinition name="Risk Category" id="riskCategory_t">
RiskCategory does not reference neither name nor id (name has a space and id is wrong).

The idea of using prefix:name as QName for typeRef in DMN is problematic as name(s) may contain spaces.

It is recommended to use prefix:id as QName and specify this clearly in the spec so we do not run into the spaces in names problem.
Reported: DMN 1.1 — Tue, 20 Sep 2016 20:03 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
typeRefs and ItemDefinition names are FEEL qualified names

In order that typeRef may reference an itemDefinition as prefixed name, as specified in 7.3.2 paragraph 9 and Table 23, the name of an itemDefinition must be a valid XML NCName, as opposed to the less stringent requirements for other NamedElements. That means it may not contain spaces and other characters used in “business-friendly” names. This is implied but not clearly stated in the spec text.

Abstract
• While this issue singles out typeRef, our proposal provides a common basis for representing both imported item definitions and variables (e.g., BKMs).
• Use name not id to reference item definitions (in typeRef) and variables (in FEEL expressions). Use of id-based references should be limited to DRG elements such as in information requirements or DI.
• To the import element, add the new attribute name, a business-friendly, easily remembered string used as a proxy for the namespace value. The name need be unique only in the importing model, not globally.
• Limit reference of target namespace (definitions/@namespace) to models that import other models. In DMN models without import, the target namespace must be declared but is never used in expressions or typeRef.
• For models that do not import other models, typeRef is just the item definition name or FEEL base type name; there is no change to FEEL expressions. For models that do import, both typeRef and FEEL variable references are [import element name].[local-name]. In DMN1.1 imported variables are referenced as [namespace value].[local-name]. Namespace values are typically URLs containing colon, which is disallowed in FEEL qualified names.

Justification
• Names are modeler-entered values, so they should be business-friendly and easily remembered. ids are tool-generated values, typically globally unique, not business-friendly, and not easily remembered. If typeRef is based on id, tool asks modeler to select item definition based on name but then uses id in the XML. This is OK, since modeler does not see the XML. But the same cannot be said for FEEL expressions referencing imported names, such as a BKM.
• Namespace prefixes in QNames are complicated, since the global declaration in definitions may be overridden locally within the model, so the prefix in effect depends on local scope. Import name is declared once in the importing model.
• Simpler is always better. This is much simpler.

Argument for backward compatibility
DMN 1.1 says that typeRefs are strings with the syntax of an XML QName.
DMN 1.2 says that typeRefs are strings with the syntax of a FEEL qualified name. Because QNames can contain the colon character but FEEL names cannot, isn't this a problem?
Not Really. QNames with a colon character are qualified using a namespace prefix, but in DMN 1.1, there is no standard way to define a namespace prefix for an imported type. DMN 1.2 adds the 'name' attribute to the 'Import' class to fix this problem. In DMN 1.1, only non-qualified typeRefs are specified well enough to work, and these will also work in DMN 1.2.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-98-DecisionTable.PNG 80 kB ()
- DMN12-98-Definitions.PNG 77 kB ()
- DMN12-98-Expressions.PNG 69 kB ()
- On Remote References in DMN.docx 18 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Issues with Table 61

Key: DMN12-74
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(on behalf of Bruce)
1. Several functions say N>1 (N is number of list items), but elsewhere spec says a list function with a singleton argument means a list where N=1. Does the table here mean N=1 is an error for these functions?
2. and(list). Examples are incorrect. All 4 examples should be null; the first 2 are the same, and the last 2 are actually undefined if N must be >1.
3. or(list). Ditto 2 above.
4. sublist. Example is incorrect. sublist([1,2,3],1,2)=[1,2]
5. insert before. Example is incorrect. insert before([1,3],1,2)=[2,1,3]
Reported: DMN 1.1 — Mon, 8 Aug 2016 20:53 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Correct rows 2-8,11 of Table 61

see Revised Text. Note that and() is renamed to all() and or() is renamed to any() as per the resolution of DMN-78.
Updated: Wed, 3 Oct 2018 14:17 GMT

Missing annotation in Decision Table in DMN XSD

Key: DMN12-282
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Changed made to the XSD for ~~DMN12-140~~ added the annotationEntry but not the clause.

Also, the annotationEntry type was created inline as all other elements have a separate type.
Reported: DMN 1.1 — Mon, 23 Apr 2018 21:30 GMT
Disposition: Resolved — DMN 1.2

Disposition Summary:

Add missing annotation to Decision table in XSD

Add the following entry right after output in tDecisionTable

<xsd:element name="annotation" type="tRuleAnnotationClause"  minOccurs="0" maxOccurs="unbounded"/>

Remove the annotationEntry element added in ~~DMN12-140~~

Add the following line right after outputEntry in tDecisionRule

<xsd:element name="annotationEntry" type="tRuleAnnotation" minOccurs="0" maxOccurs="unbounded"/>

Add the flowing complex types after tDecisionRule

        <xsd:complexType name="tRuleAnnotationClause">
               <xsd:attribute name="name" type="xsd:string"/>
        </xsd:complexType>
        <xsd:complexType name="tRuleAnnotation">
               <xsd:sequence>
                       <xsd:element name="text" type="xsd:string" minOccurs="0"/>
               </xsd:sequence>
        </xsd:complexType>

Updated: Wed, 3 Oct 2018 14:17 GMT

Wrong chapter reference for date and time / date and time subtraction

Key: DMN12-203
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Row 2 describes the subtraction of date and time values. The description in column 3 says "... where value _dt is defined in 10.3.2.3.5 date ...". I think this is a mistake. The reference should be "... where value _dt is defined in 10.3.2.3.6 date-time ...". Otherwise a conversion from date and time to date is necessary and the minimal unit would by days.

Page 132, table 58 lists the following example:
date and time("2012-12-24T23:59:00") - date and time("2012-12-22T03:45:00") = duration("P2DT20H14M")
The minmal unit here is minutes.

Therefore I think this is a typo with a wrong chapter reference.
Reported: DMN 1.1 — Tue, 10 Oct 2017 13:37 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
fix typo in chapter reference

see revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

Type should be specified for date, time and duration properties

Key: DMN12-201
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Table 53 defines the properties for different types. But the types of the properties are not specified.

Specification should be as listed here:
- for date
  - year, month, day (all of type number)
- for date and time
  - year, month, day, hour, minute, second (all of type number)
  - time offset (type days and time duration)
  - timezone (type string)
- for time
  - hour, minute, second (all of type number)
  - time offset (type days and time duration)
  - timezone (type string)
- for years and months duration
  - years, month (all of type number)
- for days and time duration
  - days, hours, minutes, seconds (all of type number)
Reported: DMN 1.1 — Tue, 10 Oct 2017 09:41 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
add type and normalize into 2 tables

See attached proposal.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-201 (version 2).docx 98 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

While BKMs enable re-use, the options for re-use are restricted to single pieces of decision logic

Key: DMN12-10
Status: closed
Source: Signavio GmbH ( Dr. Bastian Steinert)
Summary:
It should be possible to re-use a decision subgraph by extracting it to another diagram and replacing it with a reference and an invocation to the extracted decision in the original diagram.

Given the current MM, I see two ways of making that possible:
- introducing a sub-type of BKM that allows referencing a decision in another diagram
- introducing a sub-type of Invocation that allows referencing a decision in another diagram
The attachment illustrates the missing and proposed re-use possibilities of the "affordability calculation" (from the example section). The attached example uses the second option of the two.
Reported: DMN 1.0 — Tue, 21 Jul 2015 15:41 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Allow Decision Service to be invoked from decision logic in a decision model

Revised text is attached as Invocable (Issue 10) - OMG Proposal (version 14).
XML Schema changes described by: https://github.com/omg-dmn-taskforce/omg-dmn-spec/commit/82d171eafa8be4e5659b6e47b46a76a025f15d0d
All figures will be separately attached in the final report as .svg files

Argument for Backward Compatibility
The newly added class (complexType) Invocable is abstract and thus not in the serialization. Concrete attributes are unchanged (except made optional).
Note that before this change, there was no standard way to serialize a decision model containing a decision service; hence, w.r.t. decision services, there is no compatibility to maintain.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- Invocable (Issue 10) - OMG Proposal (version 14).docx 943 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Spec figures.vsd 890 kB (application/vnd.visio)
- connection-bkm-decision-service-collapsed.svg 19 kB (image/svg+xml)
- connection-bkm-decision-service.svg 5 kB (image/svg+xml)
- connection-decision-decision-service-collapsed.svg 11 kB (image/svg+xml)
- connection-decision-decision-service.svg 5 kB (image/svg+xml)
- shape-decision-service-collapsed.svg 5 kB (image/svg+xml)
- shape-decision-service.svg 4 kB (image/svg+xml)

Show diagram elements with hidden links

Key: DMN12-38
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
Because Decisions, Knowledge Sources, Input Data and BKMs can appear on many diagrams they may have requirements that are not shown on a given diagram. While this is a powerful feature it can be confusing if it is not clear to a user that such links exist but are not displayed. This could be left a a tooling issue but on balance some notation (an ellipsis for instance) that was common woudl probably be more useful.

In spite of the attached figures (meant to provoke discussion), the scope of this issue is limited to "flat" DRDs, that is, no "sub-DRDs" nested inside an outer decision or BKM.
Reported: DMN 1.1 — Wed, 11 May 2016 04:06 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Specify ellipsis as marker for missing information

See Revised Text
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DRD Encapsulation and Reuse v1.PNG 141 kB ()
- DRD Filtering Ellipsis vs Dotted Outline v1.PNG 109 kB ()

Allow DMN DI to provide an alternative notation for Input Data (DMN 1.2)

Key: DMN12-272
Status: closed Implementation work Blocked
Source: BPM Advantage Consulting ( Dr. Stephen White)
Summary:
More and more, DMN is being used in conjunction with BPMN and CMMN. The recent work of the OMG BPM Healthcare initiative is a prime example. The Healthcare Field Guide being developed is anchored with the three standards as the way forward for developing healthcare clinical pathways. Feedback from this work and work being done for the VHA using all three standards, is that data notation should be consistent across all three specifications. Thus, the BPMN Data Object, the CMMN Case File, and the DMN Data Input should all look the same since they represent the same general concept to the people creating the models. Further, it will help readers of the models, who don't create them, but are responsible for their implementation within the organization, to understand how the three models work together. Such readers could be hospital clinical informatists.
While there may be technical differences between the data representations among the three standards, these differences are not important to the business analysts who are using the models nor the readers of the models. The general concept of data used within a process, case, or decision is common across the three specs.
Thus, the proposal for this issue is to allow modeling tools to provide an alternative notation for DMN Data Inputs that matches the notation found for BPMN Data Objects and CMMN Case Files.
Reported: DMN 1.1 — Tue, 3 Apr 2018 18:24 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
duplicate of dmn12-44

close as duplicate. Note that dmn12-44 is deferred.
Updated: Wed, 3 Oct 2018 14:17 GMT

Chapter 11 example decision tables are incomplete

Key: DMN12-126
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Consider, for example, Figure 84 on pg 158. This table is missing a rule for Age in the range (21..22). For example, for Age=21.5. Note that DMN has a number type, but no integer type, so it is not possible to restrict Age to integers (within the DMN spec, at least). It would be better to use intervals that adjoin, e.g. [18..22), [22..26), [26..36), etc.
Reported: DMN 1.1 — Wed, 18 Jan 2017 02:32 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
use round and square bracket range notation to avoid gaps

close proposal for integer type for now - can open a new issue (in 1.3 for integer types)
Updated: Wed, 3 Oct 2018 14:17 GMT

Please clarify what is the result of a filter with non-boolean expressions (null)

Key: DMN12-262
Status: closed Implementation work Blocked
Source: Red Hat ( Edson Tirelli)
Summary:
Example: a relation "people" with the following content:

people : [
{ name : "Bob", age : 30 }
,
{name : "Max", age : null }
]

What is the result of an expression like the following:

people[ age > 20 ]

The filter will obviously evaluate to true for the first person "Bob", but the for second person, age is null, and the expression `age > null` will also return null.

What is the result of the expression?

a. [
{ name: "Bob", age : 30 }
]
b. null
c. some other value?

Please clarify explicitly in the spec what is the result of a filter which might evaluate to null for some elements, like the above example.
Reported: DMN 1.1 — Thu, 15 Mar 2018 00:02 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
add example of null filter

see revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

Lost formatting in 10.3.2.2 Equality, Identity, and Equivalence

Key: DMN12-246
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Some formatting (bold, italics, subscript) has been lost in the 2nd para of 10.3.2.2.
Reported: DMN 1.1 — Tue, 13 Mar 2018 23:35 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Add formatting as given

See revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

add weekday property to date, date and time

Key: DMN12-217
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
should work like XML Schema
Reported: DMN 1.1 — Thu, 14 Dec 2017 16:19 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
*merged *

see ~~DMN12-201~~
Updated: Wed, 3 Oct 2018 14:17 GMT

Semantic mapping for XML syntactical artifacts

Key: DMN12-184
Status: closed
Source: Trisotech ( Mr. Denis Gagne)

Summary:

Names are unique in DMN. As such there are no need to add syntactical artifacts during the mapping from XML to DMN context.

We propose the following changes:

Table 56

XML	Context entry in p	Remark
...	...	...
<q:e/>	"e": null	namespaces are ignored.
...	...	...
<e a = "v"> <c1>v1</c1> ...	"e":{"a": XV(v), ...	An element containing attributes or child elements -> context
...	...	...

Table 57
Remove "@a": in the FEEL semantic Domain column for rows date, dateTime, time and duration.

Figure 10.3.3.3.3
Change tns$Employee for Employee
Change tns$salary for salary

Reported: DMN 1.1 — Wed, 6 Sep 2017 20:28 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
ignore namespace and prefix in XML mapping

see revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

Releation between Definitions and DecisionService does not specified in XSD

Key: DMN12-121
Status: closed
Source: ACTICO GmbH ( Eduard Weiss)
Summary:
I am currently working on DMN and try to reuse xsd file (http://www.omg.org/spec/DMN/20151101/dmn.xsd) in our product. The problem what I have is that I cannot find definition of releation between Definitions and DecisionService inside xsd such as described in the specification page 40.

Is it right or do I misundertand the xsd format?
Reported: DMN 1.1 — Mon, 5 Dec 2016 08:59 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
Fixed by ~~DMN12-10~~/~~DMN12-174~~

This issue has been fixed by ~~DMN12-10~~/~~DMN12-174~~.
Updated: Wed, 3 Oct 2018 14:17 GMT

Useful to denote which info requirements are unconditional

Key: DMN12-14
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
A decision with logic: if x then y else z has an unconditional requirement on x but a conditional requirement on y and z. This is useful to represent in the notation (perhaps as a tick mark on the requirement arc in homage to BPM's unconditional gateway exit arc) and in the MM. It could prove very useful to implementors, who could use data-driven dataflow to activate the decision when x is available, but to produce y or z on demand.
Reported: DMN 1.0 — Thu, 13 Aug 2015 05:44 GMT
Disposition: Closed; No Change — DMN 1.2
Disposition Summary:
withdrawn - no clear proposal or compelling use case

withdrawn by submitter
Updated: Wed, 3 Oct 2018 14:17 GMT

Need attribute for human and external decisions

Key: DMN12-59
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Normally, a valid executable model requires a value expression for every decision. However, human decisions and external decisions, by definition, exclude a value expression. To allow validation to skip such decisions, an attribute identifying a decision as human or external would be useful.
Reported: DMN 1.1 — Tue, 28 Jun 2016 14:49 GMT
Disposition: Closed; No Change — DMN 1.2
Disposition Summary:
unnecessary - value expression can be in natural language

According to the spec, one can use the expressionLanguage attribute set to the value http://www.omg.org/spec/DMN/uninterpreted/20140801 to indicate that the value expression of a decision is not to be interpreted.
Updated: Wed, 3 Oct 2018 14:17 GMT

Space in FEEL names is not well-specified

Key: DMN12-58
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(from Bruce)
Space in FEEL names is not well-specified. Space (&#x20) is not a name character allowed by rules 30-32, nor is it included in the construction of name from name start and name part|additional symbol (rule 27). But additional syntax rules says single spaces are allowed in names (somewhere). I believe the intent is that “Applicant Data” and “ApplicantData” are both valid names but are not the same name. Specific ambiguities include:

· What is the relationship between space and name part? Does a space always act as a separator between name parts?

· If not, can a name part begin or end with space? Can a name start begin or end with space?

· Related: Do additional symbols also act as separators between name parts, when they do not represent operators?

· Does . act as separator between name parts (when not used as path operator or decimal point)?

· The chapter 11 example (e.g. fig 79) includes things like Applicant data . Age (note space before and after the period). Is this valid syntax?
Reported: DMN 1.1 — Tue, 28 Jun 2016 14:47 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
create new section in chapter 10 for names, tokens, and whitespace processing and improve ambiguity section

see attached proposal

Argument for Backwards Compatibility
All valid DMN 1.1 names are valid in 1.2.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-58_proposal_v3.docx 14 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Dynamic invocation

Key: DMN12-37
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(raised by Bruce)
In DMN 1.1, the target of an invocation was changed from the name of a BKM to any expression, presumably one that results in a BKM name. The reason given was to allow dynamic invocation, for example, if condition1 then BKM-X else BKM-Y. That is a potentially useful thing, but dynamic invocation would require further changes to DMN. In particular, knowledge requirements point to a particular BKM id. Changing knowledge requirement target to an expression would make it difficult (impossible?) to represent the element as a connector in the DRD. Also, the invocation bindings point to specific parameter names, requiring all targets of the dynamic invocation to have the same parameter names.
Reported: DMN 1.1 — Mon, 9 May 2016 19:25 GMT
Disposition: Closed; No Change — DMN 1.2
Disposition Summary:
had discussion, no change needed

no change
Updated: Wed, 3 Oct 2018 14:17 GMT

Show implied Information Requirements

Key: DMN12-39
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
It is easy to take advantage of the ability to have multiple DRDs showing the same objects to create multiple layers of detail - a high level DRD, more detailed ones for each "leg" etc. In general this works perfectly with decisions "encapsulating" their dependency network. The one thing that would occasionally be useful is an ability to see how Input Data is used throughout.
For instance, when Decision A requires Decision B which requires Decision C which requires Input Data D it would be useful to see that Decision A indirectly requires Input Data D. A version of a information requirement link that showed an indirect requirement would allow this to be shown without in any way violating or undermining the current approach to reuse across diagrams.

The scope of this issue is limited to "flat" DRDs, that is, no "sub-DRDs" nested inside an outer decision or BKM.
Reported: DMN 1.1 — Wed, 11 May 2016 04:11 GMT
Disposition: Closed; No Change — DMN 1.2
Disposition Summary:
too difficult to do with diagram interchange framework

The DI framework can diagram semantic elements, but here there is no actual element, only an element that can be derived by transitivity. That is not sufficient for DI, and we do not want to materialize all possible transitive links.
Updated: Wed, 3 Oct 2018 14:17 GMT

Graphical representation of Context - "sub-DRDs"

Key: DMN12-28
Status: closed
Source: Signavio GmbH ( Dr. Bastian Steinert)
Summary:
This issue is meant to factor-out the "sub-DRD issue" from a number of issues (~~DMN12-27~~, ~~DMN12-38~~) that are actually independent of whether we have "sub-DRDs". There may be better ways or alternate ways of expressing notation and meaning of a 'DRD in a box' but this seems to be a recurring theme so similar issues or competing proposals should be linked here for comparison.

Context is an important form of value expression but tool vendors appear reluctant to implement it, believing it to be not as business-friendly as a DRD expressing the same logic. I propose that DMN 1.2 add a graphical representation of a context, in which nodes represent a context entries, linked by information requirements. A decision whose value expression is a context represented in this way would be indicated in the DRD with a special marker.

The benefits of such a change are these:
1. Increased support for Contexts by tool vendors
2. More business-friendly representation
3. Simpler “top-level” DRD representation of complex end-to-end logic
4. Reusability of more complex decision logic, since BKMs can visualize their value expression in this way.
5. Compatibility with Bastian’s MID proposal 12-27.
Reported: DMN 1.1 — Wed, 4 May 2016 18:15 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
Invocable decision service addresses this issue

See ~~DMN12-10~~
Updated: Wed, 3 Oct 2018 14:17 GMT

Consider date and time datatype in S-FEEL

Key: DMN12-5
Legacy Issue Number: 19755
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
a. In clause 9.2, para 5, first sentence, "date and time" should be in italics.
b. Why is date and time type excluded from S-FEEL? This restriction makes XSD mapping problematic.
Reported: DMN 1.0 — Tue, 28 Apr 2015 04:00 GMT
Disposition: Closed; No Change — DMN 1.2
Disposition Summary:
No SFEEL changes

Not enough usage of SFEEL to justify change at this time.
Updated: Wed, 3 Oct 2018 14:17 GMT

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

FEEL 'instance of' operator is underspecified

Key: DMN12-47
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
it seems clear from Ch 10 that 'x instance of string' and 'x instance of number', for example, are defined and are true when the value of x is a string or number as defined in Ch 10. However, if the value of x is a context that conforms to some ItemDefinition or XML Schema type, then it is not defined whether this is possible or exactly what it means. We would need to define what it means for a context (and list) to be valid w.r.t. a typeRef. FEEL semantics are execution semantics, and are not validation semantics. A precise statement of validation semantics could be very useful for standardized validation of a model w.r.t. input data (which have typeRefs but not executable input values). However, this is a big job.
Reported: DMN 1.1 — Sat, 21 May 2016 18:52 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
better type checking spec covers this

now we have defined instance of on feel constructed types - lists and contexts
Updated: Wed, 3 Oct 2018 14:17 GMT

SFEEL makes too few people happy

Key: DMN12-48
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
There are many reported issues complaining that SFEEL lacks something in FEEL, or with people unhappy with something that is in both FEEL and SFEEL. For example,
The current SFEEL EBNF does not provide for the use of parentheses to set arithmetic precedence of operations.
The current EBNF only supports precedence of operators e.g. 2+3*4 = 14
In Decisions relying on more advanced arithmetic (e.g. Financial decisions related to mortgages or claims) it is desirable to allow the expressiveness of "scientific" calculation to allow the
use of parenthesis to set precedence e.g (2+3)*4 = 20.
It is recommended to add the use of parenthesis in arithmetic expressions and have them set precedence of operations.
Reported: DMN 1.1 — Wed, 25 May 2016 15:09 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
recommend full FEEL

See revised text.
Updated: Wed, 3 Oct 2018 14:17 GMT

Missing support for escape sequences in string literals

Key: DMN12-226
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Currently the syntax for string literals does not support escape sequences.
Reported: DMN 1.1 — Fri, 26 Jan 2018 16:20 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Add support for escape sequences in string literals

Change production for string literals in FEEL grammar to add support for escape sequences
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-226_proposal_v1.docx 23 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Would like to use duplicate shapes/names in diagram to avoid multiple requirement line crossings

Key: DMN12-129
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Multiple occurrences of shape/element X are currently prohibited in the spec (6.2.1.1). Would be nice to allow multiple occurrences instead of one with many outgoing requirement arrows. This affects diagram interchange, because there would be >1 diagram element per metamodel element. Need a MM element per occurrence in diagram.
Reported: DMN 1.1 — Thu, 26 Jan 2017 16:21 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
~~DMN12-62~~ Diagram Interchange allows multiple diagram elements per DMN element.

The latest proposal of Diagram Interchange ~~DMN12-62~~ removed the following sentence, which was inherited from BPMN and DMN:

Multiple depictions of a specific DMN element in a single diagram are not allowed.
Updated: Wed, 3 Oct 2018 14:17 GMT

definition of expression in glossary omits CL3 expressions

Key: DMN12-12
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The glossary is not only for CL2. CL3 adds contexts, relations, functions, etc. to the repertoire of boxed expressions
Reported: DMN 1.0 — Fri, 21 Aug 2015 19:56 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
enumerate all the expressions

see revised text.
Updated: Wed, 3 Oct 2018 14:17 GMT

Invalid example for date and time property access

Key: DMN12-206
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Excerpt from specification: "For example, FEEL(date and time("03-07-2012Z").year) = 2012"

The string literal format of the date and time string is invaild. It doesn't match XML Schema Part 2 Datatypes as mentioned on page 131 for type date.

Please change the text to: "For example, FEEL(date and time("2012-07-03T00:00Z").year) = 2012"
Reported: DMN 1.1 — Thu, 12 Oct 2017 08:03 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
fix typo in date and time string

see revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

Impossible to invoke functions and() and or()

Key: DMN12-78
Status: closed Implementation work Blocked
Source: Red Hat Inc ( Edson Tirelli)
Summary:
Page 109 of the specification, 3rd bullet, states:

“A name start (grammar rule 28) SHALL NOT be a language keyword. (Language keywords are enclosed in double quotes in the grammar rules, for example, "and", "or", "true", "false".)"

The specification defines a function invocation on page 108, rule 40, as:

function invocation = expression , parameters ;

The list of built-in functions on page 134 lists both functions “and(…)” and “or(...)” as built in functions, but from the grammar rules mentioned above, it is clear that “and”, is not a valid "expression", and so “and(…)” is also not a valid function invocation.

The same is true for “or(...)”.

Either the functions need to be renamed to use valid identifiers (i.e., identifiers that do not start with a keyword) or the grammar has to be changed to allow for this special case. My personal preference is to rename the built in functions to something like “list and(...)” and “list or(...)”.
Reported: DMN 1.1 — Tue, 23 Aug 2016 01:25 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
rename 'and' to 'all' and 'or' to 'any'

see revised text

Argument for Backward Compatibility
Normally, a change of name of built-in function would be an incompatible change. However, this part of the 1.1 spec proved impossible to implement, because the name of a built-in cannot be a language keyword. I.e., nothing to be compatible with here.
Updated: Wed, 3 Oct 2018 14:17 GMT

alternative indication of reusable logic in DRD

Key: DMN12-6
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In the metamodel/XSD, decision logic is contained in a decision element, hence not reusable. To reference reusable decision logic, decision invokes BKM, which is reusable. The semantics are clear, but representation of the decision and BKM as separate graphical elements in DRD is visually inefficient. It creates unnecessary clutter in the DRD (Fig 63 is a prime example). BPMN solved this problem in a better way, and I suggest DMN should allow the same. In BPMN a subprocess definition is embedded in the parent process so to reference reusable subprocess, it uses a call activity. The call activity shape is same as subprocess except it has a thick border style. The diagram does not contain both subprocess and call activity, just one or the other. I would like to propose that a decision shape in DRD with a thick border be used to mean the decision invokes a BKM (with name generated from the decision name). No metamodel or schema changes required; this is merely alternative graphical notation. In a DMN tool, typically clicking on the decision will hyperlink to the decision logic (DT or literal expression), whether that logic is embedded in the decision or reusable. This distinction is mostly important to programmers, not modelers, so should not unnecessarily complicate the diagram.
Reported: DMN 1.0 — Tue, 5 May 2015 17:58 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
subsumed by invocable decision service

no longer an issue after invocable decision service feature added.
Updated: Wed, 3 Oct 2018 14:17 GMT

Label of Input in decision table

Key: DMN12-88
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
In Decision table, the input extends DMNElement which gives them a label.
However, the spec clearly states that what is depicted on a Decision Table is the input expression (ref: Fig 33), not the label therefore the label attribute is useless .
What should be done with it?

NB (This issue also relate to the upcoming Diagram Interchange (DI) capability coming)
Reported: DMN 1.1 — Fri, 26 Aug 2016 18:37 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
Close as duplicate of ~~DMN12-89~~

The role of label has been clarified by ~~DMN12-93~~, which is the proposal for issue ~~DMN12-89~~.
Updated: Wed, 3 Oct 2018 14:17 GMT

FEEL path expression has same precedence as filter and invocation

Key: DMN12-60
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Grammar rules 2g and 2h indicate that filter and invocation have higher precedence than path expressions. Actually, they have the same precedence are left associative. Suggest combining these 2 rules into 1.
Reported: DMN 1.1 — Wed, 29 Jun 2016 14:59 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
combine grammar rules 2g and 2h

Apply editing instructions in Revised Text.
Updated: Wed, 3 Oct 2018 14:17 GMT

Decision Service Cannot be Shown in DRD

Key: DMN12-136
Status: closed
Source: Sapiens Decision NA ( Mr. Gil Ronen)
Summary:
The DMN Element Metamodel (Fig. 18 in the specification) shows that Decision Services are NOT a subclass of DRGElement. The definition of the DRD requires its components to be DRGElement (“A Decision Requirements Diagram (DRD) is the diagrammatic representation of one or more instances of DRGElement and their information, knowledge and authority requirement relations “). I think the Decision Service should be part of the DRD, especially if it is a callable unit within the DRD (that is, can be linked to a BKM as per ~~DMN12-10~~/~~DMN12-135~~).
Reported: DMN 1.1 — Thu, 23 Feb 2017 13:16 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
fixed by invocable decision service ~~DMN12-10~~

In the current MM (e.g. see the Ballot13 convenience doc) the DecisionService class extends Invocable which extends DRGElement.
Updated: Wed, 3 Oct 2018 14:17 GMT

Transitive information requirements maybe inferred from the spec text

Key: DMN12-225
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Page 60 para 5 says:
"As explained above, every information requirement at the DRG level is associated with a variable used at the decision
logic level. Each variable that is referenced by a decision’s expression must be a variable referenced by one of the
decision’s information requirements or an information requirement in the decision's requirement subgraph."

Page 177 Glossary entry for "Requirement Subgraph" says:
"The directed graph resulting from the transitive closure of the
requirements of a DRG element; i.e., the sub-graph of the DRG
representing all the decision-making required by a particular element"

From these two entries one could erroneously infer that Information Requirement is transitive in nature. This creates serious concerns for BKMs and Decisions Services.
Reported: DMN 1.1 — Mon, 29 Jan 2018 18:55 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
*Review text section 7.1 to remove potential misinterpretation of transitivity due to subgraph def and so it better reflects meta model *

See revised text.
Updated: Wed, 3 Oct 2018 14:17 GMT

Requirements don't have an ID (needed for DI)

Key: DMN12-101
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
The classes InformationRequirement, KnowledgeRequirement and AuthorityRequirement do not have an ID. But, they need one in order to reference them in Diagram Interchange.
Reported: DMN 1.1 — Thu, 20 Oct 2016 17:36 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Make InformationRequirement, KnowledgeRequirement and AuthorityRequirement inherit from DMNElement

Update MM figures:
- Figure 20: Decision Class Diagram
- Figure 22: BusinessKnowledgeModel class diagram
XSD Diff: https://github.com/omg-dmn-taskforce/omg-dmn-spec/commit/fabefaf02122f449d50a235ddc3d8f016202c1b0

Argument for backward compatibility
All added attributes are optional. Thus, a valid DMN 1.1 model, lacking all these new optional attributes, is also a valid DMN 1.2 model.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-10-KnowlegeSource.PNG 46 kB ()
- DMN12-102-BKM.PNG 36 kB ()
- DMN12-102-DecisionPNG.PNG 77 kB ()

Drg element labels

Key: DMN12-43
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(from Bruce)
A drg element name is supposed to match the name of the variable owned by the element, but many tools allow the element shape label to be different from the variable name. The spec should clarify whether this is allowed, possibly saying that the shape label is explicitly the label attribute and not the name.
Reported: DMN 1.1 — Sat, 14 May 2016 23:32 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
~~DMN12-93~~ explains that name is preferred to label if it exists

Also says label is not used in notation. This should clarify any confusion.
Updated: Wed, 3 Oct 2018 14:17 GMT

Eliminate () from FEEL and S-FEEL

Key: DMN12-21
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
The notation for ranges in FEEL currently allows ( ) , [ ] , ][ or combinations to show inclusive or exclusive ranges. The use of ( ) to show exclusive ranges is extremely confusing to non-computer science people. The non-technical assumption is that all ranges are inclusive and the distinction between ( and [ is too minor - it forces people to KNOW where they should be able to intuit.
If we remove support for () but leave support for ][ we don't eliminate the ability to use exclusive ranges, we just make it much clearer.
Reported: DMN 1.1 — Tue, 19 Jan 2016 23:37 GMT
Disposition: Closed; No Change — DMN 1.2
Disposition Summary:
no change because some people are using the feature

no change
Updated: Wed, 3 Oct 2018 14:17 GMT

Add id to context entry

Key: DMN12-134
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Rules of a decision table have ids but context entries do not. One should be added so it can be reference; for error reporting for example.
Reported: DMN 1.1 — Mon, 13 Feb 2017 21:49 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Make ContextEntry a DMNElement to inherit its ID

Make ContextEntry a DMNElement in order to inherit its ID.

XSD change: https://github.com/omg-dmn-taskforce/omg-dmn-spec/commit/dc1863fd27b993c908045a8807d756be55dea107
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-152-ExpressionsL3.PNG 41 kB ()

DMN 1.1 XML schema starts with ZERO WIDTH NO-BREAK SPACE (U+FEFF)

Key: DMN12-68
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)

Summary:

The DMN 1.1 XML schema (dmn.xsd) starts with zero width no-break space character (U+FEFF).

This can be seen with less dmn.xsd:

<U+FEFF><?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://www.omg.org/spec/DMN/20151101/dmn11.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.omg.org/spec/DMN/20151101/dmn11.xsd" elementFormDefault="qualified">
...

Proposal:
Remove the character using sed 's/\xef\xbb\xbf//g' dmn.xsd > fine.xsd

Reported: DMN 1.1 — Tue, 12 Jul 2016 22:45 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Remove zero-width non-breaking space from DMN XML schema

Remove the character using sed 's/\xef\xbb\xbf//g' dmn.xsd > fine.xsd
Updated: Wed, 3 Oct 2018 14:17 GMT

Scope of Variables in Context Boxed Expression

Key: DMN12-33
Status: closed
Source: Sapiens Decision NA ( Mr. Gil Ronen)
Summary:
Visibility (scope) for variables in Context Boxed Expressions that have a final result box is not clear; The spec does not address whether they are available through dot notation or are they local in scope and not accessible from outside the Context. For Contexts without a final result box it is implied that the variables are accessible through dot notation.
Reported: DMN 1.1 — Thu, 5 May 2016 15:48 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
clarify that context entries visible iff no result box

See revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

some/every ... satisfies not defined for empty list

Key: DMN12-87
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Table 37 gives semantics but does not cover empty list
Reported: DMN 1.1 — Thu, 25 Aug 2016 15:26 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
define some... of empty list to be false and every... of empty list to be true

See revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

Table 45 does not provide the semantic of addition and subtraction between elements of type Date and Duration

Key: DMN12-211
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Table 45 does not explicitly state semantics of arithmetics for date and duration values
Reported: DMN 1.1 — Tue, 14 Nov 2017 16:42 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
add 4 rows to table 45 (now 49) to account for date input/output

see revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

FEEL precedence for function definition

Key: DMN12-162
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
on page 109: "Operator precedence is given by the order of the alternatives in grammar rules 1, 2 and 4, in order from lowest to highest."

But grammar rule 2.a and 1.b contains "function definition". Therefore the precedence of a function definition is not clearly specified. Should we use 2.a (lower precedence) or 1.b (higher precedence) for a function definition?
Reported: DMN 1.1 — Wed, 3 May 2017 08:47 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
remove redundant grammar rule for function defn and reverse rules 1a and 1b

The current grammar has a duplicate reference to the function definition rule. Rules 1a and 1b are also in the wrong priority order.
Updated: Wed, 3 Oct 2018 14:17 GMT

Metamodel is missing the "kind" attribute on function

Key: DMN12-160
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
This attribute is depicted on boxed function and explain on page 104 but cannot be serialize as it is not part of table 67 presenting function attribute on page 140.
Reported: DMN 1.1 — Wed, 19 Apr 2017 04:00 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Add kind attribute to FunctionDefinition element

add to MM diagram

XSD Diff: https://github.com/omg-dmn-taskforce/omg-dmn-spec/commit/de4a4ee893b8374ea09395ee9df5a987f18e8189

See revised text for the changes on the attribute table.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-160-Expressions-Fig67.PNG 47 kB ()

Return All Annotations for All Hit Policies

Key: DMN12-124
Status: closed
Source: Sapiens Decision NA ( Mr. Gil Ronen)
Summary:
Typically, we want to know all the reasons for a conclusion and this requires metadata information about all the Hits even when returning a single conclusion.

For example, for an ‘Any’ Hit Policy Decision Table that results in the conclusion ‘Ineligible’ we want to know that the reasons are ‘Credit score too low’ and ‘Debt-to-income ratio too high’. Similarly, for an aggregated result using ‘Sum’ in the Decision ‘Total Tuition’, besides the total of $1,300, we want to know that the total includes ‘Materials $350’ and ‘Classes $950’.

Possible approaches:
1. Attribute on the Decision Table itself that includes a list of annotation columns to return in full regardless of the Hit Policy.
2. By default, always return all the annotations.
Reported: DMN 1.1 — Thu, 5 Jan 2017 15:46 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Annotation Outputs

See attached (version 6).
Higher resolution figures attached as pptx.
MM attached.
XSD change linked.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-140-DecisionTable.PNG 94 kB ()
- DT figs - GR.pptx 215 kB (application/vnd.openxmlformats-officedocument.presentationml.presentation)
- Rule Annotations - OMG Proposal (version 6).docx 242 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Parameter names of built-in function date and time(date, time) are not allowed by name rules

Key: DMN12-195
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Table 58 on page 131 defines the built-in function date and time(date, time) with parameter name "date" and parameter name "time".

But on page 109 additional syntax rules are listed:
"A name start (grammar rule 28) SHALL NOT be a language keyword."

These two definitions are conflicting.

Since "date" and "time" are language keywords (listed in grammar rule 62 for date time literal) the parameter names are illegal. The invocation of the built-in function with named parameters is not possible:
date and time(date: date("2017-01-01"), time: time("11:00:00"))

The recommendation is to define other named parameter names for the built-in function:
- rename "date" parameter to "date part"
- rename "time" parameter to "time part"
Reported: DMN 1.1 — Thu, 21 Sep 2017 14:19 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
remove date builtins as keywords

see revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

Table 45 does not provide the semantic of addition and subtraction between two elements of type date

Key: DMN12-189
Status: closed Implementation work Blocked
Source: Trisotech ( Mr. Denis Gagne)
Summary:
A row is missing in table 45 to present the addition and subtraction semantic when e1 and e2 are both of type Date.
Reported: DMN 1.1 — Wed, 20 Sep 2017 19:45 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Clarify semantics of addition/subtraction between dates and date and time values on table 45

Table 45 does not explicitly state semantics of arithmetics for date and date and time values.
Updated: Wed, 3 Oct 2018 14:17 GMT

Unclear meaning of unique name constraint for ItemDefinitions and DRGElements

Key: DMN12-141
Status: closed
Source: Signavio GmbH ( Dr. Bastian Steinert)
Summary:
The following sentence on page 65 / 69 in paragraph 7.3.2 has been interpreted differently:

"The name of an ItemDefinition element SHALL be unique within the containing instance of Definitions and its associated namespace"

Also, may be common to use same name for input data and an item definition that describes its shape, e.g. PurchaseOrder.

Need to account for namespaces (uniqueness always within Definitions element)

At least, all the 'variables' should have unique names, that is, Decisions, InputData, BKMs, and DecisionServices must have unique names within the containing Definitions. Further, all ItemDefinitions must have unqiue names (but could duplicate an input data, e.g.).

Imported elements are qualified by the name of the import. e.g. short.my-decision + 1
Reported: DMN 1.1 — Tue, 14 Mar 2017 08:39 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
re-phrase unique name constraint for ItemDefinitions

improve description of unique name constraint for ItemDefinitions to make clear that it refers to ItemDefinition only
Updated: Wed, 3 Oct 2018 14:17 GMT

Parameter domain for built-in function years and months duration() is wrong

Key: DMN12-187
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
Table cell of table 58 says that date and time is the needed type, but example in last column uses date. Therefore, please change the text in the Parameter Domain cell to "both are date".
Reported: DMN 1.1 — Fri, 1 Sep 2017 14:07 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
explicitly allow date args to years and months duration builtin

see revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

Decision table is not a good example of a builtin function

Key: DMN12-84
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
10.3.2.11 Function Semantics
FEEL functions can be
 built-in, e.g., decision table (see 10.3.4.6 Decision Table), or

Actually, decision table is not a real builtin function (as ~~DMN12-81~~ points out), so a better example is something like sum()

should remove textual decision table builtin (ch 10) and use schematic DT boxed expr instead (something like Figure 36)
Reported: DMN 1.1 — Thu, 25 Aug 2016 05:45 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
remove all mention of decision table builtin function

Decision tables are an aggregation of LiteralExpressions, UnaryTests, and other things, but are not actually builtin functions because UnaryTests have no interpretation by themselves. See Revised Text.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- DMN12-97.odt 23 kB (application/vnd.oasis.opendocument.text)
- DMN12-97.pdf 78 kB (application/pdf)

X and TBD are undefined in Table 35

Key: DMN12-83
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
I think both mean that 'no mapping is defined' and probably a blank cell would be better. And the text should say 'a blank cell means no mapping is defined'.
Reported: DMN 1.1 — Thu, 25 Aug 2016 05:39 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
replace 'X' and 'TBD' in Table 35 with empty cells

see revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

grammar rule 56 missing comma

Key: DMN12-86
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
change
56. list = "[" [ expression ,
{ "," , expression } ] , "]" ;
to
56. list = "[" , [ expression , { "," , expression }
] , "]" ;
Reported: DMN 1.1 — Thu, 25 Aug 2016 15:20 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
add comma to grammar rule 56

see revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

Different definition of hit policy collect aggregations in FEEL and DMN

Key: DMN12-175
Status: closed
Source: ACTICO ( Daniel Thanner)
Summary:
On page 83 for DMN: "the result of the decision table is the sum of all the distinct outputs"
On page 137 for FEEL built-in function: "return the sum of the outputs"

Same applies to count aggregation.

Why does a DMN decision table only aggregates distinct values, but a FEEL built-in function does not?

Is this difference between the DMN Decision Table in chapter 8 and the FEEL built-in function in chapter 10 the intended meaning?
Reported: DMN 1.1 — Fri, 26 May 2017 09:28 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
remove 'distinct' from hit policy aggregation definitions

see attached Word document
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- Hit policies collect aggregations (Issue 175) - OMG Proposal (version 1).docx 14 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

clarify format of time literals / resolve inconsistency

Key: DMN12-137
Status: closed
Source: Signavio GmbH ( Dr. Bastian Steinert)
Summary:
page 132/136, in table 58, shows the following example:
time(“T23:59:00z")
The time literal string has a leading 'T'.

Other areas of the spec define time strings as:
"a string value in the lexical space of the time datatype specified by XML Schema Part 2 Datatypes; or a string value that is the extended form of a local time representation as specified by ISO 8601, ..."

As far as I know, XML schema and the ISO standard do not define a leading 'T' for time literals.

Let's clarify this and get all examples consistent.
Reported: DMN 1.1 — Tue, 28 Feb 2017 13:56 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
remove leading 'T' from all time literal examples

remove leading 'T' from all time literal examples
Updated: Wed, 3 Oct 2018 14:17 GMT

decision table structure in 8.1 does not agree with MM

Key: DMN12-148
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Inputs are said to be a set, and each input is said to contain the input entries. But according to the MM, inputs (really input clauses) are a list, and each input does not contain the input entries, but rather implicitly references the input entries in the rules by position. Similar issue for outputs.

Trouble continues in 8.2.1, where it says there is a double line between input/output expressions and the rule entry cells. There are no output expressions. Probably, given that the clauses in the MM do not include the entry cells (those are contained in the rules), we should say the double line is between the clauses and the rules.
Reported: DMN 1.1 — Mon, 20 Mar 2017 05:30 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Align text in Ch 8 with metamodel

see revised text
Updated: Wed, 3 Oct 2018 14:17 GMT

Output Order hit policy on pg 85 is incorrect

Key: DMN12-149
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Compare with priority policy. Correct to

if the associated hitPolicy is OUTPUT ORDER, the value of an instance of DecisionTable is the list of the values of the conclusions of all the applicable rules, according to the ordering of the outputEntry in the list
of output values
Reported: DMN 1.1 — Mon, 20 Mar 2017 23:44 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Remove redundant out of date semantics and point to 10.3.2.8

The 'semantics' in 8.3.1 is redundant with 10.3.2.8. It is also out of date, e.g. there is no 'conclusion' in the metamodel anymore. Let's remove it.
Updated: Wed, 3 Oct 2018 14:17 GMT

Add specification for DMN diagrams layout

Key: DMN12-144
Status: closed
Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
Summary:
Currently the standard contains a specification of the AST. It does not contain a specification for the CS of the diagrams (e.g. (x,y) coordinates of the DRG elements on the screen).

Having such a specification will make the diagrams portable between different tool providers.

One way of doing it is to have an optional (backwards compatibility) section at the end of the DMN document with DRGElement Views that contain the graphical info (e.g. coordinates, color etc) and references by ID to the AST elements (e.g. DRGElements)
Reported: DMN 1.1 — Tue, 14 Mar 2017 09:36 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
Duplicate of ~~DMN12-20~~

~~DMN12-20~~/~~DMN12-62~~ will add Diagram Interchange to DMN.
Updated: Wed, 3 Oct 2018 14:17 GMT

Duplicate definition of BKM/@variable in Table 14

Key: DMN12-138
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)

Summary:

On page 50 (PDF 54) in Table 14 "BusinessKnowledgeModel attributes and model associations" the attribute variable is defined twice:

variable: InformationItem	The instance of InformationItem that is bound to the function. An invocation can reference this variable by name.
variable: InformationItem	This attribute defines a variable that holds the FunctionDefinition, allowing a Decision to invoke it by name.

Reported: DMN 1.1 — Wed, 8 Mar 2017 14:00 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Merge duplicate definitions of BKM/@variable in Table 14

Merge the two descriptions into one.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- Screenshot Table 14.png 97 kB (image/png)

Missign Comma in Grammar Rule 48 (some/every...)

Key: DMN12-127
Status: closed Implementation work Blocked
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
On page 109 (PDF 113) the grammar rule 48 "quantified expression" is missing a comma. It should look similar to rule 46.
Reported: DMN 1.1 — Thu, 26 Jan 2017 13:28 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Add missing comma in grammar rule 48 "quantified expression"

Add "," to grammar rule 48 similar to rule 46.
Updated: Wed, 3 Oct 2018 14:17 GMT

singular helping verb used with plural subject

Key: DMN12-103
Status: closed
Source: IBM Cloud Support ( Tom Scanlan)
Summary:
Last sentence in Scope section uses both "have" and "has" for the same plural subject "authors".

"The authors have brought forth expertise and experience from the existing decision modeling community and has sought
to consolidate the common ideas from these divergent notations into a single standard notation."

--> Correction: change "has" to ""have".
Reported: DMN 1.1 — Wed, 26 Oct 2016 15:19 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
Change 'has' to 'have'

Fix grammar in one sentence
Updated: Wed, 3 Oct 2018 14:17 GMT

Alternative DRD representation of BKM

Key: DMN12-36
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
(raised by Bruce)
By allowing reuse of a value expression, BKMs provide useful semantics. But their representation in DRD adds visual complexity without a lot of value. The Chapter 11 example in the spec is a good example. Representing both the calling decision and the called BKM in the diagram effectively doubles the number of elements in the DRD, while the knowledge requirement connector does not reveal the elements used in the BKM value expression. As an alternative, a distinctive marking in the DRD of a decision invoking a BKM could provide virtually the same information without adding clutter to the diagram. Since DRD is a filtered and truncated view of the DRG, a tool could already do this today, but not in any standardized notation.
Reported: DMN 1.1 — Mon, 9 May 2016 19:22 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
*duplicate *

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

Expressions in Input Entries

Key: DMN12-32
Status: closed
Source: Sapiens Decision NA ( Mr. Gil Ronen)
Summary:
Input Entries are defined as unary tests and as such do not allow even simple expressions. The need to exit the decision table into other FEEL constructs for simple expressions such as “Dividend Income * 0.30” makes the overall logic less readable. There are currently several tools that support expressions in decision table cells and this feature is also on Jan and James’ wishlist. The latter wrote about in more detail (http://blog.luxmagi.com/2016/04/our-dmn-2-0-wish-list-i-decision-logic/) so I won’t repeat it except to quote “This is something we see a lot of demand for by business users of DMN ‘in the field’.”
Reported: DMN 1.1 — Thu, 5 May 2016 13:16 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
duplicate

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

Collection Operators

Key: DMN12-31
Status: closed
Source: Sapiens Decision NA ( Mr. Gil Ronen)
Summary:
Modeling with collections of items are fundamental to much business processing (as was noted in various LinkedIn threads). Simple comparisons such as ‘does A,B contain A’ should be done in decision tables using dedicated operators and not require exiting to FEEL and structures external to the decision tables. Several tools already support these operators. While you can write these expressions in FEEL it is useful that a table segregates each row as a rule so that one row matches "list contains both a and b", the next row matches "list contains c or e", etc. We find these representations of the logic to be both common and easily understood by business folks. The proposal is to add ‘Is In’, ‘Contains’ and ‘Contains Any’ operators and their negation (symbols can be used instead of the full operator textual name).

Attached images show this feature used in a business setting.

Examples below of how these operators work (1st element is the Input Expression result and the 2nd is an Input Entry):
{A,B} Contains A returns True {A,B,C} Contains {A,B}
returns True
{A,B,C} Contains {A,D} returns False
{A,B} Contains Any A returns True{A,B,C}
Contains Any
{A,D}
returns True
{A,B} Contains Any C returns False

A Is In {A,B}
returns True
{A,B} Is In {A,B,C} returns True{A,B}
Is In
{A,C}
returns False
Reported: DMN 1.1 — Thu, 5 May 2016 12:37 GMT
Disposition: Duplicate or Merged — DMN 1.2
Disposition Summary:
duplicate

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

Table 47 should specify duration/duration rather than number/duration

Key: DMN12-24
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Table 47 gives specific semantics of multiplication and division for various types of operands. It gives a row for division of a number by a duration (e.g. 4 divided by 1 hour) which makes little sense. Instead, the case of dividing a duration by a duration (e.g. 1 hour divided by 15 minutes equals 4) should be specified.
Reported: DMN 1.1 — Tue, 1 Mar 2016 06:27 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
change table 47 to remove number/duration and add duration/duration

Apply editing instructions in Revised Text.
Updated: Wed, 3 Oct 2018 14:17 GMT

Missing comma to split “in” in quantified expression in FEEL syntax

Key: DMN12-53
Status: closed Implementation work Blocked
Source: Trisotech ( Mr. Denis Gagne)
Summary:
Rule 48 of Feel expression is as follow:
48. quantified expression = ("some" | "every") , name , "in" , expression ,
{ name , "in" , expression }
, "satisfies" ,expression ;

Without a comma, it is really hard to tell when a new “in” part starts. The for expression, in rule 46, does add a comma to split the various in part:
46. for expression = "for" , name , "in" , expression
{ "," , name , "in" , expression }
, "return" , expression ;

Recommend that Rule 48 should be as follow:
48. quantified expression = ("some" | "every") , name , "in" , expression ,
{“,”, name , "in" , expression }
, "satisfies" , expression ;
Reported: DMN 1.1 — Wed, 15 Jun 2016 19:22 GMT
Disposition: Resolved — DMN 1.2
Disposition Summary:
add comma to grammar rule 48

Apply editing instructions in Revised Text.
Updated: Wed, 3 Oct 2018 14:17 GMT

Wrong DecisionTable class diagram (metamodel)

Key: DMN12-8
Legacy Issue Number: 19844
Status: closed
Source: Anonymous
Summary:
The figure 8.18 is NOT the figure of the DecisionTable class diagram (i.e. metamodel).
This diagram was good into the previous beta versions of DMN specification.
This "wrong" diagram was already used as figure 6.8 on page 32 (Decision class diagram i.e. metamodel).
Reported: DMN 1.0 — Sun, 1 Nov 2015 04:00 GMT
Disposition: Closed; No Change — DMN 1.2
Disposition Summary:
The issue does not exist in the current specification

The MM, now Figure 51, seems fine in OMG formal/2016-06-01
Updated: Wed, 3 Oct 2018 14:17 GMT

DMN XSD 1.0 invalid path

Key: DMN12-22
Status: closed Implementation work Blocked
Source: UNESP Sao Paulo State University Brazil ( Fernando Nogueira)
Summary:
I am developing an application that imports DMN files generated by http://demo.bpmn.io/dmn, in order to get some information about the descision tables.

But, when I try to use the XSD schema to validate the DMN file, I get some errors, for example:

unexpected element (uri:"http://www.omg.org/spec/DMN/20151101/dmn11.xsd", local:"definitions")

Apparently, the path is no longer available. Instead, the OMG site is using http://www.omg.org/spec/DMN/20141115/dmn.xsd
Reported: DMN 1.0 — Wed, 20 Jan 2016 16:26 GMT
Disposition: Closed; No Change — DMN 1.2
Disposition Summary:
this appears to be a tool issue. The spec is correct.

see further details in the issue.
Updated: Wed, 3 Oct 2018 14:17 GMT

Business Knowledge Model can have Information Requirements

Key: DMN12-16
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
FEEL function definitions are defined as lexical closures, which simply means that names in the function body must be in scope, and that scope includes the function parameters and, just like any other decision logic, it includes the information requirements and the knowledge requirements. This is very handy. For example, it allows the logic of a BKM to reference 100 Input Data items by name, without requiring that each invocation pass in 100 parameter bindings.

In order for this to work, the BKM would model 100 Information Requirements on the 100 Input Data items, instead of modeling them as parameters. The boxed invocations would not have 100 rows of repetitive binding information. We must extend the MM and Table 2 to allow a BKM to have information requirements.
Reported: DMN 1.0 — Thu, 23 Jul 2015 23:30 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
No agreement about whether this is a good or bad idea

Defer until we can agree to resolve or close.
Updated: Wed, 3 Oct 2018 14:17 GMT

No item definition for function definition

Key: DMN12-15
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
If a function definition is the value expression of an information item, then that information item should have an item definition that gives the type of the function definition. E.g., the type of a function of two numeric arguments that returns their sum should be something like function(number, number) returns number but we have no way to express such an item definition
Reported: DMN 1.0 — Thu, 6 Aug 2015 22:40 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
needed, but out of time

Should enhance item definition so it can model function types because that is the type of a BKM's logic
Updated: Wed, 3 Oct 2018 14:17 GMT

LiteralExpression and textual expression seem to mean the same thing, need to use the same term

Key: DMN12-17
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
literal expression is used in MM, and textual expression is used in grammar. Let's use 1 consistently, but check that they are really the same concept.
Reported: DMN 1.0 — Thu, 16 Jul 2015 16:30 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
no proposal but possibly still an issue, defer.

Literal expression v. textual expression may be a distinction without a difference.
Updated: Wed, 3 Oct 2018 14:17 GMT

FEEL operators in names

Key: DMN12-42
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
If FEEL variable names can contain spaces, they should not be allowed to contain operator names like and, or, etc. for example the name "make and model" in the Collections of Cars example should not be allowed. It might be possible to determine from the context whether this is a name or an expression of 2names, it's just too hard.
Reported: DMN 1.1 — Sat, 14 May 2016 23:31 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
no simple backward compatible solution was found

perhaps we need to break with backward compatablilty in 2.0
Updated: Wed, 3 Oct 2018 14:17 GMT

Expressions in Input Entries

Key: DMN12-30
Status: closed
Source: Sapiens Decision NA ( Mr. Gil Ronen)
Summary:
Input Entries are defined as unary tests and as such do not allow even simple expressions. The need to exit the decision table into other FEEL constructs for simple expressions such as “Dividend Income * 0.30” makes the overall logic less readable. There are currently several tools that support expressions in decision table cells and this feature is also on Jan and James’ wishlist. The latter wrote about in more detail (http://blog.luxmagi.com/2016/04/our-dmn-2-0-wish-list-i-decision-logic/) so I won’t repeat it except to quote “This is something we see a lot of demand for by business users of DMN ‘in the field’.”
Reported: DMN 1.1 — Thu, 5 May 2016 14:34 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
similar to generalized unary tests

any boolean expression can be a unary test, so while you cannot enter 20 * rate, you can enter ? = 20 * rate. Defer to make ?= implied if no ? in expression.
Updated: Wed, 3 Oct 2018 14:17 GMT

Business Context links go both ways

Key: DMN12-4
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In XSD, business context pointers are duplicated in both directions. E.g. decisionOwner and decisionMaker point to organizationalUnit, which in turns has pointers back the other way. This duplication adds no new information, just potential for internal inconsistency. I suggest omitting one of these directions; the other one is easily extracted from the serialization by XPATH.
Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
cannot change schema for compatibility reasons

reconsider in 2.0?
Updated: Wed, 3 Oct 2018 14:17 GMT

Examples

Key: DMN12-3
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
DMN 1.1 should provide examples of all types of decision model allowed by the standard, both graphically (DRD and decision table, where appropriate) and XML serialization. Currently missing:
1. decision tables with an expression (more than a name) in inputExpression and outputExpression.
2. decision tables with inputEntry or outputEntry referencing a "name" as defined by S-FEEL, i.e. not just a literal.
3. DRD and decision table involving what Vanthienen calls "action subtables". All existing examples are "condition subtables".
4. Serialization of crosstab format tables.
5. Representation of literal values vs names in serialization.
6. Representation of PMML and FEEL in the serialization.
Reported: DMN 1.0 — Sun, 12 Apr 2015 15:39 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
Need comprehensive set of examples, defer.

Perhaps the next task force can extract some examples from some test cases and add them to the spec.
Updated: Wed, 3 Oct 2018 14:17 GMT

BigDecimal is not the only mapping of number to Java

Key: DMN12-2
Status: closed
Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
Summary:
Clause 10.3.2.9 shows FEEL number values as mapped to XML decimal, integer, and double, but the only mapping to Java is to BigDecimal. The appropriate mapping to Java, like the appropriate mapping to XML, depends on the range and intent of the data element. BigDecimal is rarely used for anything but currency. Java int and double are much more likely to be appropriate for most data items. The mapping of number to Java should be just as flexible as the mapping to XML and PMML.
Reported: DMN 1.0 — Wed, 9 Jul 2014 21:23 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
still no proposals in 4 years, defer.

FEEL chose the simplicity of a single numeric type. Possibly some vendors have extensions, but none has volunteered to make a detailed proposal. There are many numeric builtins and operators; a complete proposal would be somewhat tedious.
Updated: Wed, 3 Oct 2018 14:17 GMT

Need group artifact in DRD, metamodel, and XSD

Key: DMN12-13
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Group is an unfilled rectangle enclosing various elements in the DRD, with meaning defined by the modeler. It follows the usage defined by BPMN, an “artifact” with no operational semantics, simply an annotation of the model.
Reported: DMN 1.0 — Thu, 20 Aug 2015 00:13 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
Under discussion but no proposal, defer.

See issue comments.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- bpmn-figure-010.png 36 kB (image/png)
- bpmn-figure-012.png 22 kB (image/png)
- group.jpg 6 kB (image/jpeg)

No notation for ItemDefinition

Key: DMN12-7
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The notion of a 'type' or ItemDefinition is in the metamodel (with some pending issues) and in the semantics and concepts, but little is in the notation. Thus, we have notation that allows you to execute an expression with actual arguments, but no notation to allow validation based on type information without actual values.

We have most of the pieces, so it should not be difficult. E.g., individual values can be number, string, date and time, etc. We can allow numeric ranges using our unary tests, e.g. '>0', '[10..30)', etc. We can allow LOVs using "abc", "def", "ghi". These can be 'simple items', and we can also define structures using something similar to boxed contexts.
Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
no proposal for this missing feature, defer

Still seems useful.
Updated: Wed, 3 Oct 2018 14:17 GMT

italics and bold used for both typographic literal notation and FEEL semantic exposition

Key: DMN12-11
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
in typographic literals, italics are strings and bold italics are date literals, but in 10.3, italics are feel syntactic elements and bold are semantic elements. Better to have different notations
Reported: DMN 1.0 — Thu, 3 Sep 2015 15:58 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
editorial only, can defer

we should identify some typographical conventions and use them consistently.
Updated: Wed, 3 Oct 2018 14:17 GMT

ranges do not map to the semantic domain

Key: DMN12-260
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
section 10.3.2.7 Ranges says that ranges map to the semantic domain. But in DMN 1.1, ranges are unary tests and as such, do not map to the semantic domain. Also, the literal context shown is wrong, as you cannot have the entry 'soon' with value of a range (such value would have to map to the semantic domain).
Now, in DMN 1.2, perhaps we would like to map unary tests to the semantic domain, but it must be all unary tests, and not only ranges.

Proposed remove section 10.3.2.7
Reported: DMN 1.1 — Fri, 6 Apr 2018 17:36 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
defer for better spec of unary test semantics

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

XSD: global context

Key: DMN12-19
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
10.3.2.9.2 says "The global context is a context provided for convenience and 'pre-compilation'. Any number of expressions can be named and represented in a FEEL context m. The syntactic description m of this context can be evaluated once, that is, mapped to the FEEL domain as m, and then re-used to evaluate many expressions." For example, you might want to put a Relation used as a multi-dimensional constant in the global context. Or you might want to put a reusable function definition in the global context. Currently the xsd does not have globals. All expressions are bound to a specific drgElement, not global. The Import element probably needs to be modified to support this also.
Reported: DMN 1.0 — Sun, 31 May 2015 16:35 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
did not write proposal to remove global context, defer.

Probably global context can/should be removed, but we did not work out the details.
Updated: Wed, 3 Oct 2018 14:17 GMT

Enhancement suggestion: allow for expressions to be used as "end points"

Key: DMN12-80
Status: closed
Source: Red Hat Inc ( Edson Tirelli)
Summary:
This is a suggestion for future revisions of the specification:

Change the grammar to allow expressions to be used as "end points" on ranges and unary tests. E.g.:
{ Thanksgiving holiday: [ date(“2016-11-24”) .. date(“2016-11-27”) ] }
This is extremely useful for users that no longer have to create dummy variables in order to use expressions as "end points".
Reported: DMN 1.1 — Tue, 23 Aug 2016 01:32 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
closed by submitter

relevant but out of time
Updated: Wed, 3 Oct 2018 14:17 GMT

Include Test Cases in Decision Model

Key: DMN12-49
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
For interchange of test cases along with a decision model, it would be convenient to define metamodel and xsd elements for a suite of test cases, where a test case contains values for input data and expected values output decisions.
Reported: DMN 1.1 — Sat, 28 May 2016 16:25 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
Defer new features without complete proposals due to lack of time

May be more appropriate for DMN 2.0.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- testCases.xsd 3 kB (text/xml)

Change depiction of Input to be harmonized with BPMN and CMMN

Key: DMN12-44
Status: closed
Source: Trisotech ( Mr. Denis Gagne)
Summary:
As OMG promotes the integrated use of DMN with BPMN and CMMN, it is proposed to change the depiction of Input in DMN to be the paper Shape with folded corner. We can envision end users wanting to embed DMN diagrams into BPMN or CMMN diagrams. This change would provide better notational alignment with Data Object and Case File Iems in BPMN and CMMN. Futhermore is would remove the notation conflict currently existing between DMN Input and CMMN Milestone.
Reported: DMN 1.1 — Mon, 16 May 2016 14:26 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
Do Nothing

Reconsider after more experience (defer).

The Input Data object is not the same as the Data Object in BPMN and there is already a shared underlying information model. Most importantly there is no concept of a Data Output object in DMN. Information does not flow into Input Data objects in DMN and Data Objects in BPMN might be instantiated from Decisions in DMN.

There is no particular need in BPMN / DMN to model Data Objects and Input Data at the same level. A process might consider a Claim a useful Data Object while decision models might find using a single Claim object overwhelming and represent the Claim information with multiple Input Data.
Updated: Wed, 3 Oct 2018 14:17 GMT
Attachments:
- BPMN Data Object DMN Data Input.PNG 86 kB ()
- CaseFileItem.png 0.9 kB (image/png)
- Depiction of Input Data conflict with BPMN and CMMN.png 239 kB (image/png)
- Milestone.png 2 kB (image/png)
- bpmn-figure-087.Data Object Reference.png 0.9 kB (image/png)
- bpmn-figure-088.Data Object Reference Collection.png 0.9 kB (image/png)
- bpmn-figure-089.Data Input.png 1 kB (image/png)
- bpmn-figure-090.Data Input Collection.png 1 kB (image/png)
- bpmn-figure-091.Data Output.png 1 kB (image/png)
- bpmn-figure-092.Data Output Collection.png 1 kB (image/png)

Decisions can be used for many things, do we need a taxonomy?

Key: DMN12-25
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Decisions in DMN are actually expressions in a formal language (by default, FEEL). These expressions describe a range of computations and calculations, including constants like 42, calculations like (x-y)/2, and decisions using decision tables. It's awkward referring to constants and math formulas as 'decisions', but most of the time, decision is the right word. Should we allow some 'decoration' of the decision rectangle (e.g. an icon) to indicate whether it is a constant, a calculation, a decision, etc.?

Another observation - InputData and BKM are not really needed to build a working DMN product. Decisions can be used instead of InputData. All your decision services would use input decisions instead of input data. Decisions can be used instead of BKMs, as there is no prohibition about a decision's logic being a FunctionDefinition. This means that decisions can invoke other decisions or simply reference them. Either way, there is an information requirement.
Reported: DMN 1.1 — Mon, 11 Apr 2016 19:42 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
no concrete proposal, defer

no concrete proposal, defer
Updated: Wed, 3 Oct 2018 14:17 GMT

Enhancement suggestion: make unary tests first class citizens of the FEEL language

Key: DMN12-81
Status: closed
Source: Red Hat Inc ( Edson Tirelli)
Summary:
This is a suggestion for future versions of the spec:

Add support for Unary Tests as first class citizens of the FEEL language, in a similar way as ranges and functions already are.

A unary test is really a “predicate”: a single parameter function that returns a boolean. It is syntax sugar on:

function ( x ) x in <unary_test>

FEEL already supports functions as first class citizens, so it makes sense to support Unary Tests. The following two syntaxes would then be equivalent:

is minor : < 18
is minor : function( age ) age in < 18

Invoking unary tests explicitly would be like invoking a function:

Bob is minor : is minor( bob.age )

More importantly, it would allow the implementation to actually support passing unary tests as parameters to functions and make the example on page 115 viable:

decision table (
outputs: "Applicant Risk Rating",
input expression list: [Applicant Age, Medical History],
rule list: [
[ >60, "good", "Medium" ],
[ >60, "bad", "High" ],
[ [25..60], -, "Medium" ],
[ <25, "good", "Low" ],
[ <25, "bad", "Medium" ]
],
hit policy: "Unique"
)

Unary test syntax is not ambiguous, so supporting it would mean to basically change rule 2 in the grammar to include rules 14 and 17 as possible options. The semantic mapping table on page 116 would also need to include a new FEEL value type: "unary test".
Reported: DMN 1.1 — Tue, 23 Aug 2016 01:41 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
withdrawn by submitter

other issues have addressed key points, no longer relevent
Updated: Wed, 3 Oct 2018 14:17 GMT

DMN v1.2 specification

Key: DMN12-77
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
Using this "issue" as a place to post new versions of the spec as we close each ballot. The track changes will be cumulative but comments will map changes to issue numbers. Also posting meta-model files.
Reported: DMN 1.1 — Tue, 23 Aug 2016 10:47 GMT
Disposition: Deferred — DMN 1.2
Disposition Summary:
This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force
Updated: Tue, 4 Sep 2018 11:34 GMT
Attachments:
- Class_Diagram__DMN__BKM.svg 199 kB (image/svg+xml)
- Class_Diagram__DMN__BusinessContext.svg 168 kB (image/svg+xml)
- Class_Diagram__DMN__DMNElement.svg 314 kB (image/svg+xml)
- Class_Diagram__DMN__Decision.svg 446 kB (image/svg+xml)
- Class_Diagram__DMN__DecisionTable.svg 492 kB (image/svg+xml)
- Class_Diagram__DMN__Definitions.svg 366 kB (image/svg+xml)
- Class_Diagram__DMN__Expressions.svg 326 kB (image/svg+xml)
- Class_Diagram__DMN__ExpressionsL3.svg 214 kB (image/svg+xml)
- Class_Diagram__DMN__Extensibility.svg 97 kB (image/svg+xml)
- Class_Diagram__DMN__InputData.svg 62 kB (image/svg+xml)
- Class_Diagram__DMN__KnowledgeSource.svg 194 kB (image/svg+xml)
- Class_Diagram__DecisionService.svg 115 kB (image/svg+xml)
- DC.xsd 6 kB (text/xml)
- DI.xsd 5 kB (text/xml)
- DMN 1.2_ballot10 clean 70.pdf 5.82 MB (application/pdf)
- DMN 1.2_ballot10 markup 70.pdf 6.17 MB (application/pdf)
- DMN 1.2_ballot11 clean 70.pdf 5.87 MB (application/pdf)
- DMN 1.2_ballot11 markup 70.pdf 6.43 MB (application/pdf)
- DMN 1.2_ballot12 clean 70.pdf 5.87 MB (application/pdf)
- DMN 1.2_ballot12 markup 70.pdf 6.44 MB (application/pdf)
- DMN 1.2_ballot13 clean 70.pdf 5.94 MB (application/pdf)
- DMN 1.2_ballot13 markup 70.pdf 6.53 MB (application/pdf)
- DMN 1.2_ballot15 clean 70.pdf 6.30 MB (application/pdf)
- DMN 1.2_ballot15 markup 70.pdf 7.11 MB (application/pdf)
- DMN 1.2_ballot18 clean.pdf 6.38 MB (application/pdf)
- DMN 1.2_ballot18 markup.pdf 7.21 MB (application/pdf)
- DMN 1.2_ballot19 clean.pdf 6.50 MB (application/pdf)
- DMN 1.2_ballot19 markup.pdf 7.60 MB (application/pdf)
- DMN 1.2_ballot2.pdf 5.65 MB (application/pdf)
- DMN 1.2_ballot20 clean.pdf 6.49 MB (application/pdf)
- DMN 1.2_ballot20 markup.pdf 7.42 MB (application/pdf)
- DMN 1.2_ballot3.pdf 5.72 MB (application/pdf)
- DMN 1.2_ballot4.pdf 5.78 MB (application/pdf)
- DMN 1.2_ballot5.pdf 5.89 MB (application/pdf)
- DMN 1.2_ballot6.pdf 5.91 MB (application/pdf)
- DMN 1.2_ballot7 clean 70.pdf 5.72 MB (application/pdf)
- DMN 1.2_ballot7 markup 70.pdf 6.05 MB (application/pdf)
- DMN 1.2_ballot8 clean 70.pdf 5.73 MB (application/pdf)
- DMN 1.2_ballot8 markup 70.pdf 6.06 MB (application/pdf)
- DMN 1.2_ballot9 clean 70.pdf 5.74 MB (application/pdf)
- DMN 1.2_ballot9 markup 70.pdf 6.08 MB (application/pdf)
- DMN 1.2_draft v1 clean.pdf 6.31 MB (application/pdf)
- DMN 1.2_draft v1 markup.pdf 7.40 MB (application/pdf)
- DMN 1.2_draft v2 clean.pdf 6.74 MB (application/pdf)
- DMN 1.2_draft v2 markup.pdf 7.84 MB (application/pdf)
- DMN 1.2_draft v2.odt 7.71 MB (application/vnd.oasis.opendocument.text)
- DMN 1.2_draft v3 clean.pdf 6.85 MB (application/pdf)
- DMN 1.2_draft v3 markup.pdf 7.93 MB (application/pdf)
- DMN 1.2_draft v3.odt 7.72 MB (application/vnd.oasis.opendocument.text)
- DMN 1.2_draft v4 clean.pdf 6.49 MB (application/pdf)
- DMN 1.2_draft v4 markup.pdf 7.81 MB (application/pdf)
- DMN 1.2_draft v4.odt 7.73 MB (application/vnd.oasis.opendocument.text)
- DMN 1.2_draft v5 clean.pdf 6.48 MB (application/pdf)
- DMN 1.2_draft v5 markup.pdf 7.82 MB (application/pdf)
- DMN 1.2_draft v5.odt 7.73 MB (application/vnd.oasis.opendocument.text)
- DMN 1.2_draft v6 clean.pdf 6.48 MB (application/pdf)
- DMN 1.2_draft v6 markup.pdf 7.41 MB (application/pdf)
- DMN 1.2_draft v6.odt 7.73 MB (application/vnd.oasis.opendocument.text)
- DMN 1.2_draft v7 clean.pdf 6.96 MB (application/pdf)
- DMN 1.2_draft v7 markup.pdf 7.81 MB (application/pdf)
- DMN 1.2_draft v8 clean.pdf 6.51 MB (application/pdf)
- DMN 1.2_draft v8 markup.pdf 7.73 MB (application/pdf)
- DMN12.xsd 22 kB (text/xml)
- DMN12_MagicDraw.mdzip 288 kB ()
- DMNDI.xsd 4 kB (text/xml)
- DMNDI12.xmi 33 kB ()
- DMNDI12_MagicDraw.mdzip 96 kB ()
- DMNDI12_MagicDraw.xmi 262 kB ()
- Figures - Chapter 11 - Diagrams.zip 60 kB (application/zip)
- class__DMN_DI.png 6 kB (image/png)
- class__DMN_DI.svg 42 kB (image/svg+xml)
- class__DMN_Diagram.png 22 kB (image/png)
- class__DMN_Diagram.svg 154 kB (image/svg+xml)
- class__DMN_Diagram_Element.png 16 kB (image/png)
- class__DMN_Diagram_Element.svg 94 kB (image/svg+xml)
- class__DMN_Edge.png 12 kB (image/png)
- class__DMN_Edge.svg 70 kB (image/svg+xml)
- class__DMN_Label.png 9 kB (image/png)
- class__DMN_Label.svg 63 kB (image/svg+xml)
- class__DMN_Shape.png 22 kB (image/png)
- class__DMN_Shape.svg 156 kB (image/svg+xml)
- class__DMN_Style.png 23 kB (image/png)
- class__DMN_Style.svg 217 kB (image/svg+xml)
- examples.zip 790 kB (application/zip)

extra level of indirection in decision table serialization is undesirable

Key: DMN11-81
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The input and output entries in a decision table are expressions. The expressions are serialized as part of the rule 'clause', with an ID. In the rules, the expressions are represented by IDREF. This level of indirection is undesirable for many reasons:
1. the expressions are small text strings, typically no bigger than an ID
2. copy/paste of rules across decision tables won't work (IDs are different)
3. diff of decision tables is complicated, due to indirection
4. there is no level of indirection in the notation - the rules appear to contain the expressions, not a reference to them.
5. complicates JSON serialization
Proposed: In Figure 44, move Expression ownership from Clause to DecisionRule, and follow logical implications in text and xsd.
Reported: DMN 1.0 — Thu, 25 Jun 2015 06:23 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
remove indirection, split Expression into LiteralExpression and UnaryTests

DecisionRules are ordered in a DecisionTable. By also ordering the inputs and the outputs (requires splitting Clause into InputClause and OutputClause, we can move the inputEntries and outputEntries under DecisionRule and avoid all IDREFs within a decision table, significantly simplifying serialization. Also, we combine a proposal for ~~DMN11-84~~, which is merged with this issue.
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig44Prop83.PNG 85 kB ()

Define decision service

Key: DMN11-45
Legacy Issue Number: 19754
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
Allow DMN to specify and interchange definitions of decision services, along the lines proposed in Annex B.
Reported: DMN 1.0 — Tue, 28 Apr 2015 04:00 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Definition, notation and examples for Decision Service

Complete proposal in the attached document
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Decision Services proposal v5.docx 409 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Fig15Prop143.PNG 71 kB ()
- Fig16Prop143.PNG 56 kB ()

DecisionService has no defined execution semantics, and decision model semantics in 10.4 is hard to understand

Key: DMN11-176
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Now that we have decision services, this is a much better and simpler feature for which to define execution semantics. We can simplify and improve the usefulness of 10.4.
Reported: DMN 1.0 — Fri, 30 Oct 2015 16:20 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
replace 10.4 with Execution Semantics of Decision Services

This proposal depends on adoption of ~~DMN11-143~~. I think we should specify the execution semantics of decision services. This can replace 10.4, which is the execution semantics of DRGs, which is problematic because the InputData doesn't have much meaning except as the parameter of a decision service. No MM or XSD changes.
Updated: Tue, 29 Mar 2016 15:07 GMT

use refs in XSD only to substitution groups

Key: DMN11-164
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
use <element name=xx, type=tYY/> instead of <element ref=zz/>
This will more consistently name subelements as MM attributed names, not as MM class names. This is a stylistic issue only.
Reported: DMN 1.0 — Tue, 27 Oct 2015 17:21 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Consistently use MM names in XSD

Change XSD to use attribute names as defined in meta model aggregations.
Remove references to global elements where no polymorphism is needed.

In particular the changes are:

1. remove unneeded global elements and refs
2. Revert back to ref="Import" due to polymorphism with ImportedValues
3. Remove unused element text
4. Use attribute names from meta model
5. Consistently prefix type names with t
(This is only XSD cosmetics and does not affect the actual element names in instance documents)
6. Consistently name elements with MM class name with lower-case first letter
(This last change might be a little controversial, as it affects many element names. However, the previous changes result in a mixture of upper and lower case element name, which certainly will be confusing for tool vendors. Especially, since we see in the OMG BPMN Model Interchange Working Group, that many tool vendors are not performing schema validations, we might end up with subtle differences in import/export that prevent interchange. Also when developing tools to analyse or transform DMN files using XSLT or XPath, predictable element names will safe a lot of hassle.)
7. imported values can only be used in literal expression.
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- AllExpressions.png 62 kB (image/png)
- BusinessContext.png 50 kB (image/png)
- BusinessKnowledgeModel.png 51 kB (image/png)
- Decision.png 109 kB (image/png)
- DecitionTable.png 104 kB (image/png)
- Definitions.png 56 kB (image/png)
- Expression.png 100 kB (image/png)
- InputData.png 28 kB (image/png)
- KnowledgeSource.png 48 kB (image/png)

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

Key: DMN11-155
Status: closed
Source: Camunda Services GmbH ( Mr. Falko Menge)
Summary:
DMN nees to provide a standard way for vendors to serialize extensions (Vendor Extensions). It is proposed that a schema resembling what was done in BPMN and CMMN be used.

Why DMN should be extensible

The extension mechanism allows adding Custom Metadata to models in a way that it MAY be interchanged between vendors. Concretely this means that it is possible to add custom attributes and elements in a custom namespace to the XML interchange format.

Example of a custom attribute
<DecisionTable id="table1" custom:audit="true" xmlns:custom="http://custom.org/auditing" ...>
Example of a custom element
<DecisionTable id="table1" ...> ... <extensionElements> <custom:audit xmlns:custom="http://custom.org/auditing"> <custom:audit-level>full</custom:audit-level> <custom:retention>unlimited</custom:retention-level> </custom:audit> </extensionElements> ... </DecisionTable ...>
Vendors need to be able to add custom Metadata

Vendors need to be able to decorate the model with additional metadata. Vendors may implement additional usecases which the standard as such does not address like historization, reporting, fine-grained editing authorizations amd restrictions, ...
Having the possibility to put this directly into the interchange format allows vendors to roundtrip models. If all vendors participating in the roundtrip re-export the other vendor's extensions than they are not lost during roundtrip which leads to a better inter-operatbility experience for the user.

Users need to be able to add custom Metadata

The possibility to extend the model with custom metadata has also proven to be vital to camunda users and customers in the past.
Many users extend the model with their custom attributes and elements to be able to implement custom extensions.
Some have custom metadata for their execution environment others for auditing and reporting.
It is very important at users are able to put custom metadata into the xml file.

FAQ

Is BPMN's extension mechanism perfect?

Probably not. At the XML level it works extremely well. At the Meta Model level it could certainly be improved.
But the question is whether the practical advantages of a "slightly better approach" would outweigh the advantages of consistency among these standards.

Does that mean that Vendors can just ignore the Standard?

No. In order to be compliant, vendors need to implement the standard in the way mandated by the standard.
If they use custom extensions for realizing non-compliant behavior then they are non-compliant.

Do tools need to understand the extensions created by other vendors?

No. Tools do not need to understand extensions created by other vendors. What's more, the specification text explicitly states that tools do not event need to round-trip extension elements by other vendors while still being compliant. There is also no compliance level at which a tool is required to support this. A tool is fully compliant if it is not able to round-trip extension elements.

Has this actually been successful in BPMN?

Yes. Extension mechanisms are heavily used and there is ample empiric evidence of this being a successful concept. To see it in action have a look at the demos and test cases of the BPMN Model Interchange Working Group (MIWG) at the OMG.

For comparison see also the CMMN 1.1 proposal ~~CR-20~~.
Reported: DMN 1.0 — Thu, 22 Oct 2015 13:33 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Add new extension capability to DMN as per that of BPMN and CMMN

Based on the extension capabilities of BPMN and CMMN the following changes need to be done:
1. Add two rows to table 3
2. Add a new figure of the metamodel showing the relation between DMNElement and the extension mechanism in section 6.3
3. Figure 15 - DMNElement class diagram needs to be updated with ExtensionElements and ExtensionAttribute depiction.
4. A complete new section 6.3.14 Extensibility needs to be added. This will have a ripple effect on table and figure numbering. Figure of the metamodel should be inserted after the first paragraph of section 6.3.14, in the metamodel we need to add the two classes described
5. Some changes needed to DMN.xsd, which already contains this mechanism
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig15_DMNElement.PNG 77 kB ()
- Prop156_Extensibility.PNG 18 kB ()

DMN XSD, MM, Attribute/Association Tables, and spec text are not consistent

Key: DMN11-146
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
XSD must use names derived in a consistent way from MM names. XSD types should be used everywhere. Spec text descriptions must agree in name and concept with the MM. XSD must use containment and references in the same way as the MM. For example, ~~DMN11-81~~ removes references and uses containment for the entries in a DT. But XSD still has lingering ID/IDREFs that must be removed and aligned with current MM.
Reported: DMN 1.0 — Thu, 8 Oct 2015 16:10 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Align XSD, MM and spec text as described

Make following changes to XSD:
1. Relation.column in XSD should have type tInformationItem, not tContextEntry
2. Invocation.calledFunction is missing in the XSD
3. KnowledgeSource.type: change anyType to string
4. tInvocation/@calledFunction is of type="xsd:string", but in MM it aggregates an Expression => Change XSD to reference abstract element Expression.

Make following changes to MM:
1. MM ImportedValues does not contain importedElement, but XSD does. Add attribute to MM
2. Collapse the classes that are not essential in each diagram, e.g. DMNElement and NamedElement should show attributes only in the DMN Element diagram
3. Use xsd types (instead of String) for ID, anyURI, QName
4. rename OrganisationalUnit into OrganizationUnit in MM and spec text.
5. name association from Decision to InformationRequirement "informationRequirement"
6. add attribute importedElement : String[1] to ImportedValues in MM
7. remove attribute "name" from InformationItem in MM
8. Make NamedElement abstract in MM and XSD
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Class_Diagram__DMN__BKM.svg 173 kB (image/svg+xml)
- Class_Diagram__DMN__BusinessContext.svg 168 kB (image/svg+xml)
- Class_Diagram__DMN__DMNElement.svg 307 kB (image/svg+xml)
- Class_Diagram__DMN__Decision.svg 453 kB (image/svg+xml)
- Class_Diagram__DMN__DecisionTable.svg 415 kB (image/svg+xml)
- Class_Diagram__DMN__Definitions.svg 433 kB (image/svg+xml)
- Class_Diagram__DMN__Expressions.svg 317 kB (image/svg+xml)
- Class_Diagram__DMN__ExpressionsL3.svg 187 kB (image/svg+xml)
- Class_Diagram__DMN__Extensibility.svg 97 kB (image/svg+xml)
- Class_Diagram__DMN__InputData.svg 62 kB (image/svg+xml)
- Class_Diagram__DMN__KnowledgeSource.svg 162 kB (image/svg+xml)

8.3.3. still speaks of condition and conclusion - supposedly removed by DMN11-81

Key: DMN11-145
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Need to reword to use new MM associations
Reported: DMN 1.0 — Thu, 8 Oct 2015 15:59 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
spec text update to decision rule MM in 8.3.3

This issue describes the changes to Decision Rule meta-model from referencing conditions and conclusions to embedding them.
Updated: Tue, 29 Mar 2016 15:07 GMT

DMN 1.1 Beta documents

Key: DMN11-122
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
We are required to vote on the beta 1.1 documents, submitted with this report. See "Deliverables" section of this report.
Reported: DMN 1.0 — Thu, 27 Aug 2015 00:16 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
submit attached beta documents to OMG

OMG requires a vote on beta documents.
Updated: Tue, 29 Mar 2016 15:07 GMT

Reference to BMM::Objective, BPMN::Process and BPMN::Task in XMI

Key: DMN11-12
Status: closed
Source: International Business Machines ( Mr. Christian De Sainte Marie)
Summary:
The reference to classes BMM::Objective, BPMN::Process and BPMN::Task does not seem to work in the metamodel XMI file
Reported: DMN 1.0 — Tue, 29 Jul 2014 12:51 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
unable to find more information about this issue

Did not hear back from Pete and nobody on RTF is an XMI expert. Not even sure if this still applies.
Updated: Tue, 29 Mar 2016 15:07 GMT

dmn.xsd and dmn3.xsd should be merged and list of machine readable files corrected

Key: DMN11-91
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
issue 60 has identified 2 critical but easy to fix problems with the beta2 xsds. An even simpler fix is to combine the 2 xsds. Separate xsds invites the problems, and it has been reported that popular XML tools don't like the 2 xsds because it is the included xsd that has the document root. Also, ~~DMN11-89~~ proposes to use FunctionDefinition (now in dmn3) to consistently serialize all BKM logic.
Reported: DMN 1.0 — Mon, 6 Jul 2015 20:55 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Merge contents of dmn3.xsd into dmn.xsd

Merge contents of dmn3.xsd into dmn.xsd and delete dmn3.xsd.
Updated: Tue, 29 Mar 2016 15:07 GMT

Remove parameters from BKM MM - these belong at logic level

Key: DMN11-89
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The BKM MM defines parameters but has no notation for them. Meanwhile, the FunctionDefinition also defines parameters that duplicate the BKMs. Also, 10.2.1.7 says a BKM's logic must be a FunctionDefinition or a DT, but Table 11 syas a BKM's logic msut be the BODY of the function it defines. To straighten out thsi mess, I propose
1. remove params from BKM MM
2. require BKM to contain a FunctionDefiniition, so that the params will always be defined, and always at the decision logic level
3. allow FunctionDefinition whose body is a DT with simple inputExpressions that reference all parameters, and only parameters, in order, to be denoted using the DT only
Reported: DMN 1.0 — Thu, 2 Jul 2015 18:48 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
BKM value expression is a function definition

change BKM metamodel and XSD to associate BKM to FunctionDefinition instead of separate parameters and body
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig19Prop104.PNG 58 kB ()

'In DMN 1.0' now not only tedious but wrong

Key: DMN11-64
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
There are many occurrences of the phrase 'In DMN 1.0'. Now that we are writing DMN 1.1, this phrase is no longer simply tedious and redundant, but now it is also wrong. All occurrences should simply be deleted. And, all occurrences of 'In DMN' should be deleted. They are redundant. This is the DMN specification! Everything described is by default 'in DMN'!
Reported: DMN 1.0 — Thu, 4 Jun 2015 05:18 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Remove superfluous refs to DMN and all refs to DMN 1.0

Remove all unnecessary use of "In DMN..."
All remaining refs to DMN 1.0 shoul dbe updated to 1.1
Updated: Tue, 29 Mar 2016 15:07 GMT

Add association connector (artifact) with text label to represent conditional decision

Key: DMN11-47
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In the chapter 11 example, Fig 63 contains an information requirement connector linking Adjudication to Routing. But in reality Routing is not an input to Adjudication. What is meant is that Adjudication is only performed if Routing has certain output value. That relationship is what Vanthienen calls an action subtable, whereas information requirement reflects a condition subtable relationship. Still it is useful to depict such relationships in DRD. I suggest adding a new connector type, association - an artifact as meant by BPMN, i.e. no operational semantics just annotation - to reflect it. A text label could indicate a particular output value that enables the dependent decision.
Reported: DMN 1.0 — Tue, 28 Apr 2015 21:20 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
Close - no change required

Consensus is not to add new type of information requirement connector.
Updated: Tue, 29 Mar 2016 15:07 GMT

Need for annotations and comments in DRD

Key: DMN11-99
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
DRD lacks elements to hold modeler-provided annotation in the diagram. These help clarify the meaning of the decision model but otherwise have no operational semantics. In BPMN they are called "artifacts".
Reported: DMN 1.0 — Thu, 16 Jul 2015 20:39 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Add artifacts textAnnotation and association (connector) to DRD, metamodel, and xsd

See comments on ~~DMN11-42~~. The proposed annotation elements are essentially copied from BPMN 2.0.

XSD changes:
https://github.com/omg-dmn-taskforce/omg-dmn-spec/commit/489a726acb94837ef9b926c199f31e86e5a71ceb
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig15Prop100.PNG 80 kB ()
- Fig16Prop100.PNG 83 kB ()
- association.jpg 2 kB (image/jpeg)
- bpmn-figure-010.png 36 kB (image/png)
- bpmn-figure-011.png 17 kB (image/png)
- textannotation.jpg 1 kB (image/jpeg)

Need to clarify which DMNElements must and must not have names

Key: DMN11-92
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
In the MM, Fig 15, all classes inherit the optional name attribute. Thus, any DMNElement may or may not have a name. What is closer to the truth, is that some DMNElements MUST have a name, and others MUST NOT. Attached is proposed MM that splits the elements into the named and unnamed. There will be numerous text changes, especially to explain that decision tables, being expressions, do not have names. The apparent 'names' of expressions like DTs are really the name of the Information Item that has said expression as its valueExpression. It is dangerous (misleading) to supply a name for an expression, because it may appear that one could refer to the named expression's value by that name. But you cannot. You can only refer to an Information Item by name in an expression.
Reported: DMN 1.0 — Tue, 7 Jul 2015 20:01 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
define NamedElement subclass of DMNElement

Revised text, MM figures, and XSD (github links)
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig15Prop105.PNG 54 kB ()
- Fig16Prop105.PNG 50 kB ()
- Fig17Prop105.PNG 115 kB ()
- Fig18Prop105.PNG 41 kB ()
- Fig19Prop105.PNG 59 kB ()
- Fig20Prop105.PNG 27 kB ()
- Fig26Prop105.PNG 89 kB ()
- Fig60Prop105.PNG 48 kB ()

XSD: modify Import in tLiteralExpression

Key: DMN11-73
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In XSD, top-level element Import is used to make top-level elements in external DMN, XSD, and possibly other types of files visible to the decision model. Import also is part of tLiteralExpression as a way to import value expressions, but it needs additional information. Propose to give this element a different name and type:
In tLiteralExpression, replace Import with importedValues, type tImportedValues. Add tImportedValues as follows:
<xsd:complexType name="tImportedValues">
<xsd:complexContent>
<xsd:extension base="tImport">
<xsd:sequence>
<xsd:element name="importedElement">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="expressionLanguage" type="xsd:anyURI"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Reported: DMN 1.0 — Thu, 11 Jun 2015 18:20 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
replace Import in tLiteralExpression with importedValues, new type

Revise spec, MM Fig 26, and XSD as directed.
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig26Prop74.PNG 93 kB ()

inputVariable and itemDefinition are redundant in Expression metamodel

Key: DMN11-69
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
These are redundant. InputVariable is a pointer to a variable definition, but any expression MUST only reference a variable with unique name in scope, so the pointer is redundant. An expression referencing a name not defined uniquely in scope is an error.

Similarly, in tExpression, itemDefinition (a pointer to ItemDefinition representing the expression's output datatype) is redundant. The Decision or BKM element also has OutputDefinition, pointer to ItemDefinition that defines the datatype of the output expression. Any variable referenced by an any literal expression also already has a datatype defined by InformationItem.
Reported: DMN 1.0 — Thu, 11 Jun 2015 17:42 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
move inputVariable and itemDefinition from Expression metamodel to InputData and Decision (and correct XSD and explanatory text)

Revise spec, MM, and XSD as indicated.
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig17Prop72.PNG 118 kB ()
- Fig26Prop72.PNG 90 kB ()
- Fig44Prop72.PNG 84 kB ()
- Fig60Prop72.PNG 49 kB ()

Decision table default output

Key: DMN11-58
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
This issue also relates to isComplete.
Level 3 decision tables may specify a default output entry to be selected if no rules match. I dont believe this is allowed for level 2. In any case, the default output entry is missing from both boxed expression and xsd for decision table, possibly missing from metamodel also.
Reported: DMN 1.0 — Sun, 17 May 2015 16:14 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Add decision table default output

Add attribute defaultOutputEntry of type tLiteralExpression
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig44Prop114.PNG 83 kB ()

XSD itemDefinition/typeRef and typeDefinition are underspecified and incorrect

Key: DMN11-54
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
itemDefinition is referenced to a base type defined by either a typeDefinition or typeRef. 7.3.2 says typeDefinition is "a String that defines the data structure", but it simply names a built-in type, does not define a structure. It also says typeRef is "a String that references a built-in data type... or a data structure defined at the top level in an external document", but those statements are incorrect as well. Built-in types are named by typeDefinition, typeRef is not String. Structured types are defined by itemComponent and referenced by typeRef, usually NOT in an external document. So this text is completely wrong. This issue also affects how external references are defined, via namespace prefix or filename, via ID or element name. Referenced typed by DMNElementReference are ambiguous and inadequate to cover the range of external references required.
Reported: DMN 1.0 — Fri, 15 May 2015 16:23 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
simplify and correct MM and XSD for ItemDefinition

Proposal is to Merge and close ~~DMN11-25~~, 56, 57, 71.

The latest MM diagram (attached) shows ItemDefinition containing itemComponents, which are also tItemDefinition. It also shows ItemDefinition has attribute typeRef and typeDefinition. It is better to have a consistent referencing scheme via typeRef, so typeDefinition should be removed from the MM. Otherwise, the MM is correct, but the XSD is not consistent with this.

The corrected XSD deletes tItemComponent and defines itemComponent as tItemDefinition. This makes ItemComponent recursive, which resolves and closes ~~DMN11-56~~ and ~~DMN11-71~~.

Also, to make ItemDefinition consistent with ~~DMN11-67~~, allowedValue is renamed allowedValues, type tUnaryTests, maxOccurs=1.

It is important that types be referenced consistently via typeRef or itemDefinition, whether the type is:

(1) a base type (without restriction) in the ItemDefinition's typeLanguage; (2) a custom type (including base types with allowed values) defined in the current Definitions; (3) a custom type defined in an imported DMN model; or (4) a type defined in an imported XSD (or WSDL or other type language). Normally types have names unique in their namespace, and outside of DMN they do not have ids. Therefore tDMNElementReference, a pointer to id, will not work; the best way to reference types is by standard QName. This also resolves 11-25, since now Definitions/@namespace has a purpose.

A base type in the specified typeLanguage should not require ItemDefinition, nor should an imported type. ItemDefinition is required only for custom types defined in the current document.

QName is namespace-prefixed pointer to either ItemDefinition/@name (or, for imported XSD type, to xsd:simpleType/@name or xsd:complexType/@name). The prefix must be declared in DMN via xsd:schema/@xmlns:[prefix]="[namespace URI]". This means references to FEEL base types must use prefix for the FEEL namespace, just as references to XSD base types must use prefix for the XSD namespace. For imported DMN documents, the prefix must reference the Definitions/@namespace attribute of the import.
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig26Prop115.png 93 kB (image/png)

XSD; modify tItemDefinition by changing tItemComponent

Key: DMN11-56
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
ItemDefinition defines the datatype of each variable used in DMN expression. As currently defined, it "works" for FEEL base types, although inefficiently (since it has both @name and typeDefinition, two strings that both name the type). It "sort of works" for imported XSD complex types, as long as you ensure the FEEL elements have valid XML element names (e.g. no spaces, etc.) In that case ItemDefinition/@name names the FEEL type and typeRef is a QName pointer to complexType defined in imported XSD. In the general case, for FEEL complex types defined inside the DMN model, it doesn't work very well.

It is clumsy for defining data structures more than 2 levels deep. ItemDefinition may contain a list of itemComponents, each with a name and pointer to another ItemDefinition. So to define a type that is 3 levels deep, you would have to define one or more 2-level ItemDefinitions, and then the top-level ItemDefinition would use those as itemComponents and point to their ItemDefinitions. Also, the current schema is missing cardinality information (in xsd, @minOccurs and @maxOccurs), important in the definition of a complex type:

I propose a change to tItemDefinition by changing tItemComponent. Child itemComponents are now contained in a parent itemComponent, not referenced, just like a complexType in XSD. I would like to make ItemDefinition/@name a required attribute, since it names the type, but am unable to do this without making it required for all tDMNElement. So the spec should just say, even though optional in schema, ItemDefinition/@name is required.

See attached doc with diagram. I will provide also revised dmn.xsd.
Reported: DMN 1.0 — Sat, 16 May 2015 17:56 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
no longer relevant

no longer relevant
Updated: Tue, 29 Mar 2016 15:07 GMT

Question on boxed invocation format

Key: DMN11-50
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In Chapter 11 examples, most boxed invocations - Fig 76, 78, 80, 81 - have format in which the "tab" names the invoking element and the top line of the box, above the parameter list, names the invoked element. Fig 82 is different. The tab names the invoking element, the top line of the box lists the parameters of the invoking element, then the parameter list, and the bottom row names the invoked element.

That seems inconsistent and a mistake.
Reported: DMN 1.0 — Mon, 4 May 2015 21:41 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
issue seeking clarification only

issue was clarified in comments
Updated: Tue, 29 Mar 2016 15:07 GMT

typos for DMN 1.1 RTF final report

Key: DMN11-175
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
All reviewers, please log minor typos here.
Reported: DMN 1.0 — Thu, 29 Oct 2015 17:26 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
errata found in review of V4 of clean spec

see revised text. Some of these are clearly more than typos, more like omission of some editing instructions.
Updated: Tue, 29 Mar 2016 15:07 GMT

Information item name on DTs not correct in some figures

Key: DMN11-166
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
The top box of a DT should display the Information Item determined by the table, i.e. the name of the decision or BKM for which the DT is the logic.

In Figs 32, 34 and 36, "table name" should read "information item".

We should also clarify by adding to the first bullet point in 8.1 "Usually this will be the name of the Decision or Business Knowledge Model for which the Decision Table provides the decision logic."
Reported: DMN 1.0 — Thu, 29 Oct 2015 08:57 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Correct figs 29, 31 & 33 and clarify DT information item

Correct figs 29, 31 & 33 (32, 34 & 36 in v3) by replacing "table name" with "information item name"

Clarify the typical use of this box in the Introduction to Decision Tables (8.1)
Updated: Tue, 29 Mar 2016 15:07 GMT

Decision table MM and xsd need output label attribute

Key: DMN11-139
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Decision table notation has an output name (renamed output label by ~~DMN11-43~~) but there is no place in the MM for this label. Cannot use output clause name because this is the name of the component in a multiple component output.
Reported: DMN 1.0 — Wed, 30 Sep 2015 23:43 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
add outputLabel attribute to DecisionTable MM (and xsd)

see attached MM
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig44Prop140.PNG 83 kB ()

Need InformationItem for the FunctionDefinition of a BKM

Key: DMN11-137
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
At the decision logic level, one does not 'invoke' a BKM; rather, one invokes the FunctionDefinition that is contained in the BKM. How does one refer to the FunctionDefinition by name? Logic refers to InformationItems by name, it does not refer to the DRGElements directly by name. Therefore, a BKM should contain an InformationItem of the same name whose value expression is the FunctionDefinition contained in the BKM.
Reported: DMN 1.0 — Thu, 24 Sep 2015 21:58 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Add InformationItem child to BKM

see attached MM figure. Need git pointer to XSD.
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig19Prop138.PNG 47 kB ()

would like to annotate Expression with typeRef

Key: DMN11-127
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
when we removed the redundant variable references from Expression, we also removed the redundant InformationItem (now typeRef) reference. The result type of an expression is redundant because you can always compute the result type from the input types, and a good tool will have to perform this computation anyway in order to verify that the redundant value is correct. However, simple tools may benefit from a declaration of the expected type of an expression, and the benefit may outweigh the drawbacks of redundancy, hence the issue.
Reported: DMN 1.0 — Fri, 28 Aug 2015 23:33 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
add typeRef attribute to Expression, and derived association to ItemDefinition

Affects MM, XSD, and spec text
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig17Prop128.PNG 99 kB ()
- Fig26Prop128.PNG 98 kB ()
- Fig44Prop128.PNG 87 kB ()
- Fig60Prop128.PNG 52 kB ()

Decision, InputData, and other containers of InformationItem do not ref ItemDefinition directly

Key: DMN11-123
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The InformationItem has a typeRef, which may ref ItemDefinition (derived association)
Reported: DMN 1.0 — Thu, 27 Aug 2015 15:51 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
replace associations to InformationItem with typeRef (datatype) and derived associations

This corrects ~~DMN11-86~~, which is already on ballot 6. Also, replace attached figures, relevant changes highlighted.
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig20Prop126.PNG 29 kB ()
- Fig26Prop126.PNG 94 kB ()
- Fig44Prop126.PNG 85 kB ()

Knowledge Source metamodel diagram missing

Key: DMN11-120
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
section 6.3.10 describes the KnowledgeSource metamodel but has no diagram. KnowledgeSource and AuthorityRequirement is shown in figs 17,19 in a confusing manner and need correction.
Reported: DMN 1.0 — Mon, 24 Aug 2015 22:50 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Add Knowledge Source diagram and clean up KnowledgeSource in Figs 17 and 19
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig17Prop121.PNG 97 kB ()
- Fig19Prop121.PNG 46 kB ()
- KnowledgeSourceMM.PNG 49 kB ()

Definitions/@namespace has no purpose

Key: DMN11-25
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
p38 says "An instance of Definitions has a namespace, which is a String. The namespace identifies the default target namespace for the elements in the Definitions and follows the convention established by XML Schema." I think this is mistaken. The convention established by XML Schema relates to schema/@targetNamespace in the XSD. Definitions/@namespace "follows" (or did in the beta version) the convention established by BPMN 2.0, which is specifically for identifying external references as a variant of QName, using the prefix of the declared target namespace and the ID of the element in that namespace. DMN FTF no longer uses that convention, so Definitions/@namespace has no purpose, although it is a required attribute. I would like to see a return to the beta format of external references (making Definitions/@namespace relevant), since there are explicit pointers from DMN to BPMN processes and tasks, and it makes no sense for DMN to use a different referencing mechanism (based on filename not namespace) than the one BPMN uses to reference other BPMN models.
Reported: DMN 1.0 — Mon, 9 Mar 2015 19:30 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
treat namespace as part of the qualified name for imported elements

presumably if a decision D requires an imported decision E from namespace S, then D's logic can refer to S.E (but where do we say that?)
Updated: Tue, 29 Mar 2016 15:07 GMT

Constraints on Decision Table elements unclear

Key: DMN11-24
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
The S-FEEL and FEEL grammars of chapters 9 and 10 suggest a much wider range of allowed syntax in decision tables than are illustrated in any examples of the spec. For example, input entries and output entries may reference one or more "names" - presumably variables - but in the examples they reference only literal values. Also, all examples of input expressions are simply variable names, not expressions. Additional text is needed to explain what is allowed and not allowed in decision table elements.
Reported: DMN 1.0 — Mon, 9 Mar 2015 19:00 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Text to explain constraints on decision table elements

These edits reflect grammar rule changes consistent with what is allowed in decision table elements under ~~DMN11-49~~, resolving ambiguity of the terms "name", "expression", and other inconsistencies. This proposal was reviewed and agreed by Jan Vanthienen and myself and is ready for consideration by RTF.
Updated: Tue, 29 Mar 2016 15:07 GMT

Expression defined as resulting in single value, but Decision may have multiple values

Key: DMN11-22
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
This is related to ~~DMN11-9~~. Expression class is defined in 7.3 and 7.3.1 as "return a single value when interpreted", but Decision (e.g. DecisionTable, concrete subclass of Expression) may return multiple values, in two ways. Compound output tables, and multi-hit Collect tables. I suggest removing the "single value" comment from definition of Expression, or applying it only to a different class than the superclass of DecisionTable.
Reported: DMN 1.0 — Mon, 9 Mar 2015 18:44 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Revise text to clarify Expression as "single value".
Updated: Tue, 29 Mar 2016 15:07 GMT

input expression example 'age<25' is not legal in SFEEL grammar

Key: DMN11-21
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
8.2.3 says "Input expressions are usually simple, for example, a name (e.g. CustomerStatus) or a test (e.g. Age<25)." However, under the S-FEEL grammar of 9.1, Age<25 is not a simple expression.
Reported: DMN 1.0 — Mon, 9 Mar 2015 17:51 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Revise SFEEL grammar to allow comparison in input expression

The revisions to S-FEEL grammar allow comparison in CL2 input expression. Attachments for discussion only and not part of proposal.
Updated: Tue, 29 Mar 2016 15:07 GMT

In metamodel, 'variable' should move from Information Requirement to Decision / Input Data

Key: DMN11-65
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
In 6.3.11 it says the notation for an information requirement is a plain arrow (from a required decision or input data). Arrows have no labels. Yet, table 14 shows a 'variable'. Presumably, this variable must be the same as the required decision or input data. Therefore, the variable should be removed from the InformationRequirement class, and the Decision class and InputData class should extend the InformationItem class. Variables are of type InformationItem.

Proposed: remove 'variable' from table 14. Make DRGElement extend InformationItem (figures 15, 17, 19, 20 and supporting text). Remove 'informationRequirement' and 'valueExpression' from table 20. Define the qualified name of an imported DRGElement to be of the form prefix . localPart where prefix must be distinct for each import element.
Reported: DMN 1.0 — Thu, 4 Jun 2015 05:31 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
text changes to support move of InformationItem in MM/xsd
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig17Prop86.PNG 117 kB ()
- Fig26Prop86.PNG 47 kB ()

Decision table completeness undefined, Complete code conflicts with Collect

Key: DMN11-32
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
All figures showing decision tables need to be reviewed for correct hit policy and completeness codes. Many examples of UC and HC, which are not allowed in FTF version.
Reported: DMN 1.0 — Tue, 14 Apr 2015 18:45 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Remove completeness info from model and notation

we can define completeness of decision table rules, so that tools behave consistently, but there seems to be no clear need to model or notate completeness as a separate flag.

Many DT figures have a 'C' meaning Complete - these must all be removed.
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig44Prop124.PNG 83 kB ()

Dangling reference

Key: DMN11-35
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
FEEL datatypes are listed in 10.3.2.2. There is no such list. They are described below, in numbered sections, but not in a list.
Reported: DMN 1.0 — Tue, 14 Apr 2015 20:39 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
replace ref to 10.3.2.2

rewording in revised text
Updated: Tue, 29 Mar 2016 15:07 GMT

extraneous asterisks (*)

Key: DMN11-34
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
No idea what the asterisks mean:
FEEL([1+1, 2+2]) *is [2, 4]*.
Proposed: replace with bold text between asterisks and remove asterisks.
Reported: DMN 1.0 — Tue, 14 Apr 2015 20:36 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Remove extraneous asterisks in 10.3.2.1

In clause 10.3.2.1, the example
FEEL([1+1, 2+2]) is [2, 4]
should not contain the asterisks, which are the result of a copy-paste error from JIRA.
Updated: Tue, 29 Mar 2016 15:07 GMT

Beta2 XSDs are broken

Key: DMN11-60
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Both dmn.xsd and dmn3.xsd at http://www.omg.org/spec/DMN/1.0/Beta2/ have problems. Two small issues prevent any use of dmn3.xsd. Four occurrences of type="tExpression" must be changed to type="tLiteralExpression" in dmn.xsd before it can be used to serialize decision tables and enumerations.
Reported: DMN 1.0 — Fri, 22 May 2015 17:54 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
correct 2 issues in dmn3.xsd and 1 issue (4 occurrences) in dmn.xsd

Note that previous issue ~~DMN11-91~~ has combined dmn3.xsd into dmn.xsd
2 occurrences of type="tExpression" to type="tLiteralExpression" made by this issue, and
2 occurrences of type="tExpression" to type="tUnaryTests" made for issue ~~DMN11-81~~.
Updated: Tue, 29 Mar 2016 15:07 GMT

authorityRequirement in XSD

Key: DMN11-52
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
tAuthorityRequirement is incorrect. This element is contained in a decision, BKM, or KnowledgeSource. It should reference a KnowledgeSource, but in XSD it is a choice between requiredDecisionRef, requiredInputRef, and requiredAuthorityRef. Propose replace that choice with requiredAuthorityRef, pointer to the KnowledgeSource.
Reported: DMN 1.0 — Thu, 7 May 2015 18:47 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
issues seeking clarification

issue clarified
Updated: Tue, 29 Mar 2016 15:07 GMT

Remove attribute DecisionTable/@isConsistent

Key: DMN11-44
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
I think this attribute is inappropriate. It reflects a model validation condition, not a design-time property. Moreover, it has default value "false", suggesting that any model that omits this attribute is intentionally inconsistent, which makes no sense to me.

This is a bit different from isComplete, where false could possibly be intentional at design time.
Reported: DMN 1.0 — Thu, 23 Apr 2015 22:32 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
*Remove consistency info from model *

we could define the concept of consistency, so that tools will behave consistently, but it does not seem to belong in the model. Rules are either consistent or not, regardless of what some flag might say.
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig44Prop125.PNG 83 kB ()

change "output expression" to "output name"

Key: DMN11-43
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In decision table, Fig 27, 28, and third bullet on p66 refer to output expression. The other figures and the metamodel/schema refer to output name. I don't believe the output column heading can be an expression, just a name. Suggest replace "output expression" with "output name".
Reported: DMN 1.0 — Thu, 23 Apr 2015 22:02 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
correct callouts in Figs 27&28, create additional figures for multiple outputs

attached figures to be replaced/inserted, with indicated revised neighboring text. No MM or XSD change.
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig27-30Prop118.docx 753 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

add Definitions optional attributes exporter, exporterVersion

Key: DMN11-30
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
For model interchange, BPMN has shown these attributes useful for identifying the tool name and version used to create the serialization. The importing tool may have special mappings for certain exporters.
Reported: DMN 1.0 — Sun, 12 Apr 2015 16:03 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
add Definitions/@exporter, @exporterVersion

optional string attributes used to identify the tool that created the serialization, to aid in model interchange
Updated: Tue, 29 Mar 2016 15:07 GMT
Attachments:
- Fig16-proposal95.PNG 50 kB ()

DMN 1.1 RTF Issue: Negative numerics in decision tables

Key: DMN11-13
Legacy Issue Number: 19731
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
The syntaxes defined in 9.1 (S-FEEL grammar) and 10.3.1.2 (FEEL grammar) do not permit decision table input entries to contain negative numeric values.

9.4.3: An input entry is a simple unary tests, defined using:

14: simple unary tests

13: simple positive unary tests

7: simple positive unary test

8: interval

18: endpoint

19: simple value

33: simple literal

36: numeric literal: [0-9] & “.”

I suggest a numeric literal should be allowed to start with a minus sign.
Reported: DMN 1.0 — Mon, 2 Mar 2015 05:00 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
allow numeric literal to start with minus sign

according to the current grammar, numeric literals cannot have a minus sign, so neither can range endpoints, which are not arbitrary expressions.
Updated: Tue, 29 Mar 2016 15:07 GMT

Nested ItemDefinition doesn't work

Key: DMN11-147
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The intent of ItemDefinition and itemComponent was to allow nested structures, such as Order contains a list of items, each item having an ID, Description, and Quantity. This isn't possible without having to create intermediate ItemDefitions and refs.
Reported: DMN 1.0 — Fri, 9 Oct 2015 18:21 GMT
Disposition: Duplicate or Merged — DMN 1.1
Disposition Summary:
close as duplicate

close as duplicate
Updated: Tue, 29 Mar 2016 15:07 GMT

Clarify defaults for decision table outputs

Key: DMN11-130
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
The spec states (8.2.12) "Incomplete tables may specify a default output. The default value is underlined in the list of output values." This needs two points of clarification:

(a) When a default is specified, a decision table is ipso facto complete. I propose we drop the word "incomplete".
(b) The spec does not say how to use defaults when the output is compound. Can we specify defaults for some output columns and not for others? If so, what value would the output take on default, for the columns where no default was specified? If not, we should say that defaults must be specified for all output columns or none.
Reported: DMN 1.0 — Wed, 2 Sep 2015 14:14 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
close, addressed by other proposals

closed, no longer relevant
Updated: Tue, 29 Mar 2016 15:07 GMT

DMN issue: date syntax in table 29

Key: DMN11-7
Legacy Issue Number: 19691
Status: closed
Source: General Electric ( Mark Linehan)
Summary:
reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36

On page 116, in clause 10.2.2.1, the Beta 2 document introduces Table 29, “String, date, time and duration comparisons, which shows one FEEL Expression: “2012-12-31 in (2012-12-25..2013-02-14)”. The example is invalid because FEEL has no literal syntax for dates. This example should use the date() built-in function.

Also, this table should be combined with Table 28, immediately above since they both give examples of the same kind.
Reported: DMN 1.0 — Wed, 17 Dec 2014 05:00 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Combine tables 28 & 29 and change formatting

revise text as indicated
Updated: Tue, 29 Mar 2016 15:07 GMT

DMN Issue: typo in 3rd well-formed requirement of KnowledgeRequirement

Key: DMN11-6
Legacy Issue Number: 19690
Status: closed
Source: General Electric ( Mark Linehan)
Summary:
Reference the DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG document number dtc/14-11-36

On page 61, clause 6.3.12 describes the “Knowledge Requirement metamodel”. In the section on well-formed KnowledgeRequirements, the third bullet beginning “if the InformationRequirement element ” should instead read “if the KnowledgeRequirement element .”
Reported: DMN 1.0 — Tue, 16 Dec 2014 05:00 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Correct typo in 3rd well-formed requirement of KnowledgeRequirement

On page 51, clause 6.3.12 describes the “Knowledge Requirement metamodel”. In the section on well-formed KnowledgeRequirements, the third bullet beginning “if the InformationRequirement element...” should instead read “if the KnowledgeRequirement element...”
Updated: Tue, 29 Mar 2016 15:07 GMT

DMN issue: typo in introduction of "Relating Logic to Decision Requirements"

Key: DMN11-4
Legacy Issue Number: 19688
Status: closed
Source: General Electric ( Mark Linehan)
Summary:
reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36

The bullet at the top of page 64, in clause 7.1, contains the following garbled sentence: “The variables that are used in the body of the function defined by a business knowledge model element in the DRG must be bound to the information sources each of the requiring decision.”
Reported: DMN 1.0 — Tue, 16 Dec 2014 05:00 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
correct the typo

see revised text
Updated: Tue, 29 Mar 2016 15:07 GMT

XSD internally inconsistent, does not match the spec

Key: DMN11-9
Legacy Issue Number: 19724
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
I believe the XSDs are seriously messed up. On the surface, this would be apparent to anyone who tried to open the level 3 xsd in an XML editor, since the “include” fails right off the bat and the tool goes ding ding ding. Not only does it point to the wrong filename, but the namespace is different, not allowed with include. You can fix those things by making the namespaces match and fixing the filespec. Actually I don’t care that much about the level 3. I am more concerned with the 14-08-19.xsd, the Level 1 and 2.

That one has an element named ItemDefinition and another one named itemDefinition with different datatype, which is confusing. I believe that the latter is a pointer to the former. If so, you will have a lot less confusion by renaming the latter itemDefinitionRef.

But the problem with the XSD goes a lot deeper. Maybe it is my lack of understanding of the spec, I don’t know. I think the central problem is that tExpression (the datatype for inputExpression, inputEntry, outputEntry, range of allowed values, and many other elements) is just a list of inputVariables and possibly a single itemDefinition(Ref). It is NOT an expression, in natural language, S-FEEL, or anything else. Maybe the intent was to allow literal expressions, but the XSD does not reference tLiteralExpression, just tExpression. Or maybe the intent was to do like BPMN and make tExpression a mixed-content type, where the expression string is the direct content of the element, but the XSD does not say that, either. Or maybe the intent is to put the expression in the any ##other element or attribute? That would work but be very weird. Anyway, without that I think it would be an impossible challenge to serialize even the simplest decision table per the XSD. And maybe that is why there are no serialization examples in the spec.
Reported: DMN 1.0 — Tue, 17 Feb 2015 05:00 GMT
Disposition: Duplicate or Merged — DMN 1.1
Disposition Summary:
overall, early list of possible xsd issues subsumed by more focussed issues

All the substantive have been addressed by other issues. This can be closed.
Updated: Tue, 29 Mar 2016 15:07 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
- The URL for BPMN, as per here: http://www.omg.org/spec/BPMN/2.0.2/ should be http://www.omg.org/spec/BPMN/20100501/BPMN20.cmof
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

S-FEEL "expression" undefined

Key: DMN11-23
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
The S-FEEL grammar in 9.1 references "expression" in rules 21-26, but "expression" is undefined in S-FEEL. Probably "expression" in those rules should be replaced by "simple expression", which is defined.
Reported: DMN 1.0 — Mon, 9 Mar 2015 18:47 GMT
Disposition: Duplicate or Merged — DMN 1.1
Disposition Summary:
duplicates issue 24

duplicates issue 24
Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: DecisionTable/rule/condition should be IDREF not IDREFS

Key: DMN11-27
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
This element is a pointer to one inputEntry (and implicitly to its clause) so it should be IDREF, not a list. The element is unbounded, so references to other inputEntry elements are contained in other condition elements of the same rule.
Reported: DMN 1.0 — Mon, 9 Mar 2015 19:42 GMT
Disposition: Duplicate or Merged — DMN 1.1
Disposition Summary:
merge with issue 81 to remove the level of indirectlion

we think that intra-decision table references are a significant complication with no useful purpose. Thus, merge with 81.
Updated: Tue, 29 Mar 2016 15:07 GMT

need to add UnaryTests to MM and XSD

Key: DMN11-109
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
This is to complete the proposal begin by issue ~~DMN11-24~~ proposal ~~DMN11-67~~
Reported: DMN 1.0 — Thu, 6 Aug 2015 16:31 GMT
Disposition: Duplicate or Merged — DMN 1.1
Disposition Summary:
solved as part of ~~DMN11-81~~

The necessary changes have been done in ~~DMN11-81~~.
Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: change type of LiteralExpression/text, ItemDefinition/typeDefinition, and (new) textAnnotation/text to xsd:string

Key: DMN11-102
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
Currently these are mixed content type in which the direct content is untyped, and any additional child elements must be in a different namespace. they should simply be string.
Reported: DMN 1.0 — Tue, 21 Jul 2015 17:22 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
change mixed content elements to string

xsd change only
Updated: Tue, 29 Mar 2016 15:07 GMT

Decision Table metamodel and XSD should restrict input entries, input values, and output values to unary tests, and LiteralExpression for input expressions and output entries

Key: DMN11-84
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Current MM allows any expression for input entries. The spec restricts these to text strings with syntax of unary tests (or simple unary tests). Also, unary tests are not expressions and are not literal expressions.
Reported: DMN 1.0 — Fri, 26 Jun 2015 23:26 GMT
Disposition: Duplicate or Merged — DMN 1.1
Disposition Summary:
*merge with 81 - removing indirection from decision table *

So that all the decision table MM and XSD changes can be done together, we combine these issues.
Updated: Tue, 29 Mar 2016 15:07 GMT

8.2.10 calls crosstab tables "rules as columns"

Key: DMN11-88
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
Figure 41 and 42 are crosstab (columns and rows are input values) but called vertical/rules-as-columns. Surrounding text in 8.2.10 also incorrect.
Reported: DMN 1.0 — Mon, 29 Jun 2015 23:12 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
OK as is

I agree with comments, withdraw the issue.
Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: make @id optional in tExpression

Key: DMN11-80
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
Except for DT rule conditions and conclusions, id pointers to expressions are rare (maybe none?). Propose change @id in tExpression from required to optional.
Reported: DMN 1.0 — Fri, 19 Jun 2015 16:14 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Change tExpression/@id to use="optional"

Change value of attribute 'use' from 'required' to 'optional'.
Updated: Tue, 29 Mar 2016 15:07 GMT

FEEL/S-FEEL names

Key: DMN11-62
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
S-FEEL grammar rules 30-32 list characters that can be part of names. I do not see space (\u20) as one of the allowed characters or "additional symbols". There are lots of Unicode characters and symbols that probably should not be allowed.
Reported: DMN 1.0 — Sat, 30 May 2015 22:25 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
name symbols mostly copied from xml, but we do add the space!

can open new issue in 1.2 if spaces are really a problem for implementations
Updated: Tue, 29 Mar 2016 15:07 GMT

list variables in decision tables

Key: DMN11-33
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
Is it correct to say that a list is not allowed as an input expression in S-FEEL? That would mean that a supporting decision with Collect hit policy could not provide input to a dependent decision table. If it is allowed, I don't think S-FEEL input entry can distinguish "every member of the list is in [literal list]" from "any member of the list is in [literal list]". I believe it would be allowed in full FEEL... but unclear if decision table can use this.
Reported: DMN 1.0 — Tue, 14 Apr 2015 19:16 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
no change required for input expression

If an input variable is a list, then input expression can reference it.
Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: Relation and List

Key: DMN11-76
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
Relation is a particular boxed expression format for a list of similar contexts. It is a two-dimensional grid. Each row (unlabeled) represents a context, and each column a context entry. dmn3.xsd does not properly represent this. Also, Gary suggested organizing the grid in the xsd by rows (contexts) rather than by columns, as it is now in dmn3.xsd.
Reported: DMN 1.0 — Thu, 11 Jun 2015 19:04 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
Modify tList and tRelation in dmn3.xsd

Withdrawn.
Updated: Tue, 29 Mar 2016 15:07 GMT

Xsd typeRef and itemDefinitionRef

Key: DMN11-57
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In xsd, ItemDefinition links the type either to a base type via typeDefinition or some other type via typeRef. If the other type is defined externally in imported xsd, typeRef should be QName, pointer to a name, which it is. But to reuse a type defined in another ItemDenition, it should be itemDefinitionRef, pointer to an id. Propose that itemDefinitionRef be added to the choice in ItemDefinition.
Reported: DMN 1.0 — Sun, 17 May 2015 16:09 GMT
Disposition: Duplicate or Merged — DMN 1.1
Disposition Summary:
Resolved in ~~DMN11-54~~

Resolved in ~~DMN11-54~~
Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: add optional @name to inputVariable

Key: DMN11-55
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In a decision logic expression, inputVariable is an ID reference to an InformationItem, which provides the variable's name. The expression (e.g. binding expression or literal expression) then references the variable by name. This works operationally, but the logic of the XML would be much easier to follow and debug if the inputVariable allowed an optional name attribute to hold the variable's name.
Reported: DMN 1.0 — Fri, 15 May 2015 20:07 GMT
Disposition: Duplicate or Merged — DMN 1.1
Disposition Summary:
Merged with and Resolved by ~~DMN11-69~~

I submitted this issue but now I think better approach is to remove id references like inputVariable in tExpression and use names instead. This issue is thus merged with ~~DMN11-69~~ and resolved by that proposal.
Updated: Tue, 29 Mar 2016 15:07 GMT

FEEL concatenate function

Key: DMN11-53
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In Table 58, concatenate and append are essentially the same list function in FEEL. There is no concatenate string function in Table 57. Propose concatenate be moved to Table 57 as a string function (where it is most needed).
Reported: DMN 1.0 — Tue, 12 May 2015 00:03 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
string concatenation uses the "+" operator rather than a builtin function

string concatenation is defined in Table 42
Updated: Tue, 29 Mar 2016 15:07 GMT

dmn3.xsd

Key: DMN11-48
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
This issue separates the dmn3.xsd issues from ~~DMN11-9~~, which otherwise concerns dmn.xsd.
There are a number of serious problems with dmn3.xsd:
1. Syntactically incorrect. The include of dmn.xsd points to the wrong filename. The only reason why include is needed (syntactically) is to reference tExpression.
2. tExpression is not the right datatype for the elements. See ~~DMN11-9~~ for why.
3. dmn3.xsd does not represent what 12.2.2 says it does. It is not an interchange format for Level 3 decision models! It is just a schema for a context. And it is not even the right schema for a context. Serialization of a context does not use elements named ContextEntry, List, Relation, etc. You can see that from 10.3.3.3.1 and 10.3.3.3.2. I think it is meant to clarify the semantics of context, but it would never be used in serialization.

For these reasons I propose that 12.2 is modified and dmn3.xsd is removed from the specification. If a separate schema is needed to serialize Level 3, it must contain the whole thing, starting from Definitions. I don't think a separate schema is needed, but we should check if the existing element for output variable, InformationItem, can describe a context.
Reported: DMN 1.0 — Thu, 30 Apr 2015 15:14 GMT
Disposition: Duplicate or Merged — DMN 1.1
Disposition Summary:
close and merge with dmn11-91

The issues with dmn3.xsd are addressed by dmn11-61, dmn11-94 and others.
Updated: Tue, 29 Mar 2016 15:07 GMT

output data symbol & comment symbol missing in DRDs

Key: DMN11-42
Legacy Issue Number: 19746
Status: closed
Source: Anonymous
Summary:
Please add an optional output data symbol and a comment symbol, which I both urgently miss, as discussed in the LinkedIn DMN group at
https://www.linkedin.com/groups/Why-no-output-data-symbol-4225568.S.5976658175284244483

Summary: Why is there no output data symbol in DMN 1.0's DRDs?
Decisions have results, which may be complex, and currently their output data may only be indicated by the decision's name (e.g. "determine X": output is X; "check X": result is Boolean). That is not very clear.

An optional output data symbol would make decision output graphically explicit, and provides for symmetry.

DMN also lacks a comment symbol which could otherwise be used for this on DRDs.
Reported: DMN 1.0 — Fri, 17 Apr 2015 04:00 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
add text annotations in ~~DMN11-99~~ but decline to add output symbol

output symbol seems redundant with existing decision symbol (an decision has always exactly one output) and we don't want to clutter a large DRD
Updated: Tue, 29 Mar 2016 15:07 GMT

Clarify Decision/outputDefinition, DecisionTable/clause/outputDefinition, DecisionTable/@name, clause/@name

Key: DMN11-39
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
The issue is illustrated by Fig 36 on p71. The resolution should be clarified in the text.
8.2.5 says (I think) that Decision/@name = DecisionTable/@name = label in output column header in the decision table.
For a single-output DT, Decision/outputDefinition* and DecisonTable/clause/outputDefinition* both point to an itemDefinition defining the data type of the output.
For a compound-output DT, the compound output name is DecisionTable/@name. Decision/outputDefinition is a pointer to an itemDefinition for the compound output, but the spec does not describe how such a compound output should be constructed. Each individual output name is given by DecisionTable/clause/@name (for an output clause), and the clause/outputDefinition is a pointer to its datatype.
- renamed outputDefinitionRef in proposed revision to dmn.xsd, see ~~DMN11-9~~. In any case, these elements should be given different names.
Reported: DMN 1.0 — Thu, 16 Apr 2015 19:30 GMT
Disposition: Duplicate or Merged — DMN 1.1
Disposition Summary:
Merge with ~~DMN11-43~~

Some of this is resolved by other MM changes to decision table. The issue of output names and clause names is the focus of ~~DMN11-43~~.
Updated: Tue, 29 Mar 2016 15:07 GMT

Examples

Key: DMN11-29
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
DMN 1.1 should provide examples of all types of decision model allowed by the standard, both graphically (DRD and decision table, where appropriate) and XML serialization. Currently missing:
1. decision tables with an expression (more than a name) in inputExpression and outputExpression.
2. decision tables with inputEntry or outputEntry referencing a "name" as defined by S-FEEL, i.e. not just a literal.
3. DRD and decision table involving what Vanthienen calls "action subtables". All existing examples are "condition subtables".
4. Serialization of crosstab format tables.
5. Representation of literal values vs names in serialization.
6. Representation of PMML and FEEL in the serialization.
Reported: DMN 1.0 — Sun, 12 Apr 2015 15:39 GMT
Disposition: Deferred — DMN 1.1
Disposition Summary:
no volunteers, no time for 1.1

agreed to be important for 1.2
Updated: Tue, 29 Mar 2016 15:07 GMT

not all references in DMN are by ID

Key: DMN11-152
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
new typeRef is by name, not ID, as claimed in beta2 spec 12.3.2
Reported: DMN 1.0 — Wed, 21 Oct 2015 01:38 GMT
Disposition: Resolved — DMN 1.1
Disposition Summary:
Correct text for XSD references (12.3.2)

see revised text
Updated: Tue, 29 Mar 2016 15:07 GMT

DMN Issue: Boxed context example of XML data is wrong

Key: DMN11-8
Legacy Issue Number: 19692
Status: closed
Source: General Electric ( Mark Linehan)
Summary:
reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36

Clause 10.3.3.3.3 on page 144 shows a boxed context that is supposed to be the equivalent of the XML example shown in clauses 10.3.3.3.1 and 10.3.3.3.2. This boxed content is missing a horizontal line immediately below the row that contains “tns$Employee”.
Reported: DMN 1.0 — Wed, 17 Dec 2014 05:00 GMT
Disposition: Closed; No Change — DMN 1.1
Disposition Summary:
the line is there in the 'real' spec

line was missing in a version used by reviewer
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

DMN issue: InformationItem is not a specialization of Expression

Key: DMN11-5
Legacy Issue Number: 19689
Status: closed
Source: General Electric ( Mark Linehan)
Summary:
reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36

On page 75, in clause 7.3.4, the 6th paragraph starts “As a concrete specialization of Expression, an InformationItem element .” However, none of the UML diagrams show a generalization relationship between InformationItem and Expression.
Reported: DMN 1.0 — Tue, 16 Dec 2014 05:00 GMT
Disposition: Duplicate or Merged — DMN 1.1
Disposition Summary:
merge with issue to clarify relationship of Information Item and Expression

proposal for issue 65 resolves this issue as well
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

BigDecimal is not the only mapping of number to Java

Key: DMN11-11
Status: closed
Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
Summary:
Clause 10.3.2.9 shows FEEL number values as mapped to XML decimal, integer, and double, but the only mapping to Java is to BigDecimal. The appropriate mapping to Java, like the appropriate mapping to XML, depends on the range and intent of the data element. BigDecimal is rarely used for anything but currency. Java int and double are much more likely to be appropriate for most data items. The mapping of number to Java should be just as flexible as the mapping to XML and PMML.
Reported: DMN 1.0 — Wed, 9 Jul 2014 21:23 GMT
Disposition: Deferred — DMN 1.1
Disposition Summary:
no one volunteered, we'll try again in 1.2

roll forward to 1.2
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

No notation for ItemDefinition

Key: DMN11-66
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
The notion of a 'type' or ItemDefinition is in the metamodel (with some pending issues) and in the semantics and concepts, but little is in the notation. Thus, we have notation that allows you to execute an expression with actual arguments, but no notation to allow validation based on type information without actual values.

We have most of the pieces, so it should not be difficult. E.g., individual values can be number, string, date and time, etc. We can allow numeric ranges using our unary tests, e.g. '>0', '[10..30)', etc. We can allow LOVs using "abc", "def", "ghi". These can be 'simple items', and we can also define structures using something similar to boxed contexts.
Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
Disposition: Deferred — DMN 1.1
Disposition Summary:
carry over to 1.2

carry over to 1.2
Updated: Tue, 29 Mar 2016 15:07 GMT

Consider date and time datatype in S-FEEL

Key: DMN11-46
Legacy Issue Number: 19755
Status: closed
Source: FICO ( Dr. Alan Fish)
Summary:
a. In clause 9.2, para 5, first sentence, "date and time" should be in italics.
b. Why is date and time type excluded from S-FEEL? This restriction makes XSD mapping problematic.
Reported: DMN 1.0 — Tue, 28 Apr 2015 04:00 GMT
Disposition: Deferred — DMN 1.1
Disposition Summary:
defer to 1.2

No proposal was submitted for 1.1
Updated: Tue, 29 Mar 2016 15:07 GMT

alternative indication of reusable logic in DRD

Key: DMN11-51
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In the metamodel/XSD, decision logic is contained in a decision element, hence not reusable. To reference reusable decision logic, decision invokes BKM, which is reusable. The semantics are clear, but representation of the decision and BKM as separate graphical elements in DRD is visually inefficient. It creates unnecessary clutter in the DRD (Fig 63 is a prime example). BPMN solved this problem in a better way, and I suggest DMN should allow the same. In BPMN a subprocess definition is embedded in the parent process so to reference reusable subprocess, it uses a call activity. The call activity shape is same as subprocess except it has a thick border style. The diagram does not contain both subprocess and call activity, just one or the other. I would like to propose that a decision shape in DRD with a thick border be used to mean the decision invokes a BKM (with name generated from the decision name). No metamodel or schema changes required; this is merely alternative graphical notation. In a DMN tool, typically clicking on the decision will hyperlink to the decision logic (DT or literal expression), whether that logic is embedded in the decision or reusable. This distinction is mostly important to programmers, not modelers, so should not unnecessarily complicate the diagram.
Reported: DMN 1.0 — Tue, 5 May 2015 17:58 GMT
Disposition: Deferred — DMN 1.1
Disposition Summary:
no time in 1.2

defer to 1.2
Updated: Tue, 29 Mar 2016 15:07 GMT

Business Context links go both ways

Key: DMN11-31
Status: closed
Source: Bruce Silver Associates ( Mr. Bruce Silver)
Summary:
In XSD, business context pointers are duplicated in both directions. E.g. decisionOwner and decisionMaker point to organizationalUnit, which in turns has pointers back the other way. This duplication adds no new information, just potential for internal inconsistency. I suggest omitting one of these directions; the other one is easily extracted from the serialization by XPATH.
Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
Disposition: Deferred — DMN 1.1
Disposition Summary:
defer to 1.2

minor issue, no strong advocate to change in 1.1
Updated: Tue, 29 Mar 2016 15:07 GMT

Need group artifact in DRD, metamodel, and XSD

Key: DMN11-116
Status: closed
Source: Oracle ( Gary Hallmark)
Summary:
Group is an unfilled rectangle enclosing various elements in the DRD, with meaning defined by the modeler. It follows the usage defined by BPMN, an “artifact” with no operational semantics, simply an annotation of the model.
Reported: DMN 1.0 — Thu, 20 Aug 2015 00:13 GMT
Disposition: Deferred — DMN 1.1
Disposition Summary:
This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force
Updated: Tue, 22 Dec 2015 15:43 GMT
Attachments:
- bpmn-figure-010.png 36 kB (image/png)
- bpmn-figure-012.png 22 kB (image/png)
- group.jpg 6 kB (image/jpeg)

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:
- dmn.xmi 112 kB ()

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:
- Issue 3 Proposed Resolution.docx 12 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

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:
- DMN Beta draft 2.1 markup.pdf 4.60 MB (application/pdf)
- DMN Beta draft 2.1.pdf 4.49 MB (application/pdf)
- DMN Beta draft 2.1.zip 3.24 MB (application/zip)

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:
- DMN correct for issue 15.doc 2.81 MB (application/msword)

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:
- DefineAbilityToFly.pdf 197 kB (application/pdf)
- Priority compound outputs v3.docx 17 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

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:
- floor.doc 34 kB (application/msword)

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:
- Issue18proposed-140729.rtf 89 kB (application/rtf)

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

What is DMN namespace?

Key: DMNFTF-9
Status: closed
Source: International Business Machines ( Mr. Christian De Sainte Marie)
Summary:
What is the target namespace for the DMN XML Schema?
Reported: DMN 1.0b1 — Thu, 1 Aug 2013 14:27 GMT
Disposition: Resolved — DMN 1.0
Disposition Summary:
The correct namespace for DMN 1.0 is http://www.omg.org/spec/DMN/20130901
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:
- DMN issue 99-ecorr.doc 204 kB (application/msword)

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:
- BusinessContext.png 715 kB (image/png)

Beta 5 with attachments

Key: DMNFTF-232
Status: closed
Source: International Business Machines ( Mr. Christian De Sainte Marie)
Summary:
Beta 5, including corrected XMI and XSD files
Reported: DMN 1.0b1 — Thu, 31 Jul 2014 15:35 GMT
Disposition: Resolved — DMN 1.0
Disposition Summary:
Final Specification (clean copy and convenience copy)

This is the proposed DMN 1.0 document and the 'convenience document' that details issue-by-issue changes since beta 1.
Updated: Tue, 21 Apr 2015 01:19 GMT
Attachments:
- DMN 10 (corrected for all FTF issues).xmi 112 kB ()
- DMN 10 level 1+2 (corrected for all FTF issues).xsd 16 kB (text/xml)
- DMN 10 level 3 (corrected issue 1).xsd 2 kB (text/xml)
- DMN Beta 5.pdf 5.29 MB (application/pdf)
- DMN Beta companion.pdf 6.85 MB (application/pdf)

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:
- DMN Revised Submission Errata Applied corrected for issue 54.doc 214 kB (application/msword)

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:
- Improved chapter 8.1-8.2-8.4 FTF.docx 573 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

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:
- 8.1-8.2.2 spec ready for 55, 66-70, 74.doc 261 kB (application/msword)
- Improved chapter 8.1-8.2-8.4 FTF (1).pdf 721 kB (application/pdf)

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:
- concat.doc 28 kB (application/msword)

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:
- DMN beta 3 corrected for issue 35.doc 4.48 MB (application/msword)

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:
- Lists.doc 33 kB (application/msword)

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:
- DMN Beta draft 1.pdf 4.42 MB (application/pdf)

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:
- aggregate_varargs.doc 31 kB (application/msword)

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:
- Issue60proposed-140723.rtf 87 kB (application/rtf)

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:
- different styles.docx 250 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

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

No Knowledge Sources in example

Key: DMNFTF-89
Status: closed
Source: Decision Management Solutions ( James Taylor [X] (Inactive))
Summary:
The example does not include any Knowledge Sources and should do.
Reported: DMN 1.0b1 — Thu, 20 Mar 2014 21:09 GMT
Disposition: Resolved — DMN 1.0
Disposition Summary:
add knowledge sources to Fig 55
Updated: Tue, 21 Apr 2015 01:19 GMT
Attachments:
- Figure 55 with KSs various types.jpg 1.85 MB (image/jpeg)
- Figure 55 with KSs.jpg 1.82 MB (image/jpeg)

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:
- Issue 88 figure 2.jpg 1.99 MB (image/jpeg)
- _thumb_10416.png 9 kB (image/png)

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:
- 8.1-8.2.2 spec ready for 55, 66-70, 74.doc 261 kB (application/msword)
- Improved chapter 8.1-8.2-8.4 FTF (1).pdf 721 kB (application/pdf)

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:
- 8.2.11 spec ready for 73-77.doc 206 kB (application/msword)

"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:
- 8.2.11 spec ready for 73-77.doc 206 kB (application/msword)

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:
- 8.2.11 spec ready for 73-77.doc 206 kB (application/msword)

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:
- 8.2.11 spec ready for 73-77.doc 206 kB (application/msword)

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:
- feel examples.doc 39 kB (application/msword)

"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

Key: DMNFTF-70
Legacy Issue Number: 19221
Status: closed
Source: Object Management Group ( Andrew Watson)
Summary:
Fig 27, 28, 30, 31 ... The meaning of the letters "HC" in these tables is not introduced for another 30 pages. It's a long wait.
Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
Disposition: Resolved — DMN 1.0
Disposition Summary:
Define hit policy and completion code earlier in clause 8.
Updated: Tue, 21 Apr 2015 01:19 GMT
Attachments:
- 8.1-8.2.2 spec ready for 55, 66-70, 74.doc 261 kB (application/msword)
- Improved chapter 8.1-8.2-8.4 FTF (1).pdf 721 kB (application/pdf)

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:
- 8.1-8.2.2 spec ready for 55, 66-70, 74.doc 261 kB (application/msword)
- Improved chapter 8.1-8.2-8.4 FTF (1).pdf 721 kB (application/pdf)

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:
- 8.1-8.2.2 spec ready for 55, 66-70, 74.doc 261 kB (application/msword)
- Improved chapter 8.1-8.2-8.4 FTF (1).pdf 721 kB (application/pdf)

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:
- 8.1-8.2.2 spec ready for 55, 66-70, 74.doc 261 kB (application/msword)
- Improved chapter 8.1-8.2-8.4 FTF (1).pdf 721 kB (application/pdf)

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
Attachments:
- DMN Revised Submission Errata Applied corrected for issue 99 (no XLink).doc 208 kB (application/msword)

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:
- DMN Example Beta 4.docx 1.39 MB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

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:
- Connection rules clarification v2.docx 59 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

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:
- casedata+group edits.docx 19 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

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:
- Correction of editorial issues (248).doc 343 kB (application/msword)

Change Tracking Document

Key: DMNFTF-247
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: 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:
- Change tracking - Gary.doc 5.51 MB (application/msword)
- Change tracking csma.doc 2.53 MB (application/msword)
- Change tracking section 11.docx 9.07 MB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- DMN 1.0 b FTF change-bar.pdf 6.98 MB (application/pdf)
- DMN 1.0 b FTF clean.pdf 5.29 MB (application/pdf)
- DMN 1.0 c FTF change-bar.doc.001 10.00 MB ()
- DMN 1.0 c FTF change-bar.doc.002 10.00 MB ()
- DMN 1.0 c FTF change-bar.doc.003 10.00 MB ()
- DMN 1.0 c FTF change-bar.doc.004 6.42 MB ()
- DMN 1.0 c FTF change-bar.pdf 7.03 MB (application/pdf)
- DMN 1.0 c FTF clean.pdf 5.29 MB (application/pdf)
- DMN 1.0 d FTF change-bar.doc.001 10.00 MB ()
- DMN 1.0 d FTF change-bar.doc.002 10.00 MB ()
- DMN 1.0 d FTF change-bar.doc.003 10.00 MB ()
- DMN 1.0 d FTF change-bar.doc.004 6.42 MB ()
- DMN 1.0 d FTF change-bar.pdf 7.00 MB (application/pdf)
- DMN 1.0 e FTF change-bar.doc.001 10.00 MB ()
- DMN 1.0 e FTF change-bar.doc.002 10.00 MB ()
- DMN 1.0 e FTF change-bar.doc.003 10.00 MB ()
- DMN 1.0 e FTF change-bar.doc.004 6.42 MB ()
- DMN 1.0 e FTF change-bar.pdf 7.01 MB (application/pdf)
- change tracking document 2014-11-20.doc.001 10.00 MB ()
- change tracking document 2014-11-20.doc.002 10.00 MB ()
- change tracking document 2014-11-20.doc.003 3.74 MB ()
- change tracking document 2014-11-24.doc.001 10.00 MB ()
- change tracking document 2014-11-24.doc.002 10.00 MB ()
- change tracking document 2014-11-24.doc.003 3.79 MB ()
- change tracking document.doc.001 10.00 MB ()
- change tracking document.doc.002 8.74 MB ()
- dtc-2014-08-17 (annotated).pdf 7.23 MB (application/pdf)

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:
- DMN 1.0 FTF change-bar.pdf 6.88 MB (application/pdf)
- DMN 1.0 FTF clean.pdf 5.29 MB (application/pdf)

type1	type2	equivalent to	conforms to
type([{"id": 1,"name":"Peter", "age": 45}])	type(Decision3)	True	True
type(Decision4)	type(Decision3)	True	True