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

The examples don't contain extensions

The issue seems to be fixed

Since DMNv1.2 the spec dropped the equivalence of:

[a] = a

because it does not apply to the statement that

a singleton list L, when used in an expression where a list is not expected, behaves as if L[1] is written.

So the expression

[a] = a

on DMNv1.2 is expected to return false.

However, in section 10.3.2.6 Context of the spec, it provides the following statement for the get entries function:

To retrieve a list of key,value pairs from a context m, the following built-in function may be used: get entries(m).
For example, the following is true:

get entries({key 1 : "value 1 "})[key="key 1 "].value = "value 1 "

BUT

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

  by substitution:

[ { key : "key1", value : "value1" } ][key="key1"].value = "value1"
[ { key : "key1", value : "value1" } ].value = "value1"
[ "value1" ] = "value1"

according to DMNv1.2 should be false

By the same principle that the DMNv1.2 for the following literal expression:

[123] = 123

on DMNv1.2 is expected to be false

Defer to DMN 1.6

Defer to DMN 1.6

Situational Data is the set of Data Items and their structures that are needed for the performance and understanding of a Knowledge Package Model.
The details of the Data Items will usually be a subset of the “official” complexity of those items in the environment of the Knowledge Package Model.
For example, the official definition of the Data Item for Blood Pressure (in healthcare) includes more than 50 properties. A Data Item in a Situational Data Model may need only 2 of those properties for execution of the Processes, Cases, and or Decision Services.
Semantic References can be added to link the Data Item to the “official” details.
Uses of the Data Items in BPM+ models that determine the scope of Situational Data include:
Data required for DMN Decisions
Data required for BPMN Gateways transitions
Data required to be passed to/from services invoked by BPMN and CMMN
Data required to trigger Sentries in CMMN
Etc.

Defer to DMN 1.6

Defer to DMN 1.6

A Knowledge Package is mechanism for packaging and distributing a set of BPM+ models (the knowledge)
A Knowledge Package references separate, but connected BPM+ models (BPMN Processes, CMMN Cases, and DMN Decision Services)
KPMN is focused solely on the BMI behavioral standards
A Knowledge Package also contains a Data Item library for the data that will be used by the BPM+ models
A Situational Data Model and Notation (SDMN) is also being proposed as a potential BMI standard to be added to the BPM+ stack (see separate presentation on this topic)
A Knowledge Package also contains metadata about the topic of the package to aid in understanding the content and to find appropriate Knowledge Packages
We are still exploring the relationships between KPMN and Provenance and Pedigree
KPMN includes a diagram to illustrate the scope of the Knowledge Package’s content (a Knowledge Model Diagram)

Defer to DMN 1.6

Defer to DMN 1.6

some built in functions are overloaded in that they can have multiple signatures. So, say, performing an "instance of" to compare against the function "min" is meaningless as the signature is not known unless it is invoked.

Unless the type system is to take into account overloaded functions?

Defer to DMN 1.6

Defer to DMN 1.6

The spec sometimes refers to the temporal precision as milliseconds and sometimes to seconds. Sections 10.3.2.3.3, 10.3.2.3.5 and 10.3.2.3.6 refer to Seconds whereas table 48 offers a semantic of Milliseconds

Defer to DMN 1.6

Defer to DMN 1.6

the builtin function is() refers to this section. It should cover some pos/neg examples of equality vs. identity, and explain aggregate elements in D, e.g. list of structures.

Defer to DMN 1.6

Defer to DMN 1.6

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

Defer to DMN 1.6

Defer to DMN 1.6

The DMN metamodel & the XSD schema do not support definition of function type. For example, a construction as the one below is not supported:

<functionDefinition name='add_type' returnType='number'>
         <parameters>
                <param name='a' typeRef='number'>
                <param name='b' typeRef='number'>
        </parameters>
</functionDefinition>

Duplicates 13-7

Close - already fixed

Rule #66 on page 111 says that a character in a string can be expressed as:

"\u", hex digit, hex digit, hex digit, hex digit

For example "\uD83D"

That is, exactly four hex digits. I believe the intent is that FEEL only allows exactly four digits, and does not allow the kinds of expressions that we see in the EBNF.

What is never specified is the exact meaning of that hex value. There are two possibilities:

(a) Is that value a Unicode code point? In this case it is easy, the hex value is the code point value, however because you are limited to 64K characters, and not the 1.1M character range normally considered, and not even the values that are mentioned in the spec as having significance.

(b) Or is it a UTF-16 code value? UTF-16 has encoding rules about values in the surrogate character range. In UTF-16 a high-surrogate-code value must be followed by a low-surrogate-code value or else the sequence of values is invalid and undefined. Using surrogate characters you can address the entire 1.1million characters but the user is required to understand about surrogate pairs.

The spec never mentions that UTF-16 encoding is required! It always uses "Unicode" and talks about "characters" and "code points". It does not mention anything about surrogate pairs. It never says that these values a "just like Java" or any other UTF-16 implementation.

Page 124 says that the FEEL string value is the same as java.lang.String. Should we infer from that that internal representations must be in UTF-16? however it also says that it is equivalent to an XML string (which is NOT constrained to UTF-16) and PMML string which I looked up and seems to be based on XML. XML allows characters to be expressed as &#nnnn ; That is an ampersand, a hash, a decimal number, terminated by a semicolon. In this case, the decimal value is the actual code point, and not the UTF-16 value. So page 124 does not say unambiguously that Java defines the string values that can be used.

Unicode is mentioned only in three places: on page 108 (about EBNF character ranges), page 111 that tokens are a sequence of unicode characters, page 114 in an example.

While it might be nice to be a "code point", the syntax clearly limits you to four digits leaving you no way to express larger code point values. If it was a code point you would be limited to only specifying 64,000 character (minus several thousand code points that not allowed for various reasons).

The easiest repair is to state clearly that the \u notation assumes that UTF-16 is being used to encode the strings, and that UTF-16 rules must be used when specifying hex values for characters.

I believe most implementations to date have assumed that these are UTF-16 code unit values. That is what Java does. That is what JavaScript does. I don't know of any environments that do anything different for this kind of expression.

Hex values are already properly defined in DMN 1.3

The issue has been discussed and fixed in DMN 1.3 - ballot #10
https://issues.omg.org/browse/DMN13/fixforversion/14682?selectedTab=org.omg.jira.task-forces%3Ataskforce-ballot-panel

https://issues.omg.org/browse/DMN13-127
https://issues.omg.org/browse/DMN13-143

This issue was used by the DMN 1.3 RTF to store the latest version of the convenience documents. The issue got rolled over to 1.4 when the 1.3 JIRA project was closed. However, it has no relevance for 1.4 and does not identify a problem with the spec that needs addressing.

Edits applied to DMN1.2 towards 1.3

Close DMN 1.3 spec placeholder issue

This issue was used by the DMN 1.3 RTF to store the latest version of the convenience documents. The issue got rolled over to 1.4 when the 1.3 JIRA project was closed. However, it has no relevance for 1.4 and does not identify a problem with the spec that needs addressing.

This issue was used by the DMN 1.3 RTF to store the latest version of all metamodel files. The issue got rolled over to 1.4 when the 1.3 JIRA project was closed. However, it has no relevance for 1.4 and does not identify a problem with the spec that needs addressing.

Magic draw files for DMN and DMNDI (diagrams).
The ones with .mdzip suffix and with MagicDraw in the name should be equivalent (both are magic draw formats).
The ones with XMI in the name should be "clean", but some manual fiddling is usually required. I tried to do said fiddling, but no guarantees. Pete Rivett has been helpful in the past.
These were created with Magicdraw 17.0.5. It is out of date, but it's all I have a license for.
The .svg files should be used for all the class diagram figures.

Close DMN 1.3 MM placeholder issue

This issue was used by the DMN 1.3 RTF to store the latest version of all metamodel files. The issue got rolled over to 1.4 when the 1.3 JIRA project was closed. However, it has no relevance for 1.4 and does not identify a problem with the spec that needs addressing.

The spec sometimes refers to the temporal precision as milliseconds and sometimes to seconds. Sections 10.3.2.3.3, 10.3.2.3.5 and 10.3.2.3.6 refer to Seconds whereas table 48 offers a semantic of Milliseconds

Defer to DMN 1.5

Defer to DMN 1.5

some built in functions are overloaded in that they can have multiple signatures. So, say, performing an "instance of" to compare against the function "min" is meaningless as the signature is not known unless it is invoked.

Unless the type system is to take into account overloaded functions?

Defer to DMN 1.5

Defer to DMN 1.5

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

Defer to DMN 1.5

Defer to DMN 1.5

the builtin function is() refers to this section. It should cover some pos/neg examples of equality vs. identity, and explain aggregate elements in D, e.g. list of structures.

Defer to DMN 1.5

Defer to DMN 1.5

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

Defer to DMN 1.5

Defer to DMN 1.5

Situational Data is the set of Data Items and their structures that are needed for the performance and understanding of a Knowledge Package Model.
The details of the Data Items will usually be a subset of the “official” complexity of those items in the environment of the Knowledge Package Model.
For example, the official definition of the Data Item for Blood Pressure (in healthcare) includes more than 50 properties. A Data Item in a Situational Data Model may need only 2 of those properties for execution of the Processes, Cases, and or Decision Services.
Semantic References can be added to link the Data Item to the “official” details.
Uses of the Data Items in BPM+ models that determine the scope of Situational Data include:
Data required for DMN Decisions
Data required for BPMN Gateways transitions
Data required to be passed to/from services invoked by BPMN and CMMN
Data required to trigger Sentries in CMMN
Etc.

Defer to DMN 1.5

Defer to DMN 1.5

A Knowledge Package is mechanism for packaging and distributing a set of BPM+ models (the knowledge)
A Knowledge Package references separate, but connected BPM+ models (BPMN Processes, CMMN Cases, and DMN Decision Services)
KPMN is focused solely on the BMI behavioral standards
A Knowledge Package also contains a Data Item library for the data that will be used by the BPM+ models
A Situational Data Model and Notation (SDMN) is also being proposed as a potential BMI standard to be added to the BPM+ stack (see separate presentation on this topic)
A Knowledge Package also contains metadata about the topic of the package to aid in understanding the content and to find appropriate Knowledge Packages
We are still exploring the relationships between KPMN and Provenance and Pedigree
KPMN includes a diagram to illustrate the scope of the Knowledge Package’s content (a Knowledge Model Diagram)

Defer to DMN 1.5

Defer to DMN 1.5

Since DMNv1.2 the spec dropped the equivalence of:

[a] = a

because it does not apply to the statement that

a singleton list L, when used in an expression where a list is not expected, behaves as if L[1] is written.

So the expression

[a] = a

on DMNv1.2 is expected to return false.

However, in section 10.3.2.6 Context of the spec, it provides the following statement for the get entries function:

To retrieve a list of key,value pairs from a context m, the following built-in function may be used: get entries(m).
For example, the following is true:

get entries({key 1 : "value 1 "})[key="key 1 "].value = "value 1 "

BUT

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

  by substitution:

[ { key : "key1", value : "value1" } ][key="key1"].value = "value1"
[ { key : "key1", value : "value1" } ].value = "value1"
[ "value1" ] = "value1"

according to DMNv1.2 should be false

By the same principle that the DMNv1.2 for the following literal expression:

[123] = 123

on DMNv1.2 is expected to be false

Defer to DMN 1.5

Defer to DMN 1.5

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

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.

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

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.

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/

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

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