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.

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?

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.

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

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.

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

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

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.

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

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

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.

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

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?

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?

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?

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?

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.

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.

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.

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

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.

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.

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

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.

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

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