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.

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

Currently, it is not possible to merge/concatenate two or more contexts. A context can only be declared statically.

We need to model a decision that gets two or more contexts and returns a new context that includes all entries of the given contexts.

Suggestions:

• introduce a new built-in function similar to the concatenate() function of lists but for contexts
• it is named `put all` (like Java's Map#putAll function)
• it has one argument: contexts... (type: list<context<Any>>)
• it returns a new context that includes all entries from the given contexts
• it might override context entries if the keys are equal. The entries are overridden in the same order as the contexts are passed in the function

put all({x:1}, {y:2})
// returns: {x:1, y:2}

Close as merged

Resolved as part of DMN14-187

Currently, it is not possible to create or modify a context dynamically. A context can only be declared statically.

We need to model a decision that gets a context, adds or removes entries, and returns a new context. For example, by using the get entries() function of a given context and modifying the entry list with a filter expression or list functions.

Suggestions:

• introduce a new conversion built-in function for context as reverse function to get entries()
• it is named `context`
• it has one argument: entries... (type: list<context<Any>>) - each context must have two entries with the keys: "key" and "value"
• it returns a new context that includes all given entries

context([{"key":"a", "value":1}, {"key":"b", "value":2}])
// returns: {a:1, b:2}

Close as merged

Resolved as part of DMN14-187

Currently, it is not possible to add an entry to a given context. A context can only be declared statically.

We need to model a decision that gets a context, adds an entry, and returns the new context.

Suggestions:

• introduce a new built-in function similar to the add() function of lists but for contexts
• it is named `put` (like Java's Map#put function)
• it has three arguments: context (type: context<Any>), key (type: string), value (type: Any)
• it returns a new context that includes the new entry
• it might overwrite the value of an existing entry

put({x:1}, "y", 2)
// returns {x:1, y:2}

Introduce 3 new built-in functions for context

Introduce 3 new built-in functions for context creation, context put, context merge (of several contexts).

For tools to clearly identify the version of a DMN file or FEEL expression, the XML namespaces of DMN, DMN DI, and FEEL should be updated.

DI and DC namespaces can stay the same as DMN 1.4 DI is still based on the same DI 1.1 specification.

Namespace URIs should be consistent with the scheme applied in DMN 1.2 and DMN 1.3

Update XML Namespaces for DMN 1.4

Update namespace URIs with the following values:

• DMN14.xsd: https://www.omg.org/spec/DMN/20211108/MODEL/
• FEEL: https://www.omg.org/spec/DMN/20211108/FEEL/
• DMN14.xmi: http://www.omg.org/spec/DMN/20211108/DMN14.xmi

This is consistent with the scheme applied in DMN 1.2 and DMN 1.3, and in conformance with the "OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces in OMG Specifications - Version 3" (smsc/2018-08-01), which states in particular:

Note: if a spec has many machine readable files, and only some of them change at a given specification version, then only the changed files should get new URIs. That could mean a mixture of URI date segment values for a given specification version.

The current version of the spec is missing a boxed expression visualization and serialization for iterator expressions

Add boxed iterator expression

See attached word document and figures

The current version of the spec is missing a boxed expression visualization and serialization for filter expression

Add boxed filter expression

See attached word document and figures

The current version of the spec is missing a boxed expression visualization and serialization for conditional statement

Add boxed conditional expression

see word document and images

From row 4 it is about syntax sugar for inequality, but is missing the >case (row7).

Fix typo

Fix typo

The standard does not specify if a valid boxed context can contain several context entries with the same key or not.

However, it does specify that if a FEEL context is described via text (see FEEL grammar and 10.3.2.6 Context) the keys are distinct.

Also, how are the names overriden / shaded ?

Clarify that names are unique within a context

Proposal does not explicitly state that names are unique within a context - clarify.

Table 40 contains the folowing row:

Based on the definition given in a previous section it should be

Fix example about conformance of date and date and time

Fix example and remove empty row

for instance append a basic down-to-Earth example like:

replace("banana","a","o") = "bonono"

as already agreed on the DMN TCK.

We found User enquiry about the behaviour of the function, and the only example listed currently is quite techy. Possibly adding a simple example first would help end-users

Add more examples of replace() function

We got User enquiries about the behaviour of the function, and the only example listed currently is quite technical. Possibly adding a simple example first, in addition to the existing technical example, would help end-users.

Second paragraph from the bottom of page 173 contains

have qualified names nbkmi and encapsulatedLogic bkmi.f.

it should be

have qualified names nbkmi and encapsulatedLogic fbkmi.

where bkmi are formatted as indexes (see description of the of the syntax for FEEL function in the naext paragraph).

Correct typo - incorrect indexing

correct indexing

On p. 155, section 10.6.1 incorrectly refers to Figure 10-2. The reference should be to Figure 10-18 which is found on p. 156.

Correct figure reference

On p. 155, section 10.6.1 incorrectly refers to Figure 10-2. The reference should be to Figure 10-18 which is found on p.156.

Grammar rule 52 is using single quote notation, and I believe this is just a typo when submitting the original change.

However DMNv1.3 also missed to exclude grammar 52 from defining Literal terminal symbol.
This is a concerning problem.
This implies rule 52 as defined in DMNv1.3 is defining additional Literal terminal symbol(s) and therefore with DMNv1.3 it is no longer formally possible to name a DRGElement for example: "list of products" or "context of business".
I believe this is an oversight in backward compatibility:

• rule 52 is only used for the technical “instance of” operator which may find limited use by business analysts
• using as a name “list …” or “context …” might be more relevant and wide-spread used, ref examples above

The proposal below addresses this problem as well, making DMNv1.3+ backward compatible again

Proposal

A total of 2 changes.

With reference to DMNv1.3 dtc-19-12-06

Chapter 10.3.1.2 Grammar rules Page 121
replace:

52. type =
qualified name |
'list' '<' type '>' |
'context' '<' name ':' type { ',' name ':' type } '>' | 'function' '<' [ type { ', ' type } ] '>' '->' type
;

with:

52. type =
qualified name |
"list" "<" type ">" |
"context" "<" name ":" type { "," name ":" type } ">" | "function" "<" [ type { ", " type } ] ">" "->" type
;

Chapter 10.3.1.4 Tokens, Names, and White space Page 122
before bullet point:

* A sequence conforming to grammar rule 28, 29, 35, or 37

insert new bullet point:

* for backward compatibility reasons, “list” and “context” from grammar rule 52 are not considered Literal terminal symbols.

Correct FEEL grammar rule 52

Replace inverted commas in rule 52 and include "52" in reference

In the following section, the world 'decision' is misspelt as 'decsion'.

"- Binding contexts in which the value of an expression is bound to a variable with associated type information
(e.g. binding actual parameters to formal parameters in an invocation, or binding the result of a decision’s logic
to the decsion’s output variable). The expression is subject to conforms to conversion."

Fix typo

Fix spelling of decision

Currently the existing functions support: ceiling, flooring and even rounding.

There are uses cases where other type of rounding are needed.

Add extra functions for rounding

Add extra functions for rounding

The DMN 1.3 specification refers to "sub-decisions" in two places (sections 5.3.3 and 10.6.1) but this term is not defined.

Replace sub-decision as a term

Replace the phrases with alternative descriptions

When an Input Data or Decision is represented by an InformationItem that is a collection, there is no visual annotation on the DRD, reducing the clarity of the diagram.

Annotate collections on DRDs

Revise the text to allow a decoration on Input Data and Decisions that are collections.

The instance of grammar does not include the range type, so it is not possible to do `[1..10] instance of range<Any>`. Nor does it support either identifying something as simply a context, or simply as a function.

Please add range<type> to the grammar.

The grammar does support identifying something as simply a context. The list type can be accommodated by <Any>, such as `foo instance of list<Any>`, but the grammar for context currently requires at least one name and type, so simply checking that something is a context is not supported. That is, `foo instance of context<>` is not possible.

Please change the context grammar from `'context' '<' name ':' type

'>' to `'context' '<[' name ':' type

']>'` implying that `context<>` means a context with no entries and thus, all contexts conform to it. Though, a more preferable alternative is described below.

Also, the grammar does not support identifying something as a function, only as a function of a given type - there is no equivalent to `foo instance of function<Any> -> Any`. The statement `foo instance of function<> -> Any` is testing for a function type with no params. This is different to testing purely for a function type.

A grammar to support the above is simply to support the name of each of the types with no `<>` stuff afterwards. Such that `foo instance of list`, `foo instance of context`, `foo instance of function`, `foo instance of range` are all valid. This would be my preference.

Add range to instance of

The changes are baselined on DMN 1.3 dtc-19-12-06.pdf.