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:

• https://issues.omg.org/browse/DMN12-62?focusedCommentId=18500&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-18500
• DMN13-191
• DMN14-166

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

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.

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

Remove typeRef from variable of BKMs

Remove typeRef from BKM variables but keep it on their encapsulatedLogic in 9 places

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.

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

Section 10.3 contains a number of instances where a space has appeared after the numeral 1. Sometimes this makes the syntax incorrect.

Remove superfluous spaces after "1"

Replace "1 " with "1".

The copyright section needs to be updated.

Update copyright section

Update the years of contribution based on OMG-recognized contributors and taskforce membership. See also DMN13-242

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.

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

There are 2 typos in the examples

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

Should be

duration("P0DT25H") and duraton("P0Y13M"))

Fix spelling of the word 'duration'

Fix spelling of the word 'duration' in two places

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

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.

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&#xA;"

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="&#34;text/plain&#34;"/>

(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

Fix meta model typos

Fix several typos in meta model (XMI) that are not consistent with the XML schema (XSD).

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 

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

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.

Remove part of section that is erroneous

Delete part of section 7.1 that is erroneous on page 60 (PDF 66)

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.

Clarify equivalence between date and date and time instances

Clarify equivalence between date and date and time instances

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.

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

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.

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.

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.

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.

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]

Add an example using null to the Lists and filters section

In section 10.3.2.5 add an example

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

Resolved already

Resolved in an earlier version already when we introduced the type lattice.

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.

Duplicate of DMN15-44

Duplicate of DMN15-44

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

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.

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.

Correct text about decimal numbers

Correct the statements about numbers to include scientific notation.

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.

No external references any more

The latest XMI file does not have such references.

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.

Defer to DMN 1.6

Defer to DMN 1.6

In this couple of chapters, "duration" is written "duraion" (without "t" - 2 occurrences)

Duplicate of DMN15-119

Fixed in DMN15-128

Sections 10.3.2.3.7 and 10.3.2.3.8 have "duraion" instead of "duration"

Fixed in another issue

Fixed already in DMN15-128

Sample xml files have Trisotech extension elements. These should be removed prior to publication.

The examples don't contain extensions

The issue seems to be fixed

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.

Extend positive unary tests with equality operators

Extend positive unary tests with equality operators

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 )

Requirements SHOULD be referenced

change text in Chapter 7.1 and 7.3.4 according to the below instructions

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.

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.

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.

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

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

Widen semantic of Table 62 to cover FEEL semantic

Change of text for semantic of Table 62

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.

Fix 3rd bulletpoint rule reference in "10.3.1.2 Grammar rules"

Update the grammar rule reference and provide more context.

Currently the syntax of numeric literals does not support usage of exponents. This is quite useful when dealing with large numbers.

Support numbers in scientific notation

Extend grammar to support numbers in scientific notation

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.

Proposal merged into DMN15-136

Proposal merged into DMN15-136

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

Duplicate of previous issue

Duplicate of previous issue

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

Duplicate of previous issue

Duplicate of previous issue

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

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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.

Issue has been split up

The relevant gaps are covered in the respective JIRAs DMN15-99 and DMN15-101

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.

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.

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

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.

in FEEL -4**2 = 16
Some may expect = -16

Add clarification about precedence

Add a warning about the different precedence and suggestions to avoid ambiguities

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.

Fix typo "DecsionTable"

Fix typo

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Duplicate of DMN15-94

Fixed in DMN15-95

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.

Close without change

Issue fixed already in DMN 1.4

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

Defer to DMN 1.6

Defer to DMN 1.6

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?

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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?

Defer to DMN 1.6

Defer to DMN 1.6

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?

Defer to DMN 1.6

Defer to DMN 1.6

The FEEL grammar contains simple expressions as starting terminal

page 107 6. simple expressions = 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?

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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?

Defer to DMN 1.6

Defer to DMN 1.6

Figure 10 on page 25 with text "The encapsulated decisions are therefore

"

Figure 11 on page 26 with text "The encapsulated decisions for this services are

".

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

Defer to DMN 1.6

Defer to DMN 1.6

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] }

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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/

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

split off from DMN13-12

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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)

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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?

Defer to DMN 1.6

Defer to DMN 1.6

Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.
UnaryTest should be added to the diagram.

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

E.g. in aggregation, default for item definition, see examples in DMN-2, where filters like [item!=null] are used repeatedly

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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"

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

There is no visual way to show that a decision iterates over a collection at the top level.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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()?

Defer to DMN 1.6

Defer to DMN 1.6

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) 

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

A "bucket" for collecting related issues around external links

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6

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.

Allow the import into the default namespace by specifying an empty name.

allow the import into the default namespace by specifying an empty name.

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

Defer to DMN 1.6

Defer to DMN 1.6

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"

Defer to DMN 1.6

Defer to DMN 1.6

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.

Defer to DMN 1.6

Defer to DMN 1.6