This is a trivial typo, and the fix is easy.

Lower on page 108 it says: "the character range that includes all Unicode characters is [\u0-\u10FFF]." This range specified has less than 70,000 characters.

I don't think your intent is to limit implementations to 70K characters and in fact in places (e.g. grammar rule #30) character values larger than this are mentioned.

"all Unicode characters" is actually the entire range of 32-bit values (minus some control codes: hundreds of millions of characters, most of which are undefined). Instead you are defining a SUBSET of this that will be allowed.

Second, the most common implementation of Unicode uses UTF-16, and as a consequences OF THIS ENCODING, the range of representable characters is 0 through 10FFFF. Note that is six hex digits, there are four F digits. There are over a million characters in this range.

(1) Nowhere in the spec does is say you are limiting characters to the UTF-16 range. This should be explicitly stated if that is your intent.

(2) The phrase on page 108 should be changed to; "DMN allows the use of unicode characters in the range of [\u0-\u10FFFF]."

(3) The specification of EBNF character expression should be changed to allow 6 hex digits, currently it says you can only use five digits max.

Allow 4 or 6 hexadecimal digits for unicode code point

See attached word doc

On page 110, rule #66 gives these escape sequences:

string escape sequence = "\'" | "\"" | "
" | "\n" | "\r" | "\t" | "\u", hex digit, hex digit, hex digit, hex digit;

Using the hex character value notation "\uD41A" you can only four hex digits which is not enough to specify the entire Unicode character range. The spec specifically mentions that much higher values are allowed, and there should be a standard way to specify them without having to use the cryptic surrogate character pairs.

This suggestion is to add braces to allow variable length hex values in exactly the way that JavaScript allows:

"\u

"

This is character 128,014 in the unicode set. To specify this character using surrogate pairs you would have to use: "\uD83D\uDC0E" which is complicated and confusing and is currently subject to discussion on whether this is valid or not within the current spec.

"A" = "\u

"

"è" = "\u

"

"査" = "\u

"

"" = "\u

" (Jira seems to crash if I inlcude this character)

It is nice because you actually use the Unicode code point value, and because of the braces you can specify a variable number of hex digits so the entire Unicode set can be easily addressed. The precidence for this syntax is set by JavaScript (

https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

See page 218 where it defines this (slightly translated):

UnicodeEscapeSequence ::
\u Hex4Digits
\u

This will not conflict with any existing implementation since the opening brace was not allowed in earlier implementations. The new allowed syntax could be used in DMN 1.3 and higher.

Addressed by resolution of DMN-127

DMN-127 adds \U, 6*hex digit to address this issue as well

DMN DI allows to depict element more than once. When drawing a diagram, tools need to check graphically the way points to know to which DMNShape a DMNEdge is actually connected to.

Add sourceElement and targetElement to DMNEdge

Add a sourceElement and targetElement to the DMNEdge class so the actual DMNShape used as source and target can be resolved without graphical deduction.

Figure 6.10 has not been updated in line with issue DMN13-140.

Correct fig 6.10 and associated text

Replace figure 6.10 & modify para 2 of section 6.3.1 so that UnaryTests is a subclass of Expression, rather than DMNElement.

The proposal targets the case of a PMML invocation having a single output prediction(s), for the result to be simply the value result of such single prediction, instead of a context with 1 only entry, name of the single output prediction, and value of that prediction.

Do not wrap single values returned from PMML in context

Executive summary

The proposal targets the case of a PMML invocation having a single output prediction(s), for the result to be simply the value result of such single prediction, instead of a context with 1 only entry, name of the single output prediction, and value of that prediction.
This would also align expected invocation behaviour similarly to what RTF agreed on when dealing with Decision Service, ref: https://issues.omg.org/browse/DMN13-163

Rationale and details

By the PMML specification, a ML predictive model can produce multiple outputs, so in general a (FEEL) Context is assumed to be returned by its invocation, containing a key-value pair of prediction name and value.

However,
Most PMML models have a single prediction as output.
To get an idea, can reference examples presented on PMML website: http://dmg.org/pmml/pmml_examples/index.html

Specifically to a well-known example, Iris dataset, Tree model: http://dmg.org/pmml/pmml_examples/KNIME_PMML_4.1_Examples/single_iris_dectree.xml
This would imply every time a Decision invokes a BKM for the PMML prediction, something like:

{ class : "Iris-versicolor" }

is returned, instead of simply getting back something like a FEEL string:

"Iris-versicolor" 

So it would make very annoying for dependent decision the need to always access the single prediction output in the key-value pair:

result.class

instead of more simply:

result

and other analogous implications.

This proposal would align the expected behaviour to what what RTF agreed on when dealing with Decision Service, ref: https://issues.omg.org/browse/DMN13-163 for coercion of the singleton value, in the case of a single PMML output prediction.

Section 10.3.2.3.4 time of the spec already says:
[..] If no time offset is specified, the time is interpreted as a local time of day at some location, whose relationship to UTC time is dependent on time zone rules for that location, and may vary from day to day. [..]

But table 66 show the signature time(hour, minute, second, offset) but does not show the signature time(hour, minute, second) which forces users to write time(08, 04, 32, null) when what they would want to write is simply time(08, 04, 32)

Make offset parameter optional in built-in function time()

In Table 66 page 145 change time(hour, minute, second, offset) for time(hour, minute, second, offset?)

DMN 1.1 should provide examples of all types of decision model allowed by the standard, both graphically (DRD and decision table, where appropriate) and XML serialization. Currently missing:
1. decision tables with an expression (more than a name) in inputExpression and outputExpression.
2. decision tables with inputEntry or outputEntry referencing a "name" as defined by S-FEEL, i.e. not just a literal.
3. DRD and decision table involving what Vanthienen calls "action subtables". All existing examples are "condition subtables".
4. Serialization of crosstab format tables.
5. Representation of literal values vs names in serialization.
6. Representation of PMML and FEEL in the serialization.

Add second example to Chapter 11

See attached word doc for spec changes. See attached zip file for additions to examples.zip.

The spec defines "modulo" FEEL built-in function as: "the remainder of the division of dividend by divisor"
However, this might be subject to ambiguity in the case the Divisor or Dividend are negative, as also mentioned by Wikipedia page which list examples out of several programming languages and systems: https://en.wikipedia.org/wiki/Modulo_operation by saying that "When either a or n is negative, the naive definition breaks down and programming languages differ in how these values are defined".

FEEL aims to be a Friendly Enough expression language, and especially thinking about DMN practitioners who might be used to Spreadsheet based systems might find misleading if the definition of the FEEL "modulo" gets bind to the Java (default) definition, the following table illustrate the difference:

or to other implementation languages where the definition of Modulo/Remainder is not explicit, or the default one is not consistent with Spreadsheet default one.

It is proposed therefore to change the specification in 10.3.4.5 Numeric functions Table 70 for the FEEL "modulo" built-in function
FROM: "Returns the remainder of the division of dividend by divisor."
TO: "Returns the remainder of the division of dividend by divisor. In case either dividend or divisor is negative, the result has the same sign of the DIVISOR."

This would avoid ambiguity by making a clear definition of what should be the sign in case either of the operands are negative.
This should make this consistent with Spreadsheet based system result of "MOD()" expression, which should address being Friendly Enough for DMN practitioners and DM analyst.
This would not make the result the same as the default of Java % operator or BigDecimal#remainder, but Java based implementation/Vendor can trivially address the result to be compliant with the spec.

Improve the specification of the modulo builtin function

The existing specification does not restrict the arguments to integers, and does not clearly define the sign of the result.

Allen's interval algebra defines possible relations between two intervals.
Namely:
before
meets
overlaps
finishes
includes
starts
coincides
after
metBy
overlappedBy
finishedBy
during
finishes

Some more info available here: https://en.wikipedia.org/wiki/Allen%27s_interval_algebra

Add interval builtins, range objects in semantic domain, and compact date literals

See attached word doc

As discussed in the RTF call on Feb 5th, we need to fix:

1.Refs to grammar rules at end of ch9 are incorrect (change 14 to 12 and check others)
2. grammar rule 14 in ch10 is unused and should be removed
3. UnaryTests UML class is missing from the spec (it is shown on one diagram not the defining occurrence
Need to specify this MM class and point to the correct unary tests grammar rule that defines its syntax (this will be different for FEEL and SFEEL)

Fix grammar rule references and add UnaryTests MM

Specification Text
See revised text.

Metamodel

• In Figure 7.6, Change UnaryTests class to inherit from Expression rather than directly from DMNElement
• See attached Fig7_6

XML Schema

• Correct tExpression to make the typeRef attribute optional (as shown in the metamodel of Fig 7.6)
• make tUnaryTests extend tExpression instead of tDMNElement

Backward Compatibility Argument

• Expressions that do specify a typeRef will still be valid when the typeRef in the XSD is corrected to be optional
• UnaryTests that do not specify a typeRef will still be valid because the typeRef is optional

The DMNv1.2 spec reports these two lines examples:

type([{"id": 1,"name":"Peter", "age": 45}])

type(Decision3)

type(Decision4)

type(Decision3)

However concerning the first referenced line, type1

type([{"id": 1,"name":"Peter", "age": 45}])
     ^
  by following the syntax used in table 39 takes the form of the type:

list<context<"id": number,"name": string, "age": number>>

and type2:

type(Decision3)

  by following the syntax used in table 39 takes the form of the type:

context<"id": number,"name": string, "age": number>

So in the first referenced line it is asserted type1 is Equivalent to type2, but a list and a context are not Equivalent by the rule described in section 10.3.2.9.1 Type Equivalence

Similarly for the second referenced line, type 1:

type(Decision4)

  by following the syntax used in table 39 takes the form of the type:

list<context<"id": number,"name": string, "age": number>>

As for the ItemDefinition with the isCollection="true" which therefore obliges the definition that:

IsCollection: Boolean Setting this flag to true indicates that the actual values defined by this ItemDefinition are collections of allowed values.

So again by the section 10.3.2.9.1 Type Equivalence there are no "iff" rules explicited which would make a LIST Equivalent to a CONTEXT.

Analogous issue for the reported values of Conformance.

Can you kindly verify and clarify if needed, please?

Replace 2 rows in table 40

See attached word doc

The spec does not contain a section where the type conversions are described, hence they end-up spread across the spec. For example, a particular case of invocation conversion is described in 10.3.2.5:

Similarly, on a function f( p ) where the domain of the formal parameter p does not include lists, but on an invocation f( pa ) the
actual parameter pa is a singleton list where the type of pa[1] belongs to the domain of p, then pa[1] should be used instead.

Consolidating all of them in one paragraph will make the spec more readable and easier to change in the future (e.g. we want to apply conversions in other context). It will also help us to identify gaps in the spec.

It's a natural step after adding the type relationships in DMN 1.2.

Add extra paragraph to clarify type conversions

see attached word doc

Table 55: Semantics of exponentiation limits the second operand to be an integer. It allow any number.

Allow second operand of exponentiation to be a number

The second operand of exponentiation should be allowed to be a number rather than limited to an integer

Enhance the example in chapter 11 with more realistic metadata attached to the decisions, input data, knowledge sources, etc.

Enhance Chapter 11 example with additional standard metadata

Enhance Chapter 11 example with additional standard metadata, as attached.

Executive summary

The proposal targets the case of a Decision Service having a single output decision(s), for the result to be simply the value result of such single decision, instead of a context with 1 only entry, name of the single output decision, and value of that decision

Rationale and details

with reference to figure from the spec Figure 11.7: Routing Decision Service, the use of the decision service in a literal expression would currently require to write something like:

if Routing Decision Service( ..., ... ).Routing = "ACCEPT" then true else false

please notice specify the .Routing would sound redundant and arguably some may say user-unfriendly in the scenario of a Decision Service with a single output decision.

In the case of a Decision Service with a single output decision, we could more friendly have:

if Routing Decision Service( ..., ... ) = "ACCEPT" then true else false

In other words, the result of invoking the "Routing Decision Service" accordingly to this proposal would be:

Routing Decision Service :  "ACCEPT"

and not:

Routing Decision Service :  { Routing : "ACCEPT" }

as of today.

Naturally when a Decision Service contains multiple output DecisionS, then is always the context, for instance taking example from DMN Spec Figure 11.6: Bureau Strategy Decision Service the result will continue to be:

Bureau Strategy Decision Service :  { Strategy : ..., Bureau call type: ... }

Proposal specification change

With reference to document formal/19-01-05, chapter "10.4 Execution Semantics of Decision Services", page 151
Replace the following:

The execution semantics of S is FEEL(F): a function that when invoked with values from the FEEL semantic domain
bound to the parameters representing input data and input decisions, returns a context consisting of all the output
decisions' output values.

with:

The execution semantics of S is FEEL(F): a function that when invoked with values from the FEEL semantic domain
bound to the parameters representing input data and input decisions, returns:

• in the case of a single output decision(s), the single decision's output value.
• in the case of multiple output decisions, a context consisting of all the output decisions' output values.

clarify that single output decision service does not result in context but rather the single output value

Executive summary

The proposal targets the case of a Decision Service having a single output decision(s), for the result to be simply the value result of such single decision, instead of a context with 1 only entry, name of the single output decision, and value of that decision

Rationale and details

with reference to figure from the spec Figure 11.7: Routing Decision Service, the use of the decision service in a literal expression would currently require to write something like:

if Routing Decision Service( ..., ... ).Routing = "ACCEPT" then true else false

please notice specify the .Routing would sound redundant and arguably some may say user-unfriendly in the scenario of a Decision Service with a single output decision.

In the case of a Decision Service with a single output decision, we could more friendly have:

if Routing Decision Service( ..., ... ) = "ACCEPT" then true else false

In other words, the result of invoking the "Routing Decision Service" accordingly to this proposal would be:

Routing Decision Service :  "ACCEPT"

and not:

Routing Decision Service :  { Routing : "ACCEPT" }

as of today.

Naturally when a Decision Service contains multiple output DecisionS, then is always the context, for instance taking example from DMN Spec Figure 11.6: Bureau Strategy Decision Service the result will continue to be:

Bureau Strategy Decision Service :  { Strategy : ..., Bureau call type: ... }

FEEL has changed in DMN 1.3. We need a way to know which version is used in a model, e.g. by using a new URI for expressionLanguage and typeLanguage.

This is also important, in case FEEL is used outside DMN, because in that case the surrounding model doesn't have any reference to a DMN version.

Update FEEL URI

Update the URI for FEEL to https://www.omg.org/spec/DMN/20191111/FEEL/ as defined in DMN13-187.

FEEL supports function invocation described in rule 40, for example f(a, b, c)

The specification doesn't describe in details how the function is resolved (name of function is bound to the function definition). For example:

• what are the DMN / FEEL artifacts that the call can be bound to (e.g. DMN invocables visible in context)
• how are the name clashes resolved (e.g. both a BKM and a buil-in function have the same signature)
• how are the binding candidates built (e.g. apply all combinations of implicit conversions) and selected (e.g. exact match takes precedence)

Specify how functions are found in scope and argument types are checked

See attached word doc

Please update the copyright section to reflect contributions to the standard by RTF members.

For instance, add Red Hat, Camunda, etc.

Add OMG-confirmed contributors to copyright list

As discussed with Mr. Juergen Boldt, this proposal only adds contributors to the list of copyright holders, who explicitly requested this, got confirmed by OMG, and can show their involvement.

Red Hat represented by Edson Tirelli and Matteo Mortari made the following contributions to DMN:

• 13 Issues raised, many with proposals already included, 9 of them approved
• 3 Proposals created and approved by TF
• Primary contributor to the DMN TCK

Camunda Services GmbH represented by Mr. Falko Menge made the following contributions to DMN:

• Chapter 13 DMN Diagram Interchange (DMN DI) including Meta Model and XML Schema
• 10 Issues raised, many with proposals already included, all of them approved
• 22 Proposals created and approved by TF
• 61 commits to XML Schema, examples and other machine-readable files in GitHub
• Over 400 hours of work tracked
• Contributor to the DMN TCK

Trisotech represented by Mr. Denis Gagne made the following contributions to DMN:

• 34 Issues raised, many with proposals already included, 22 of them approved
• 10 Proposals created and approved by TF
• Contributor to the DMN TCK

This dashboard shows further activities of these contributors: https://issues.omg.org/secure/Dashboard.jspa?selectPageId=10900

The spec should keep track and acknowledge the work of all the people and companies involved.

Update acknowledgments section

Update copyright list with all participating companies

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

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

Update XML Namespaces for DMN 1.3

Update the XML namespaces with the following values:

DMN13.xsd: https://www.omg.org/spec/DMN/20191111/MODEL/
DMNDI13.xsd: https://www.omg.org/spec/DMN/20191111/DMNDI/
FEEL: https://www.omg.org/spec/DMN/20191111/FEEL/

Using this "issue" as a place to post new versions of the spec as we close each ballot. The track changes will be cumulative but comments will map changes to issue numbers. Also posting meta-model files.

Close old meta-issue

This was a place to collect some files for the DMN 1.2 RTF final report and input to the 1.3 spec. It was deferred by default.

section 10.3.2.7 Ranges says that ranges map to the semantic domain. But in DMN 1.1, ranges are unary tests and as such, do not map to the semantic domain. Also, the literal context shown is wrong, as you cannot have the entry 'soon' with value of a range (such value would have to map to the semantic domain).
Now, in DMN 1.2, perhaps we would like to map unary tests to the semantic domain, but it must be all unary tests, and not only ranges.

Proposed remove section 10.3.2.7

Covered by Range builtins

See DMN13-139

If a function definition is the value expression of an information item, then that information item should have an item definition that gives the type of the function definition. E.g., the type of a function of two numeric arguments that returns their sum should be something like function(number, number) returns number but we have no way to express such an item definition

add FunctionItem to ItemDefinition MM, XSD, and spec text

See attached word doc

Group is an unfilled rectangle enclosing various elements in the DRD, with meaning defined by the modeler. It follows the usage defined by BPMN, an “artifact” with no operational semantics, simply an annotation of the model.

Add Group to spec, MM, and XSD fashioned after BPMN

See attached word doc

Section 10.3.2.5 includes a few examples for the filter expression. In particular it shows the following example:
[ {x:1, y:2}, {x:2, y:3} ][x=1] = {x:1, y:2}

The result of this expression is a context (an object). I first thought this must be a mistake, as the filter expression should always return a list.

I then found the following sentence: 'Singleton lists are equal to their single item.', showing that the above expression returns a non-list value by intention.

I wonder how the need for mixing up lists and non-list (with the so called singleton list) has arisen. I have never seem something like it before and I have difficulties to see its value. In addition, I could not find a second sentence in the entire standard that also uses or describes the concept of singleton lists.

Therefore, I would like to propose removing this single sentence about singleton-lists and would like to change the example to look like this:
[ {x:1, y:2}, {x:2, y:3} ][x=1] = [{x:1, y:2}]

Correct the example in 10.3.2.5

The example on section "10.3.2.5" is missing the list operator in the result.

in 10.3.2.7, the literal context example shows third entry where context expression is a unary tests. This is not allowed.

Covered by new Range builtins

See DMN13-139

Imagine the following two date and time values (note that both values are the same instant in time on the time line):

• date and time("2017-11-10T11:00@Europe/Paris")
• date and time("2017-11-10T10:00Z")

If the user uses FEEL expressions he is very surprised about the results:

date and time("2017-11-10T11:00@Europe/Paris") - date and time("2017-11-10T10:00Z")    -> result is PT0S, which means same instant on time line
date and time("2017-11-10T11:00@Europe/Paris") < date and time("2017-11-10T10:00Z")    -> result is false
date and time("2017-11-10T11:00@Europe/Paris") > date and time("2017-11-10T10:00Z")    -> result is false
date and time("2017-11-10T11:00@Europe/Paris") = date and time("2017-11-10T10:00Z")    -> result is false

If the user wants to check if both date and time values are the same instant on the time line he must use the following FEEL expression:

(date and time("2017-11-10T11:00@Europe/Paris") - date and time("2017-11-10T10:00Z")) = Duration("PT0S")

If the user uses a combination of < or > with = the underlying operations are not really understandable:

date and time("2017-11-10T11:00@Europe/Paris") >= date and time("2017-11-10T10:00Z")

This expressions says in the curently defined semantics in FEEL: "Is the left instant of time greater than the right instant in time or are the properties of the left value equal to the properties of the right value".

This is not "Friendly Enough" to the user and the source of very many misunderstandings.

Recommendation:

• Therefore the operators =, !=, <, >, <= and >= should ALL use the defined value functions.
• Additionally we recommend to introduce an additional property "value" for date, time, date and time, years and months duration, days and time duration (see table 53 on page 126). The property returns the value of the value function using type number.
• Introduce a new built-in function "same properties(value1, value2)" that compares all properties of value1 and value2 for equality. This built-in function reflects the currently specified behaviour of equality for date, date and time, time.

use timeline semantics for comparison of dates

see attached .docx file

In chapter "10.6.5 Invocation of user-defined PMT function" the expected result is mentioned as: 3975.982590125562

We think that the expected result should be: 3975.982590125552338278440100112431

If the decimal function would be used the result would be:

decimal(PMT(requested product.rate, requested product.term, requested product.amount),12) = 3975.982590125552

May be the decimal function is missing?

Additional issue: In both cases (with or without the usage of decimal()) the 11th position after the decimal point is a 5 and not a 6. Or is there a rounding mistake/issue?

3975.982590125552

fix result of calculation

The result of the PMT calculation in Section 10.6.5 is incorrect.

(from Bruce)
Table 58 asserts the string constructor operates on any non-null argument, but it does not define the semantics, in particular a)string(list); b)string(complexType). These should either atomize the value and concatenate the strings of the atoms, or report an error or null. Even though Table 58 says null is not in the domain, it also says that string(null)=null. It would make more sense (to me) that string(null)=””.

duplicate of dmn13-27

duplicate of dmn13-27

A number of issues are considering changes to reserved words, built-ins etc. In general these changes should leave the standard case-aware (cases used by a user in naming something should be preserved) but case-insensitive (date is the same as Date and dAte). Any restrictions to names should reflect case insensitivity and interchange should maintain case.

changing semantics of identifiers is not backward compatible

changing semantics of identifiers is not backward compatible

The spec defines "modulo" FEEL built-in function as: "the remainder of the division of dividend by divisor"
However, this might be subject to ambiguity in the case the Divisor or Dividend are negative, as also mentioned by Wikipedia page which list examples out of several programming languages and systems: https://en.wikipedia.org/wiki/Modulo_operation by saying that "When either a or n is negative, the naive definition breaks down and programming languages differ in how these values are defined".

FEEL aims to be a Friendly Enough expression language, and especially thinking about DMN practitioners who might be used to Spreadsheet based systems might find misleading if the definition of the FEEL "modulo" gets bind to the Java (default) definition, the following table illustrate the difference:

or to other implementation languages where the definition of Modulo/Remainder is not explicit, or the default one is not consistent with Spreadsheet default one.

It is proposed therefore to change the specification in 10.3.4.5 Numeric functions Table 70 for the FEEL "modulo" built-in function
FROM: "Returns the remainder of the division of dividend by divisor."
TO: "Returns the remainder of the division of dividend by divisor. In case either dividend or divisor is negative, the result has the same sign of the dividend."

This would avoid ambiguity by making a clear definition of what should be the sign in case either of the operands are negative.
This should make this consistent with Spreadsheet based system result of "MOD()" expression, which should address being Friendly Enough for DMN practitioners and DM analyst.
This would not make the result the same as the default of Java % operator or BigDecimal#remainder, but Java based implementation/Vendor can trivially address the result to be compliant with the spec.

corrected in dmn13-125

corrected in dmn13-125

Table 56 describes the semantics of the instance of operator.

It does not specify the expected result if the instance of expression is incorrect. For example, there is syntactic error, the type name cannot be found (e.g. typo or missing import) or if the type expression is incorrect (e.g. list<> or context<>).

Clarify type lattice L and tie 'instance of' semantics to L

see attached word doc

The specification in chapter "10.3.4.4 List functions" for built-in function stddev does not explicit if it's meant to be population or sample standard deviation.
However based on the example provided "stddev( 2, 4, 7, 5 ) = 2.0816659994661" would indicate it is meant to be the sample standard deviation --which is undefined for a single 1 sample value

In order to be explicit, it is suggested to change the table entry as:

Clarify the semantics of the stddev() function

See revised text.

The specification in chapter "10.3.1.5 Contexts, Lists, Qualified Names, and Context Lists"

presents the following example:

[{a: [{b: 1}, {b: [2.1, 2.2]}]}, {a: [{b: 3}, {b: 4}, {b: 5}]}].a.b =
[[{b: 1}, {b: [2.1, 2.2]}], [{b: 3}, {b: 4}, {b: 5}]].b =
[[1, [2.1, 2.1]],[ 3, 4, 5]]

However line 2 is wrong since DMNv1.2 dropped the equivalence that

a=[a]

therefore line 2 is problematic:

[[{b: 1}, {b: [2.1, 2.2]}], [{b: 3}, {b: 4}, {b: 5}]].b =
 ^ b property is not available here

as at the cursor position is not a context but two items of the root list.

It is proposed to replace the example as follows:

[{a: {b: 1}}, {a: {b: [2.1, 2.2]}}, {a: {b: 3}}, {a: {b: 4}}, {a: {b: 5}}].a.b =
[{b: 1}, {b: [2.1, 2.2]}, {b: 3}, {b: 4}, {b: 5}].b =
[1, [2.1, 2.1], 3, 4, 5]

Fix typo in the example on chapter 10.3.1.5

See revised text.

The spec says: Three-valued logic (true, false, null) based on SQL and PMML
This statement can lead to misinterpretation (given their understanding of the SQL and/or PMML three value logic) for nothing given that we define the semantic of the FEEL three Value logic clearly below.

Remove reference to SQL and PMML three value logic

This reference to SQL and PMML is not needed and may lead to misinterpretation. Simply remove that reference.

In section "10.3.2.6 Context" two built-in functions are described: get value(), get entries().
However these functions are not summarized later in section "10.3.4 Built-in functions"

Describing all built-in functions in latter section "10.3.4 Built-in functions" is important to agree on the function parameters name.

Agree on the function parameters name is important for invoking function and binding parameters by name, rather than positional.

I propose to add a new section inside "10.3.4 Built-in functions", with the following:

10.3.4.x Context function

Table xx defines Context functions.

Table xx: Semantics of Context functions

get value({key1 : "value1"}, "key1") = "value1"
get value({key1 : "value1"}, "unexistent-key") = null

get entries({key1 : "value1"}) = [ { key : "key1", value : "value1" } ]
get entries({key1 : "value1"})[key="key1"].value = "value1"

Add get entries() and get value() functions to the function tables in chapter 10

See revised text.

The above section mentions to two context-related functions "get value" and "get entries" that are not in the built in functions list. Are they meant to be there?

duplicate of dmn13-126

closed as duplicate

The spec example shows a function definition inline in a literal expression using sort(). My take on the FEEL grammar spec is that a function definition can only exist inside a boxed expression, not inside a literal expression. A function definition inside a literal expression whose body has names with spaces or additional characters makes the parsing of the entire expression before execution darn hard - we'll I haven't figured it out anyways.

In the specific case of the sort function, the type of the 'list' parameter may only be known at execution time, and thus the types of the arguments to the 'precedes' function can only be known at execution time - that is, when actually executing the sort. And to execute a sort, you need to pass it its arguments - which means a parsed function definition. If that function definition has names with spaces, then parsing can't be done until the types are known - during the sort execution. A little bit chicken an egg.

But, if I read the spec correctly, you should not be able to have a function definition inside a literal expression. In which case, it is parsed separately to its invoking function and the above is not an issue.

As a note, the given example and some tests in the TCK (which I am not sure should be there) involve simple params or simple names and can be parsed. But the scenario above is not covered by the TCK.

Happy to be guided otherwise. An all advice appreciated.

change grammar rule 2.h. in ch 10 to use expression instead of textual expression

see revised text

Typo in rule

51. comparison =
a.expression , ( "=" | "!=" | "<" | "<=" | ">" | ">=" ) , expression |
b.expression , "between" , expression , "and" , expression |
c.expression , "in" , positive unary test ;
d.expression , "in" , " (", positive unary tests, ")" ;

c. should have | at the end not ;

We should replace non-terminal Boolean literal with boolean literal for consistency.

fix minor typos in FEEL grammar rules

see attachment

Fig 11.28 on page 179 of formal-19-01-05 shows a screenshot of Applicant Data.
The values of Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses are inverted, if the end result of executing the model is for decision Routing = "ACCEPT".

In other words; currently the PDF document display as:
Applicant Data.Monthly.Income = 10000 (ten-thousands)
Applicant Data.Monthly.Expenses = 100000 (a-hundred-thousands)
but actually it should be:
Applicant Data.Monthly.Income = 100000 (a-hundred-thousands)
Applicant Data.Monthly.Expenses = 10000 (ten-thousands)
if the decision Routing should evaluate to "ACCEPT".

Also, check spelling of "Stragegy" in Fig 11.30

*Replace erroneous figures *

Monthly.Income and Monthly.Expenses corrected in figure 11.28
Typo corrected in figure 11.30

It is possible for a FEEL expression to generate a value with no possible datatype (as they are currently defined). Here are some examples:

1. If x>0 then x else ‘value must be greater than 0’

2. [0,’a’]

3. [0,[1,2]]

In the first case the result is either a string or a number. In the second case it is a list (collection) where the items are of different types. In the third case, which is more borderline, the collection items include a number and a list, again not the same type. The third case also relates, I believe, to DMN12-115.

The rules for item definition, in combination with FEEL base types, do not support any of these cases. That means a variable with these values cannot have a typeRef. Some implementations may depend on the typeRef to compile the expression properly, and/or may prevalidate to ensure that a typeRef is provided.

I suggest one or more of these as possible solutions:

1. Allow item definition to include a union of existing types, e.g. number or string

2. Allow typeRef to be a list, e.g. feel:number, feel:string

3. Add new base type, anyAtomicType, meaning any of the FEEL base types.

We support homogeneous list types. Need better justification for heterogeneous list or union types.

DMN 1.2 adds type lattice, supports homogeneous list types like list<string>, promotes heterogeneous list types to list<Any>, which is good enough, unless more evidence to the contrary is presented.

Qualified name and path expression uses both the dot '.' character. Therefore it is very hard to distinguish between these cases.

Example:

• {p:{name: "jack"}, persons:[p,p].name}.persons

  results to

  ["jack", "jack"] 

• {p:{name: "jack"}, persons:[p,p], path : persons.name }.path

  results to

  ["jack", "jack"]

  (or is dynamic path access not possible in FEEL?)

• {p:{name: "jack"}, persons:[p,p], qn: p.name }.qn

  results to

  "jack"

Not an issue

All listed FEEL examples are valid FEEL expressions. Example 1 shows a path expression, example 2 a qualified name with an implicit path expression.

The FEEL syntax allows qualified names as type for an instance of expression. But the semantic mapping is not specified. Therefore, is this a valid FEEL expression:

{a: {b: 1}, c: 2 instance of a.b}.c

and this the corresponding result: "true"?

What types can be used for instance of? Only datatypes (like string, number, ...)? Can we use kinds (list, context, ...), too?

Since singleton lists are equal to the single element and kinds are allowed for instance of, everything is instance of list, am I right?

clean up specification of types, and add syntax for parametrized context, list, and function types

see attached documents

The semantic mapping is not accurately specified for the "in" expression. What datatypes, kinds can be used as iteration source. Only lists and single elements? Is it possible to iterate over context entries of a context? Are there any other datatypes that must be considered?

Issue addressed by "iteration context" added in 1.2

DMN 1.2 added the notion of "iteration context" and is described in 10.3.2.14. This seems to address the issue.

The definition of decision service in 6.2.5 says this:
_The border SHALL enclose all the
encapsulated decisions, and no other decisions or input data. The border MAY enclose other DRG elements but these
will not form part of the definition of the Decision Service._

This is a problem because it is not possible to omit the Input data if they are input to encapsulated decisions and they use the listed input data option.

spec is clear enough

No change needed. The current spec is clear about listed input data and the use of listed input data in a decision service would be unambiguous and is clearly allowed.

Input Entries are defined as unary tests and as such do not allow even simple expressions. The need to exit the decision table into other FEEL constructs for simple expressions such as “Dividend Income * 0.30” makes the overall logic less readable. There are currently several tools that support expressions in decision table cells and this feature is also on Jan and James’ wishlist. The latter wrote about in more detail (http://blog.luxmagi.com/2016/04/our-dmn-2-0-wish-list-i-decision-logic/) so I won’t repeat it except to quote “This is something we see a lot of demand for by business users of DMN ‘in the field’.”

Support expressions in DT input entries

This is already supported in DMN 1.2. A positive unary test can be an Expression.

FEEL date type is presented in section 10.3.2.3.5 however in some sections of the specification where all FEEL type are enumerated, the date type is omitted.

• Section 7.3.2
  If the type language is FEEL the built-in types are the FEEL built-in data types: number, string, boolean, days and time duration, years and months duration, time, and date and time.

• Section 10.3.1.3
  FEEL supports the following datatypes:
  • number
  • string
  • boolean
  • days and time duration
  • years and months duration
  • time
  • date and time

• In section 10.3.2.12, it is not part of table 42

• Date is part of S-FEEL and this paragraph from section 9.3 should probably be modified too:
  S-FEEL does not support FEEL date and time. However, it supports the date type, which is like FEEL date and time with hour, minute, and second required to be absent. The lexical and value spaces of FEEL date are the literal and value spaces of the XML Schema date datatype.

add missing 'date' type in several places in spec

see revised text

First page of spec contains broken links:

Link http://www.omg.org/spec/DMN/20151101/dmn.xmi
In the PDF document seems to be broken. It contains a space after “spec/”.

Link http://www.omg.org/spec/DMN/20151101/ch11example.xml
in the PDF document seems to be broken. It contains a space after “spec/”.

Fixed on OMG website

This has been treated as a broken link and fixed by OMG on their website. No action needed by RTF.

Most is described after Table 46 Needs to be moved just after Table 44.

move 2 paragraphs following Table 46 to before Table 45

move indicated text

These additional symbols do not provide much more expressiveness for name and may create a lot parsing issues

non-backward compatible FEEL grammar change

would need 2.0 RFP

The sample provided at http://www.omg.org/spec/DMN/20151101/ch11example.xml contains the following namespaces defined at the root level:

xmlns:ex="http://www.omg.org/spec/DMN/20151101/ch11example.xml" xmlns="http://www.omg.org/spec/DMN/20151101/dmn.xsd" namespace="http://www.omg.org/spec/DMN/20151101/ch11example.xml"

FEEL is not included, hence when used to define types it is used as

<typeRef xmlns:ns2="http://www.omg.org/spec/FEEL/20140401">ns2:number</typeRef>

Adding it at the root will make the xml more user-friendly.

FEEL namespace is in the header of sample XML files in DMN 1.2

please verify and let's close

The sample XML specified on the first of the spec contains a typo.

Sample is http://www.omg.org/spec/DMN/20151101/ch11example.xml

Strategy is misspelled. See below:

<itemDefinition name="Stategy" id="strategy_t">
<typeRef
xmlns:ns2="http://www.omg.org/spec/FEEL/20140401">ns2:string</typeRef>
<allowedValues>
<text>"BUREAU","DECLINE","THROUGH"</text>
</allowedValues>
</itemDefinition>

no "Stategy" in DMN 1.2 sample file

This seems to fixed in 1.2. Please verify, and let's close.

The first page of the spec contains several HTTP links. Some of them seem to be broken due to an extra space.

Link http://www.omg.org/spec/DMN/20151101/dmn.xmi
In the PDF document seems to be broken. It contains a space after “spec/”.

Link http://www.omg.org/spec/DMN/20151101/ch11example.xml
in the PDF document seems to be broken. It contains a space after “spec/”.

merge with DMN13-67

duplicate

SFEEL and FEEL grammar are ambiguous due to “additional name symbols”. For example,

• Person.Loan is a Name or Qualified Name?
• Loan+123 is a Name or an Expression ?

I don’t think the “additional name symbols” add much value when it comes to having business friendly name. If we want to keep them, we should use the SQL approach and disambiguate these identifiers with quotation marks. For example, ‘Loan+123’ is an identifier while Loan+123 an expression.

non-backward compatible FEEL grammar change

would need a 2.0 RFP

The grammar contains several sub-grammars each one with its own start non-terminal: expression, simple expressions, simple unary tests.

The grammar should be broken in 3 grammars, and common part to make things more obvious. It will make the grammars more readable and help the CL3 implementation. The spec should also specify for each grammar where it used (e.g. unary tests are used in the Input Entries of a Decision Table etc).

SFEEL is deprecated

No editorial changes for SFEEL

Naming inconsistency in Figure 70.

Use Pre-bureau instead of Pre-Bureau or change Post-bureau to Post-Bureau.

Ch 11 figures are machine-generated in DMN 1.2, should be consistent

Can someone recheck Ch 11 for consistency, and if OK, let.s close this.

The example file http://www.omg.org/spec/DMN/20151101/ch11example.xml with document number dtc/15-11-55 does not correspond to the figure 70 on page 147 in chapter 11.3 of the DMN 1.1 specification with document number formal/2016-06-01.
The figure shows an information requirement from decision "Bureau call type" to decision "Pre-bureau risk category", while the XML has an information requirement from decision "Bureau call type" to business knowledge model "Pre-bureau risk category table" in line 972.
The figure shows a knowledge requirement from decision "Routing" to business knowledge model "Routing rules", while the XML has an authority requirement from decision "Routing" to business knowledge model "Routing rules" in lines 1331-1333.
I suggest to correct the XML example file.

Chapter 11 example xml has been fixed

Fixed in 1.2 (generated from same tool)

The FEEL syntax grammar rule 45 only allows names for a path expression. Is this the real intention or should qualified names be allowed, too?
Otherwise only top level context entries can be accessed.

If only name is allowed, the following example is not possible: "{a:{b:1}}.a.b"

submitter agrees there is no issue

no issue here

FEEL grammar rule 2.i for simple positive unary test is ambiguous if no operator is specified. An endpoint is an simple value which can be a simple literal. Additionally the literal specification in grammar rule 2.i can be also a simple literal. This is ambiguous and should be changed.

ambiguity per se is not a serious issue

there are other ambiguities that are resolved with semantic checks or other rules.

3rd bullet enumeration on page 71 says:
A set of inputs (zero or more). Each input is made of an input expression and a number of input entries.The
specification of input expression and all input entries is referred to as the input clause.

I blieve it should read:
A set of inputs (one or more). Each input is made of an input expression and a number of input entries.The
specification of input expression and all input entries is referred to as the input clause.

0 input tables (with collect policy) behave as relations

may be useful for level 2 implementations

The purpose of the ‘Any’ Hit Policy is to allow for overlapping criteria in the rule conditions for the same conclusion. However, each rule also needs to allow for different additional information and messages that are specific to that rule. See attached example decision table. The current text in the specification does not allow for this.

Currently, ‘Any’ is defined in section 8.2.11 as: “Any: there may be overlap, but all of the matching rules show equal output entries for each output, so any match can be used. If the output entries are non-equal, the hit policy is incorrect and the result is undefined. “

Proposal to change the above text to: “Any: there may be overlap, but all of the matching rules show equal output entries for the left-most output column, so any match can be used. If the output entries are non-equal for the left-most output column, the hit policy is incorrect and the result is undefined.“

DMN 1.2 provides annotation columns as well as result columns

annotation columns are not considered in hit policy semantics, they can differ for the ANY policy

Clause 10.3.2.9 shows FEEL number values as mapped to XML decimal, integer, and double, but the only mapping to Java is to BigDecimal. The appropriate mapping to Java, like the appropriate mapping to XML, depends on the range and intent of the data element. BigDecimal is rarely used for anything but currency. Java int and double are much more likely to be appropriate for most data items. The mapping of number to Java should be just as flexible as the mapping to XML and PMML.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

If FEEL variable names can contain spaces, they should not be allowed to contain operator names like and, or, etc. for example the name "make and model" in the Collections of Cars example should not be allowed. It might be possible to determine from the context whether this is a name or an expression of 2names, it's just too hard.

non-backward compatible FEEL grammar change

would need 2.0 RFP

Decisions in DMN are actually expressions in a formal language (by default, FEEL). These expressions describe a range of computations and calculations, including constants like 42, calculations like (x-y)/2, and decisions using decision tables. It's awkward referring to constants and math formulas as 'decisions', but most of the time, decision is the right word. Should we allow some 'decoration' of the decision rectangle (e.g. an icon) to indicate whether it is a constant, a calculation, a decision, etc.?

Another observation - InputData and BKM are not really needed to build a working DMN product. Decisions can be used instead of InputData. All your decision services would use input decisions instead of input data. Decisions can be used instead of BKMs, as there is no prohibition about a decision's logic being a FunctionDefinition. This means that decisions can invoke other decisions or simply reference them. Either way, there is an information requirement.

withdrawn by submitter

Do not see much value here.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

Having spaces and additional characters in useful from a user / BA perspective. However, is not good practice when it comes to implementing / designing programming languages / DSL. That's mainly due to ambiguities introduced by this approach. This is the reason none of the main stream PL do not support this feature.

I suggest the following approach:

• use spaces and additional characters in labels to improve the usability of FEEL (display labels in DRD diagrams)
• if the name of a DMN entity (e.g. decision) contains a a space of additional character, use ' as delimiters. For example, 'A nice decision name ?'
• reference ItemDefinitions by id and not by name to avoid ambiguities.
• use the same delimiters to handle FEEL keywords as names (e.g. an OutputClause has name/label date)

The same approach has been used successfully for SQL and OCL. OCL 2.4. specification is here
http://www.omg.org/spec/OCL/2.4/

non-backward compatible change to FEEL and metamodel

would need to wait for 2.0 RFP

null is not defined in the S-FEEL grammar.
But it could be obtained as an input to a decision table so it would make sense to allow this value in the decision table as unitary test.

we decided in DMN 1.2 to "deprecate" SFEEL.

We should not change SFEEL anymore.

(on behalf of Bruce)
On p122 it says "In Grammar Rule 51c, the qualified name must evaluate to a comparable constant value at modeling time, i.e., the endpoint must be a literal or a named constant". This says variables, except design-time constants, may not be used in decision tables. I think this constraint is not supported by the grammar and eliminates important functionality. Any name in scope should be allowed.

No longer an issue

I don't see the prohibition against variables in the current spec. It may have been lifted by the introduction of generalized unary tests. Let's close if no longer an issue.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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?

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

This is a suggestion for future revisions of the specification:

Change the grammar to allow expressions to be used as "end points" on ranges and unary tests. E.g.:

This is extremely useful for users that no longer have to create dummy variables in order to use expressions as "end points".

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

The processing of lists of data is fundamental to business decisions. Some kind of multiplicity should be indicated at the DRD level, and iteration should be supported visually at the decision logic level. In spite of the attached figures (meant to provoke discussion), the scope of this issue is limited to "flat" DRDs, that is, no "sub-DRDs" nested inside an outer decision or BKM. DRD proposal should specify what the multiplicity marker or other DRD notation looks like, and where it may appear, e.g. attached to head or tail of a requirement arrow, or inside a decision or BKM shape left of the name, etc.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

literal expression is used in MM, and textual expression is used in grammar. Let's use 1 consistently, but check that they are really the same concept.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

The expression of the PMT function contains an invalid character and is therefore not executable. The first minus character is a dash, but shouldn't.

(amount rate/12) / (1 – (1 + rate/12)*-term)

Fixed:

(amount rate/12) / (1 - (1 + rate/12)*-term)

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

FEEL grammar is ambiguous. Rule 2.i is ambiguous for identifiers like Person, as it can lead to two parse trees, one with QualifiedName the other with Name in it. See rule for simple value.

Rule 1 is ambiguous as there is an overlap between textual expression and boxed expression. I suggest breaking the grammar in several grammars with a common part. This ambiguity will just go away as soon as we do that.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

We need to be able to compare to the current date and time
e.g.
Now() as a unitary test
or
Now() = a specified date and time

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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?

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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?

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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?

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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?

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

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.

RTF 1.3 is ending

Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.