Issue 1: The footnote of the entire document states version 1.3. Should this not be 1.4?
Issue 2: 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 decisison. 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

is passed. So the two outputs are "b", "d". As the decision is NOT a collection, we should not yield something like

, but should aggregate, yet, as stated, how to aggregate b,d?

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]

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

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

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

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

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

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.

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

Duplicate of DMN15-119

Fixed in DMN15-128

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

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

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

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

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"

The names of the number() function in note 1 at the end of Table 72

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.