section 6.2.1.1 allows elements such as decisions to be labeled with add'l attributes, and does not actually require a label at all. This is unnecessarily general and may cause problems for DI and for using multiple occurrences to avoid line crossings.

DMN12-62 removes other attributes than the name from diagrams

DMN12-62 already contains a text proposal that removes other attributes than the name (or a pretty-printed version of that) from diagrams

Most element inherit DMNElement which includes a label.
Some elements extends NamedElement that extends DMNElement and adds a required name to it.

Some text should be added to the specification to determine how those two attributes should be used.
For example, what should be depicted on a Decision in the diagram?
It’s name or its label?
Is that label really required on all elements?
(please note that a label may contain ctrl char like carriage return where I presume the name would not)

NB (This issue also relate to the upcoming Diagram Interchange (DI) capability coming)

Clarify role of label

1. Clearly define that the name attribute is displayed in the notation
2. Explain label attributes purpose as an alternative short description and that it is not displayed and not to be confused with names, which are used for referencing
3. Should not be used on elements that already have a name

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.

No workable proposal after several discussions over 2 years

How should iteration be visualized at the logic level and at the requirements level?

Modeling with collections of items is fundamental to much business processing (as was noted in various LinkedIn threads). Simple comparisons such as ‘does A,B contain A’ should be done in decision tables using dedicated operators and not require exiting to FEEL and structures external to the decision tables. Several tools already support these operators. While you can write these expressions in FEEL it is useful that a table segregates each row as a rule so that one row matches "list contains both a and b", the next row matches "list contains c, d, and e", etc. We find these representations of the logic to be both common and easily understood by business folks. The proposal is to add ‘Is In’, ‘Contains’ and ‘Contains Any’ operators and their negation (symbols can be used instead of the full operator textual name).

Attached images show this feature used in a business setting.

Examples below of how these operators work (1st element is the Input Expression result and the 2nd is an Input Entry):

returns True

Contains Any

returns True

returns True

Is In

returns False

Expanding the definition of unary test to allow boolean literal expressions

Change section 10.3.1.2 Grammar Rules (for FEEL) as follows:
Add a grammar rule 17d, a 'generalized unary test' as a 4th option for 'unary tests'.
Define 'generalized unary test' in a new grammar rule: generalized unary test = literal expression
In the Semantics section (probably in 10.3.2.8) add:
The name '?' refers to the value of the corresponding input expression, and add another grammar rule (not a syntactic one) that restricts the generalized unary test to a Boolean result:

grammar rule 17.d: FEEL(t')=true, where t' is t with every occurrence of the symbol ? in t substituted with e.

Will require some occurrences of 'unarytests' and 'unary tests' in the spec to be changed to 'generalized unary tests'. Will need examples showing 'generalized unary test' in decision tables, probably in the decision table chapter.

Examples:
1. The Input Expression Order.Total that evaluates to 5, combined with the Input Entry “>0” will result in the evaluation of “5>0” and a “true” result.

2. The Input Expression Order.Total that evaluates to 5, combined with the Input Entry “?>0” will result in the evaluation of “5>0” and a “true” result.

3. The Input Expression 'List of Codes' that evaluates to [“red”, “blue”], combined with the Input Entry “list contains (?,”green”)” will evaluate as “list contains ([“red”, “blue”],”green”) resulting in “false”.

4. The Input Expression Tax.Threshold that evaluates to 100000 combined with the Input Entry “?>gross pay*0.7” will result in the evaluation of “100000>gross pay*0.7” where gross pay is another Information Requirement.

for example, if 'lib' is the name of an imported model, and Input1 is an input data in that model, then one can refer to the input in FEEL using lib.Input1, but this is not specified in 10.4

improve specification of import and qualified names

see attached word doc

The semantics in 10.4 provides a mapping from a decision service to a function definition (which already has execution semantics defined earlier in Ch 10). The mapping does not explicitly consider imported elements. E.g. we could map an imported definition named 're-use this' to a nested context with the same name in the top context.

resolved as DMN12-188

duplicate issue

According to the ItemDefinition specification, an ItemDefinition can be defined in two ways:

• reference to a built-in or imported typeRef
• composition of ItemDefinition via itemComponents

According to the metamodel in Figure 7.6 and Table 23 typeRef is optional and itemComponent has [0..*] cardinality.

That means an ItemDefinition can be defined as

<itemDefinition id="1234" name="name"/>

What is the actual semantics of this type? Is it some sort of a root type in a type system?

To make the semantics more readable and fix some some typos or missing info, I suggest the following:
1. Add missing cardinality for ItemDefintion.itemComponent in Figure 7.6. (missing info)
2. In Table 23 change cardinality of typeRef to be [0..1] to match the metamodel (typo).
3. Add an extra constraint in Table 23 itemComponent row:
When typeRef is missing, itemComponent has at least one ItemDefinition.

Improve type checking semantics

see attached word doc v8

Number for section 10.5 is missing, and title 'Metamodel' is small font

(additional issues, if any, can be added here)

not an issue in the official spec

this is a tracking issue about producing a convenience document.

Currently there are three kind of functions in DMN / FEEL:

• builtin functions (see page 130), strongly typed with optional parameters and var args, with static typing.
• DMN functions defined in the metamodel (see functionDefinition element in xsd schema), strongly typed, with static binding
• FEEL functions defined in FEEL (see grammar rule 57), weakly typed with dynamic typing.

Mixing both static typing and dynamic typing in the same language is not a great idea from the execution point of view.

I am not a fan of dynamic typing mainly because it pushes semantic rules in the dynamic semantics and diminishes the quality of software products (e.g. increases maintenance costs) .

Imagine for example a context that contains an entry x with
function(a, b) a + b
and another one calling
x(1, 2)
The semantic analyzer cannot type check and infer the return type of the definition, it has to wait until the function is invoked. The type of x is partial (unknown parameter types and return types) for the rest of execution.

On top of that the function can be used both for numbers and strings. If the intended behavior changes over time for one use case the user has to write another function anyway.

It gets even harder to handle type checking for external functions.

I suggest adding an a parameter type in rule 58

formal parameter = parameter name ":" type name

where type name is a FEEL type or a complex type (defined via a typeRef)

part of improved types/itemdefinitions

DMN12-216 adds optional types to FEEL functions

Endpoints in SFEEL grammar are

endpoint = simple value ;
simple value = qualified name | simple literal ;

Adding an extra alternative to support function calls will be useful, especially for tests on strings and lists.

A Prolog-like notation can be used to specify the position of the input entry. For example,
contains(?, "abc")

covered by generalized unary tests

the boolean expression containing '?' can invoke functions

Section 8.3.3 Decision rule metamodel do not list the attribute in a table for RuleAnnotation as it is usually done.

Add table RuleAnnotation attributes and model associations

Add the following table to section 8.3.3

Iteration is supported in DMN1.1 using the for..in..return operator, such as

for j in myList return myFunction(j,…)

But this only handles the case where each iteration of myFunction depends only on the value of j, the nth item in myList. It excludes cases where the iteration depends on:

1. The n-1st item in the list, or
2. The nth item of another list, or
3. The result of the n-1st iteration

These are all very common iteration use cases.

add iteration context and 'partial' keyword to for..in..return

Proposal

The solution requires two simple enhancements to the for..in..return operator.

1. Loop on index. Following “in”, instead of the list variable myList use the range syntax a..b, where expressions a and b are integers, for example:

for n in 1..N return myFunction(n, myList,…)

Most often N will be the count of myList and n an index into myList:

for n in 1..count(myList) return myFunction(myList[n],…)

2. Include partial results in the iteration. Much like the built-in variable item is defined for filter expressions, we introduce a new built-in variable partial for iteration, a list variable holding the results of previous iterations, for example:

for n in 1..N return myFunction(n, myList, partial, …)

Typically this would be used in an expression like

for n in 1..count(myList) return myFunction(myList[n], partial, …)

These two small changes allow for..in..return to handle all 3 iteration use cases.

We lack examples of input expressions that are not simple names, input entries that reference variables, and output entries that are more than simple values.
For example, could change fig 67, Eligibility column, from Eligibility||INELIGIBLE|ELIGIBLE to Eligibility=ELIGIBLE||false|true
In Fig 71, add a context entry with name 'Adult' and value '18'. Change the entry <18 to <Adult.
In Fig 83, rename to Adjusted Disposable Income. Add parameter list (Risk Category, Disposable Income). Change output entries to 0.6 * Disposable Income, 0.7 * Disposable Income, 0.8 * Disposable Income, change invocation entry in Fig 82 name to Adjusted Disposable Income and pass Disposable Income. Change Affordability calculation to 'if Adjusted Disposable Income > Required Monthly Installment'

add more examples

more suggested examples

There is a typo in the sublist() function example on page 134. It states:

sublist([1,2,3], 1, 2) = [2]

But the correct would be:

sublist([1,2,3], 1, 2) = [1, 2]

issue subsumed by DMN12-74

issue subsumed by DMN12-74

(from Bruce)
It means addition for most operand types but concatenation for strings. This is another implementation barrier because the mapping from FEEL to another language requires evaluation of operands to determine their datatype. Making + addition only and adding a string concat function would simplify implementation.

changes to FEEL (even small ones) would not be backward compatible

out of scope for RTF to change meaning of "foo" + "bar"

(from Bruce)
one barrier to FEEL implementation is parsing when both variables and built in function names contain spaces. Modelers and tools can elect not to use spaces in variable names but the functions are defined in the spec. Eliminating spaces in builtin function names would simplify parsing. E.g., distinct-values() instead of distinct values(). Xpath does it this way.

changing names of built-ins is not backward compatible

Changing names would not be backward compatible and hence is out of scope for an RTF; and there should be a higher bar to standardize multiple names for the same builtin.

Bruce reports there are many errors in this document:
http://www.omg.org/spec/DMN/20151101/ch11example.xml

new example xml file is part of DMN12-229

Close this as duplicate.

On page 64 (PDF 68) the supporting text says:

Expression is an abstract specialization of DMNElement, from which it inherits the name, and optional id, description, and label attributes.

However, DMNElement does not have a name attribute.

Remove name from attribute list of Expression

See revised text.

The DMN metamodel doesn't seem to match the XSD schema:

Page 37. DMNElement.extensionAttribute[0..*] in metamodel vs otherAttributes in XSD

Page 39: Definitions.collection[0..*] in metamodel vs elementCollection in XSD

Definitions.decisionService[0..*] in metamodel, missing in xsd.

Page 64: ItemDefinition.itemComponents[0..] in metamodel ItemDefinition.itemComponent[0..] in XSD (extra s in metamodel)

Align names in MM with XSD for Definitions/@elementCollection and ItemDefinition/@itemComponent

In MM:

• rename 'collections' to 'elementCollection' in Figure 19: "Definitions Class Diagram"
• rename 'itemComponents' to 'itemComponent' in Figure 31: "Expression class diagram".

The DMN specification says about singleton lists:

• Chapter 10.3.1.4 on page 110: "A singleton list is equal to its single item, i.e., [e] = e for all FEEL expressions e."
• Chapter 10.3.2.5 on page 113: “Therefore, any function or operator that expects a list as input but instead receives a non-list semantic domain element e behaves as if it had received [e] as input.”

This works for most expressions and built-in functions, but for list built-in functions and the sort built-in function the behavior is ambiguous. This leads to different possible valid results for a FEEL expression. The problem here is that the further processing of this result (in DMN and/or other FEEL expressions) leads to different behavior/results of subsequent (boxed) expressions.

Examples of ambiguous FEEL expressions:

• distinct values(["a", ["a"]])
  • possible results: ["a"] or [["a"]] or ["a", ["a"]]
• union(["a"], [["a"]])
  • possible results: ["a"] or ["a", ["a"]]
• index of(["a", ["a"]], "a")
  • possible results: [1,2] or [1]
• count([[]])
  • possible results: 0 or 1
• list contains(["a", ["b"]], "b")
  • possible results: true or false
• min([1],2)
  • possible results: [1] or 1
• flatten([“a”, [], [[]]])
  • possible results: [“a”] or [“a”, []]

Therefore we think, the specification must be detailed to ensure cross vendor interoperability.

Our proposal for DMN 1.2 is not a change of the existing behavior, but a more detailed description of the expected behavior:

Add the following 5 bullet points to chapter 10.3.4.4 List functions before table 61:

• List built-in functions work on the passed lists as they are. A single element may be converted to a singleton list where the parameter domain requires this. (For example count(), list con-tains(), index of()).
• If a built-in function returns a list, any list item originating from the parameters are pre-served, i.e. singleton lists remain (for example reverse(), sort(), min()).
• To operate on list items, singleton lists may be resolved to their single item (for example min(), and(), mean()).
• If a list built-in function identifies list items, FEEL equality is used (for example index of(), list contains()).
• If FEEL equality matches two or more list elements and the built-in function has to decide which equal element should be returned, the function MUST return the element with the lowest position. (For example distinct values())

Additionally the description of the flatten() built-in function should be changed to:

“flatten nested lists and removes empty and nested empty lists”

Additionally it may be helpful to categorize the list built-in functions to the following categories:

• Functions searching for list items:
  list contains(), index of()
• Functions creating a new list with additional or removed items:
  sublist(), append(), concatenate(), insert before(), remove()
• Functions changing the list order of items:
  reverse(), sort()
• Functions operating on list items and calculating a result:
  count(), min(), max(), sum(), mean(), and(), or()
• Set theory functions:
  distinct values(), flatten(), union()

We could add a new column “category” to table 61 or divide table 61 into more tables.

Examples for the above FEEL expressions with the new applied specification changes:

• distinct values(["a", ["a"]]) = [“a”]
• union(["a"], [["a"]]) = [“a”]
• index of(["a", ["a"]], "a") = [1, 2]
• count([[]]) = 1
• list contains(["a", ["b"]], "b") = true
• min([1],2) = [1]
• flatten([“a”, [], [[]]]) = [“a”]

Replace e=[e] with implicit de-listing to avoid argument domain error

See attached word doc

Here is a slight one (typo error) table 6.1, first row: an « e » is missing into « Knowledge ».

N.B. It is more elegant to not cut a table on several pages, as it was done before, but it is another matter.

Unable to find the issue

I do not see a table 6.1 in the spec, nor do I find a 'Knowledge' with missing 'e'.

There is three ways to depict a decision service in DMN 1.2:
Expanded with the divider line
Expanded without the divider line.
Collapsed with the plus maker

However, in the lastest version of the specification (from Ballot 15) in the Decision Service section only 2 depictions are shown: the expanded one, with and without divider line.

To have the last one, we need to add an isExpanded attribute to DMNShape.

Add isCollapsed attribute to DMNShape

See revised text.

The figures in chapter 11 does not match the ch11example.xml file. There are missing requirements, typos and undefined functions.

In order to be able to execute the ch11example.xml file the following erors must be fixed:

• Missing information requirement from "Applicant data" to "Application risk score"
• Missing information requirement from "Applicant data" to "Post-bureau affordability"
• "Bureau call type" decision should have an information requirement from "Pre-bureau risk category" decision and knowledge requirement from
  "Pre-bureau risk category table" should be removed.
• Missing information requirement from "Application risk score" to "Post-bureau risk category"
• Missing information requirement from "Post-bureau risk category" to "Post-bureau affordability"
• Missing information requirement from "Required monthly installment" to "Post-bureau affordability"
• Typo in BKM "Application risk score model": Parameter name should be "Marital Status" (with space)
• Inside "Pre-bureau risk category table" rule 2 and 3 contains wrong expressions for input clause "Application Risk Score". It should be ".." instead of "-" inside ranges
• For the "Bureau call type" decision "Pre-Bureau Risk Category" should be renamed as "Pre-bureau risk category" (as the decision name) on the right.
• For BKM "Affordability calculation" "Disposible Income" should be renamed as "Disposable Income" and for the first context entry "-" minus should be used (not an invalid character)
• In case of "Strategy" decision the input clauses should be corrected as "Eligibility" and "Bureau Call Type" instead of "eligibility" and "bureauCallType"
• For "Post-bureau risk category" decision remove invalid characters from the name of "Application Risk Score"
• The external function "PMT" should be declared. We recommend to add a new business knowledge model "PMT" with a knowledge requirement from that business knowledge model "PMT" to "Installment calculation"

Other issues with already reported errors concerning the chapter 11 example:

• http://issues.omg.org/browse/DMN12-52
• http://issues.omg.org/browse/DMN12-70
• http://issues.omg.org/browse/DMN12-108

Revision of Chapter 11 example

What has changed?

• All decisions and business knowledge model names were uniformized to lower case
• Decision table "Application risk score model" Age input entries were modified to be complete (ie [18..21], [22..25] were changed to [18..22), [22..26) )
• Everything was recaptured to make sure we had the proper naming in parameters in the decision logic
• XML was generated with DMN 1.2 namespace and the complete DI. There is 6 diagrams corresponding to figure 11.2 to 11.7
• PMT function that is invoked in "Installment calculation decision logic" is now defined in its own file (Chapter 11 Example - Financial.dmn) and this file is imported by Chapter 11 Example. The imported BKM was also added to the proper diagrams.
• A figure of the PMT function was added

Footnote 2 of table 61 contains wrong check, therefore change footnote 2, to: "length must be in the range [1..E], where E is L - start position + 1 if start position is positive, and -start position otherwise."

The "+ 1" is important!

Example: sublist([1,2,3],1,3)
--> length must be in the range from [1..3] not [1..2]

Same applies to built-in function substring(), table 60 page 133, footnote 1, second sentence.

correct the range of the length arg of 2 builtins

see revised text

It is said that the numbering of S-FEEL is the same than FEEL specified in section 10.3.1.2, but from rule 33 to 39 it is not the case anymore.

S-FEEL

33 simple literal = numeric literal | string literal | Boolean literal | date time literal ; (should be 34)
34 string literal = '"' ,

, '"' ;
36. Boolean literal = "true" | "false" ;
37. numeric literal = [ "-" ] , ( digits , [ ".", digits ] | "." , digits ) ;
38. digit = [0-9] ;
39. digits = digit ,

;
51. comparison =
a. expression , ( "=" | "!=" | "<" | "<=" | ">" | ">=" ) , expression |
62. date time literal = ( "date" | "time" | "date and time" | "duration" ) , "(" , string literal , ")" ;

Number the SFEEL grammar rules consecutively.

See revised text. Change is editorial only. Does not change the grammar.

The DMN metamodel has Decision with M:N relations that point to BPMN and BMM. This may/will create undesirable referencing issues. While it It is desirable to maintain "loose coupling" between DMN and these external sources (BPMN, BMM, and even CMMN) to do so normally requires these kinds of relations be defined in the caller (or source) rather than the callee (or target). In the particular context of DMN, with respect to BPMN, BMM and event CMMN, the Decision will mostly likely be the target (and not the source). It is recommended to remove the BPMN20::Process, the BPMN20::Task, the BMM::Objective elements from the metamodel and their associated relations and rather make sure that a BPMN, BMM and/or CMMN models can point to a Decision that it uses rather than a DMN Decision pointing to (the potentially not enumerable) places where it is used.

Cannot remove objects from meta-model, would not be backward compatible.

DMN 1.1 models may reference BPMN or BMM elements. These models must also be valid in DMN 1.2. As I understand backward compatibility requirements, this issue is out of scope for an RTF.

This may include both the DRD and boxed expressions (decision tables, etc)

Add Diagram Interchange Chapter and XSD

Add DI chapter and necessary changes to existing spec text.

XSD Changes based on CMMN 1.1 DI:
https://github.com/omg-dmn-taskforce/omg-dmn-spec/commit/d0f469e69a12ccd268c0e24e6d278f7dc6ca9ad9

A more detailed changelog can be found in this Git branch:
https://github.com/omg-dmn-taskforce/omg-dmn-spec/commits/fm-dmn12-62-diagram-interchange

the tables are using 'inputEntry' and 'outputEntry' whereas the MM uses 'inputValues' and 'outputValues'. The MM is correct.

*change inputEntry to inputValues and outputEntry to outputValues *

Apply editing instructions in Revised Text.

according to the UML diagrams in the figures, Decision and InputData do not have typeRefs. They have variables, which are InformationItems, and it is the InformationItems that have the typeRef. Propose to remove typeRef from tables 10 and 15.

remove typeRef from tables 10 and 15

Apply editing instructions in Revised Text.

In DMN, null seems to be used mostly to indicate absence of a value or the presence of an error.

When using the Decision Table hit policies C and C#, failure to match rules in the decision table does not mean either. In such cases, the most appropriate and expected result should be:

• for hit policy C: an empty list
• for hit policy C#: the value 0

hit policies C and C# do not return null when there are no matches

See attached Word file

FEEL has changed between DMN 1.0, 1.1 and 1.2. 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.

New URI for FEEL 1.2

In accordance with the "OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces in OMG Specifications – Version 2" (smsc/2015-3-06) and the DMN 1.2 namespace URIs introduced together with Diagram Interchange, new namespace should be:
http://www.omg.org/spec/DMN/20180521/FEEL/

A lot of use cases of decision logic involve date and time manipulations (e.g. some decision based on the age of an invoice or a person). The current list of DMN functions is too limited to express the logic in a business friendly way.

For example:
floor((today()-Past Date).days/365.25) to compute the age in years of a person, an invoice, a client account etc. (where 'Past Date' is a date)

or worst

floor(((date and time(Past Date,time("00:00")) + duration("P" + string(floor((today()-Past Date).days/365.25)) +"Y") +duration("P1Y")) - now()) /duration("PT24H")) to compute the number of day until the yearly anniversary of person, an invoice, a client account etc.

A list of additional required built-in functions will be submitted as proposal to this issue

Add more built-in functions

Add more built-in functions

It would be useful to save some custom information on import declaration but no extensions are offered on import.

ExtensionAttributes should be added and potentially ExtensionElements.

Make Import MM class inherit from NamedElement

Revise 6.3.3. Import metamodel and Table 6 Import attributes and model associations to reflect Import as subclass of NamedElement.

Make corresponding changes to the XSD.

Backward Compatibility Argument
The new attributes inherited from NamedElement are optional. Import elements that are valid before the change are also valid after the change.

typeRef is a QName which has 2 parts, an optional namespace and a local name.
In XML local name is typed as an xsd:NCName and thus cannot have spaces in it.

In the CH11 example of the spec,
There is a serialization error that lead to confusion about Qname…
ex: line 447 there is a formal parameter with a typeRef to "ex:RiskCategory" but its definition at line 84 is:
<itemDefinition name="Risk Category" id="riskCategory_t">
RiskCategory does not reference neither name nor id (name has a space and id is wrong).

The idea of using prefix:name as QName for typeRef in DMN is problematic as name(s) may contain spaces.

It is recommended to use prefix:id as QName and specify this clearly in the spec so we do not run into the spaces in names problem.

typeRefs and ItemDefinition names are FEEL qualified names

In order that typeRef may reference an itemDefinition as prefixed name, as specified in 7.3.2 paragraph 9 and Table 23, the name of an itemDefinition must be a valid XML NCName, as opposed to the less stringent requirements for other NamedElements. That means it may not contain spaces and other characters used in “business-friendly” names. This is implied but not clearly stated in the spec text.

Abstract
• While this issue singles out typeRef, our proposal provides a common basis for representing both imported item definitions and variables (e.g., BKMs).
• Use name not id to reference item definitions (in typeRef) and variables (in FEEL expressions). Use of id-based references should be limited to DRG elements such as in information requirements or DI.
• To the import element, add the new attribute name, a business-friendly, easily remembered string used as a proxy for the namespace value. The name need be unique only in the importing model, not globally.
• Limit reference of target namespace (definitions/@namespace) to models that import other models. In DMN models without import, the target namespace must be declared but is never used in expressions or typeRef.
• For models that do not import other models, typeRef is just the item definition name or FEEL base type name; there is no change to FEEL expressions. For models that do import, both typeRef and FEEL variable references are [import element name].[local-name]. In DMN1.1 imported variables are referenced as [namespace value].[local-name]. Namespace values are typically URLs containing colon, which is disallowed in FEEL qualified names.

Justification
• Names are modeler-entered values, so they should be business-friendly and easily remembered. ids are tool-generated values, typically globally unique, not business-friendly, and not easily remembered. If typeRef is based on id, tool asks modeler to select item definition based on name but then uses id in the XML. This is OK, since modeler does not see the XML. But the same cannot be said for FEEL expressions referencing imported names, such as a BKM.
• Namespace prefixes in QNames are complicated, since the global declaration in definitions may be overridden locally within the model, so the prefix in effect depends on local scope. Import name is declared once in the importing model.
• Simpler is always better. This is much simpler.

Argument for backward compatibility
DMN 1.1 says that typeRefs are strings with the syntax of an XML QName.
DMN 1.2 says that typeRefs are strings with the syntax of a FEEL qualified name. Because QNames can contain the colon character but FEEL names cannot, isn't this a problem?
Not Really. QNames with a colon character are qualified using a namespace prefix, but in DMN 1.1, there is no standard way to define a namespace prefix for an imported type. DMN 1.2 adds the 'name' attribute to the 'Import' class to fix this problem. In DMN 1.1, only non-qualified typeRefs are specified well enough to work, and these will also work in DMN 1.2.

(on behalf of Bruce)
1. Several functions say N>1 (N is number of list items), but elsewhere spec says a list function with a singleton argument means a list where N=1. Does the table here mean N=1 is an error for these functions?
2. and(list). Examples are incorrect. All 4 examples should be null; the first 2 are the same, and the last 2 are actually undefined if N must be >1.
3. or(list). Ditto 2 above.
4. sublist. Example is incorrect. sublist([1,2,3],1,2)=[1,2]
5. insert before. Example is incorrect. insert before([1,3],1,2)=[2,1,3]

Correct rows 2-8,11 of Table 61

see Revised Text. Note that and() is renamed to all() and or() is renamed to any() as per the resolution of DMN-78.

Changed made to the XSD for DMN12-140 added the annotationEntry but not the clause.

Also, the annotationEntry type was created inline as all other elements have a separate type.

Add missing annotation to Decision table in XSD

Add the following entry right after output in tDecisionTable

<xsd:element name="annotation" type="tRuleAnnotationClause"  minOccurs="0" maxOccurs="unbounded"/>

Remove the annotationEntry element added in DMN12-140

Add the following line right after outputEntry in tDecisionRule

<xsd:element name="annotationEntry" type="tRuleAnnotation" minOccurs="0" maxOccurs="unbounded"/>

Add the flowing complex types after tDecisionRule

        <xsd:complexType name="tRuleAnnotationClause">
               <xsd:attribute name="name" type="xsd:string"/>
        </xsd:complexType>
        <xsd:complexType name="tRuleAnnotation">
               <xsd:sequence>
                       <xsd:element name="text" type="xsd:string" minOccurs="0"/>
               </xsd:sequence>
        </xsd:complexType>

Row 2 describes the subtraction of date and time values. The description in column 3 says "... where value _dt is defined in 10.3.2.3.5 date ...". I think this is a mistake. The reference should be "... where value _dt is defined in 10.3.2.3.6 date-time ...". Otherwise a conversion from date and time to date is necessary and the minimal unit would by days.

Page 132, table 58 lists the following example:

date and time("2012-12-24T23:59:00") - date
and time("2012-12-22T03:45:00") =
duration("P2DT20H14M")

The minmal unit here is minutes.

Therefore I think this is a typo with a wrong chapter reference.

fix typo in chapter reference

see revised text

Table 53 defines the properties for different types. But the types of the properties are not specified.

Specification should be as listed here:

• for date
  • year, month, day (all of type number)
• for date and time
  • year, month, day, hour, minute, second (all of type number)
  • time offset (type days and time duration)
  • timezone (type string)
• for time
  • hour, minute, second (all of type number)
  • time offset (type days and time duration)
  • timezone (type string)
• for years and months duration
  • years, month (all of type number)
• for days and time duration
  • days, hours, minutes, seconds (all of type number)

add type and normalize into 2 tables

See attached proposal.

It should be possible to re-use a decision subgraph by extracting it to another diagram and replacing it with a reference and an invocation to the extracted decision in the original diagram.

Given the current MM, I see two ways of making that possible:

• introducing a sub-type of BKM that allows referencing a decision in another diagram
• introducing a sub-type of Invocation that allows referencing a decision in another diagram

The attachment illustrates the missing and proposed re-use possibilities of the "affordability calculation" (from the example section). The attached example uses the second option of the two.

Allow Decision Service to be invoked from decision logic in a decision model

Revised text is attached as Invocable (Issue 10) - OMG Proposal (version 14).
XML Schema changes described by: https://github.com/omg-dmn-taskforce/omg-dmn-spec/commit/82d171eafa8be4e5659b6e47b46a76a025f15d0d
All figures will be separately attached in the final report as .svg files

Argument for Backward Compatibility
The newly added class (complexType) Invocable is abstract and thus not in the serialization. Concrete attributes are unchanged (except made optional).
Note that before this change, there was no standard way to serialize a decision model containing a decision service; hence, w.r.t. decision services, there is no compatibility to maintain.

Because Decisions, Knowledge Sources, Input Data and BKMs can appear on many diagrams they may have requirements that are not shown on a given diagram. While this is a powerful feature it can be confusing if it is not clear to a user that such links exist but are not displayed. This could be left a a tooling issue but on balance some notation (an ellipsis for instance) that was common woudl probably be more useful.

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.

Specify ellipsis as marker for missing information

See Revised Text

More and more, DMN is being used in conjunction with BPMN and CMMN. The recent work of the OMG BPM Healthcare initiative is a prime example. The Healthcare Field Guide being developed is anchored with the three standards as the way forward for developing healthcare clinical pathways. Feedback from this work and work being done for the VHA using all three standards, is that data notation should be consistent across all three specifications. Thus, the BPMN Data Object, the CMMN Case File, and the DMN Data Input should all look the same since they represent the same general concept to the people creating the models. Further, it will help readers of the models, who don't create them, but are responsible for their implementation within the organization, to understand how the three models work together. Such readers could be hospital clinical informatists.
While there may be technical differences between the data representations among the three standards, these differences are not important to the business analysts who are using the models nor the readers of the models. The general concept of data used within a process, case, or decision is common across the three specs.
Thus, the proposal for this issue is to allow modeling tools to provide an alternative notation for DMN Data Inputs that matches the notation found for BPMN Data Objects and CMMN Case Files.

duplicate of dmn12-44

close as duplicate. Note that dmn12-44 is deferred.

Consider, for example, Figure 84 on pg 158. This table is missing a rule for Age in the range (21..22). For example, for Age=21.5. Note that DMN has a number type, but no integer type, so it is not possible to restrict Age to integers (within the DMN spec, at least). It would be better to use intervals that adjoin, e.g. [18..22), [22..26), [26..36), etc.

use round and square bracket range notation to avoid gaps

close proposal for integer type for now - can open a new issue (in 1.3 for integer types)

Example: a relation "people" with the following content:

people : [

,

]

What is the result of an expression like the following:

people[ age > 20 ]

The filter will obviously evaluate to true for the first person "Bob", but the for second person, age is null, and the expression `age > null` will also return null.

What is the result of the expression?

a. [

]
b. null
c. some other value?

Please clarify explicitly in the spec what is the result of a filter which might evaluate to null for some elements, like the above example.

add example of null filter

see revised text

Some formatting (bold, italics, subscript) has been lost in the 2nd para of 10.3.2.2.

Add formatting as given

See revised text

should work like XML Schema

*merged *

see DMN12-201

Names are unique in DMN. As such there are no need to add syntactical artifacts during the mapping from XML to DMN context.

We propose the following changes:

Table 56

Table 57
Remove "@a": in the FEEL semantic Domain column for rows date, dateTime, time and duration.

Figure 10.3.3.3.3
Change tns$Employee for Employee
Change tns$salary for salary

ignore namespace and prefix in XML mapping

see revised text

I am currently working on DMN and try to reuse xsd file (http://www.omg.org/spec/DMN/20151101/dmn.xsd) in our product. The problem what I have is that I cannot find definition of releation between Definitions and DecisionService inside xsd such as described in the specification page 40.

Is it right or do I misundertand the xsd format?

Fixed by DMN12-10/DMN12-174

This issue has been fixed by DMN12-10/DMN12-174.

A decision with logic: if x then y else z has an unconditional requirement on x but a conditional requirement on y and z. This is useful to represent in the notation (perhaps as a tick mark on the requirement arc in homage to BPM's unconditional gateway exit arc) and in the MM. It could prove very useful to implementors, who could use data-driven dataflow to activate the decision when x is available, but to produce y or z on demand.

withdrawn - no clear proposal or compelling use case

withdrawn by submitter

Normally, a valid executable model requires a value expression for every decision. However, human decisions and external decisions, by definition, exclude a value expression. To allow validation to skip such decisions, an attribute identifying a decision as human or external would be useful.

unnecessary - value expression can be in natural language

According to the spec, one can use the expressionLanguage attribute set to the value http://www.omg.org/spec/DMN/uninterpreted/20140801 to indicate that the value expression of a decision is not to be interpreted.

(from Bruce)
Space in FEEL names is not well-specified. Space (&#x20) is not a name character allowed by rules 30-32, nor is it included in the construction of name from name start and name part|additional symbol (rule 27). But additional syntax rules says single spaces are allowed in names (somewhere). I believe the intent is that “Applicant Data” and “ApplicantData” are both valid names but are not the same name. Specific ambiguities include:

· What is the relationship between space and name part? Does a space always act as a separator between name parts?

· If not, can a name part begin or end with space? Can a name start begin or end with space?

· Related: Do additional symbols also act as separators between name parts, when they do not represent operators?

· Does . act as separator between name parts (when not used as path operator or decimal point)?

· The chapter 11 example (e.g. fig 79) includes things like Applicant data . Age (note space before and after the period). Is this valid syntax?

create new section in chapter 10 for names, tokens, and whitespace processing and improve ambiguity section

see attached proposal

Argument for Backwards Compatibility
All valid DMN 1.1 names are valid in 1.2.

(raised by Bruce)
In DMN 1.1, the target of an invocation was changed from the name of a BKM to any expression, presumably one that results in a BKM name. The reason given was to allow dynamic invocation, for example, if condition1 then BKM-X else BKM-Y. That is a potentially useful thing, but dynamic invocation would require further changes to DMN. In particular, knowledge requirements point to a particular BKM id. Changing knowledge requirement target to an expression would make it difficult (impossible?) to represent the element as a connector in the DRD. Also, the invocation bindings point to specific parameter names, requiring all targets of the dynamic invocation to have the same parameter names.

had discussion, no change needed

no change

It is easy to take advantage of the ability to have multiple DRDs showing the same objects to create multiple layers of detail - a high level DRD, more detailed ones for each "leg" etc. In general this works perfectly with decisions "encapsulating" their dependency network. The one thing that would occasionally be useful is an ability to see how Input Data is used throughout.
For instance, when Decision A requires Decision B which requires Decision C which requires Input Data D it would be useful to see that Decision A indirectly requires Input Data D. A version of a information requirement link that showed an indirect requirement would allow this to be shown without in any way violating or undermining the current approach to reuse across diagrams.

The scope of this issue is limited to "flat" DRDs, that is, no "sub-DRDs" nested inside an outer decision or BKM.

too difficult to do with diagram interchange framework

The DI framework can diagram semantic elements, but here there is no actual element, only an element that can be derived by transitivity. That is not sufficient for DI, and we do not want to materialize all possible transitive links.

This issue is meant to factor-out the "sub-DRD issue" from a number of issues (DMN12-27, DMN12-38) that are actually independent of whether we have "sub-DRDs". There may be better ways or alternate ways of expressing notation and meaning of a 'DRD in a box' but this seems to be a recurring theme so similar issues or competing proposals should be linked here for comparison.

Context is an important form of value expression but tool vendors appear reluctant to implement it, believing it to be not as business-friendly as a DRD expressing the same logic. I propose that DMN 1.2 add a graphical representation of a context, in which nodes represent a context entries, linked by information requirements. A decision whose value expression is a context represented in this way would be indicated in the DRD with a special marker.

The benefits of such a change are these:
1. Increased support for Contexts by tool vendors
2. More business-friendly representation
3. Simpler “top-level” DRD representation of complex end-to-end logic
4. Reusability of more complex decision logic, since BKMs can visualize their value expression in this way.
5. Compatibility with Bastian’s MID proposal 12-27.

Invocable decision service addresses this issue

See DMN12-10

a. In clause 9.2, para 5, first sentence, "date and time" should be in italics.
b. Why is date and time type excluded from S-FEEL? This restriction makes XSD mapping problematic.

No SFEEL changes

Not enough usage of SFEEL to justify change at this time.

We have 2 notations for input data

1. an oval shape

2. the name of input data in the requiring decision (so-called Listed Input Data)

As far as I see, there is nothing in the MM to distinguish these cases,

so there is no way to interchange the intended notation.

Proposed: add a new attribute to Decision named listedInputData of type boolean.

DI supports interchange of listed input data on diagrams

this issue subsumed and resolved by diagram interchange (DMN12-20)

it seems clear from Ch 10 that 'x instance of string' and 'x instance of number', for example, are defined and are true when the value of x is a string or number as defined in Ch 10. However, if the value of x is a context that conforms to some ItemDefinition or XML Schema type, then it is not defined whether this is possible or exactly what it means. We would need to define what it means for a context (and list) to be valid w.r.t. a typeRef. FEEL semantics are execution semantics, and are not validation semantics. A precise statement of validation semantics could be very useful for standardized validation of a model w.r.t. input data (which have typeRefs but not executable input values). However, this is a big job.

better type checking spec covers this

now we have defined instance of on feel constructed types - lists and contexts

There are many reported issues complaining that SFEEL lacks something in FEEL, or with people unhappy with something that is in both FEEL and SFEEL. For example,
The current SFEEL EBNF does not provide for the use of parentheses to set arithmetic precedence of operations.
The current EBNF only supports precedence of operators e.g. 2+3*4 = 14
In Decisions relying on more advanced arithmetic (e.g. Financial decisions related to mortgages or claims) it is desirable to allow the expressiveness of "scientific" calculation to allow the
use of parenthesis to set precedence e.g (2+3)*4 = 20.
It is recommended to add the use of parenthesis in arithmetic expressions and have them set precedence of operations.

recommend full FEEL

See revised text.

Currently the syntax for string literals does not support escape sequences.

Add support for escape sequences in string literals

Change production for string literals in FEEL grammar to add support for escape sequences

Multiple occurrences of shape/element X are currently prohibited in the spec (6.2.1.1). Would be nice to allow multiple occurrences instead of one with many outgoing requirement arrows. This affects diagram interchange, because there would be >1 diagram element per metamodel element. Need a MM element per occurrence in diagram.

DMN12-62 Diagram Interchange allows multiple diagram elements per DMN element.

The latest proposal of Diagram Interchange DMN12-62 removed the following sentence, which was inherited from BPMN and DMN:

Multiple depictions of a specific DMN element in a single diagram are not allowed.

The glossary is not only for CL2. CL3 adds contexts, relations, functions, etc. to the repertoire of boxed expressions

enumerate all the expressions

see revised text.

Excerpt from specification: "For example, FEEL(date and time("03-07-2012Z").year) = 2012"

The string literal format of the date and time string is invaild. It doesn't match XML Schema Part 2 Datatypes as mentioned on page 131 for type date.

Please change the text to: "For example, FEEL(date and time("2012-07-03T00:00Z").year) = 2012"

fix typo in date and time string

see revised text

Page 109 of the specification, 3rd bullet, states:

“A name start (grammar rule 28) SHALL NOT be a language keyword. (Language keywords are enclosed in double quotes in the grammar rules, for example, "and", "or", "true", "false".)"

The specification defines a function invocation on page 108, rule 40, as:

function invocation = expression , parameters ;

The list of built-in functions on page 134 lists both functions “and(…)” and “or(...)” as built in functions, but from the grammar rules mentioned above, it is clear that “and”, is not a valid "expression", and so “and(…)” is also not a valid function invocation.

The same is true for “or(...)”.

Either the functions need to be renamed to use valid identifiers (i.e., identifiers that do not start with a keyword) or the grammar has to be changed to allow for this special case. My personal preference is to rename the built in functions to something like “list and(...)” and “list or(...)”.

rename 'and' to 'all' and 'or' to 'any'

see revised text

Argument for Backward Compatibility
Normally, a change of name of built-in function would be an incompatible change. However, this part of the 1.1 spec proved impossible to implement, because the name of a built-in cannot be a language keyword. I.e., nothing to be compatible with here.

In the metamodel/XSD, decision logic is contained in a decision element, hence not reusable. To reference reusable decision logic, decision invokes BKM, which is reusable. The semantics are clear, but representation of the decision and BKM as separate graphical elements in DRD is visually inefficient. It creates unnecessary clutter in the DRD (Fig 63 is a prime example). BPMN solved this problem in a better way, and I suggest DMN should allow the same. In BPMN a subprocess definition is embedded in the parent process so to reference reusable subprocess, it uses a call activity. The call activity shape is same as subprocess except it has a thick border style. The diagram does not contain both subprocess and call activity, just one or the other. I would like to propose that a decision shape in DRD with a thick border be used to mean the decision invokes a BKM (with name generated from the decision name). No metamodel or schema changes required; this is merely alternative graphical notation. In a DMN tool, typically clicking on the decision will hyperlink to the decision logic (DT or literal expression), whether that logic is embedded in the decision or reusable. This distinction is mostly important to programmers, not modelers, so should not unnecessarily complicate the diagram.

subsumed by invocable decision service

no longer an issue after invocable decision service feature added.

In Decision table, the input extends DMNElement which gives them a label.
However, the spec clearly states that what is depicted on a Decision Table is the input expression (ref: Fig 33), not the label therefore the label attribute is useless .
What should be done with it?

NB (This issue also relate to the upcoming Diagram Interchange (DI) capability coming)

Close as duplicate of DMN12-89

The role of label has been clarified by DMN12-93, which is the proposal for issue DMN12-89.

Grammar rules 2g and 2h indicate that filter and invocation have higher precedence than path expressions. Actually, they have the same precedence are left associative. Suggest combining these 2 rules into 1.

combine grammar rules 2g and 2h

Apply editing instructions in Revised Text.

The DMN Element Metamodel (Fig. 18 in the specification) shows that Decision Services are NOT a subclass of DRGElement. The definition of the DRD requires its components to be DRGElement (“A Decision Requirements Diagram (DRD) is the diagrammatic representation of one or more instances of DRGElement and their information, knowledge and authority requirement relations “). I think the Decision Service should be part of the DRD, especially if it is a callable unit within the DRD (that is, can be linked to a BKM as per DMN12-10/DMN12-135).

fixed by invocable decision service DMN12-10

In the current MM (e.g. see the Ballot13 convenience doc) the DecisionService class extends Invocable which extends DRGElement.

Page 60 para 5 says:
"As explained above, every information requirement at the DRG level is associated with a variable used at the decision
logic level. Each variable that is referenced by a decision’s expression must be a variable referenced by one of the
decision’s information requirements or an information requirement in the decision's requirement subgraph."

Page 177 Glossary entry for "Requirement Subgraph" says:
"The directed graph resulting from the transitive closure of the
requirements of a DRG element; i.e., the sub-graph of the DRG
representing all the decision-making required by a particular element"

From these two entries one could erroneously infer that Information Requirement is transitive in nature. This creates serious concerns for BKMs and Decisions Services.

*Review text section 7.1 to remove potential misinterpretation of transitivity due to subgraph def and so it better reflects meta model *

See revised text.

The classes InformationRequirement, KnowledgeRequirement and AuthorityRequirement do not have an ID. But, they need one in order to reference them in Diagram Interchange.

Make InformationRequirement, KnowledgeRequirement and AuthorityRequirement inherit from DMNElement

Update MM figures:

• Figure 20: Decision Class Diagram
• Figure 22: BusinessKnowledgeModel class diagram

XSD Diff: https://github.com/omg-dmn-taskforce/omg-dmn-spec/commit/fabefaf02122f449d50a235ddc3d8f016202c1b0

Argument for backward compatibility
All added attributes are optional. Thus, a valid DMN 1.1 model, lacking all these new optional attributes, is also a valid DMN 1.2 model.

(from Bruce)
A drg element name is supposed to match the name of the variable owned by the element, but many tools allow the element shape label to be different from the variable name. The spec should clarify whether this is allowed, possibly saying that the shape label is explicitly the label attribute and not the name.

DMN12-93 explains that name is preferred to label if it exists

Also says label is not used in notation. This should clarify any confusion.

The notation for ranges in FEEL currently allows ( ) , [ ] , ][ or combinations to show inclusive or exclusive ranges. The use of ( ) to show exclusive ranges is extremely confusing to non-computer science people. The non-technical assumption is that all ranges are inclusive and the distinction between ( and [ is too minor - it forces people to KNOW where they should be able to intuit.
If we remove support for () but leave support for ][ we don't eliminate the ability to use exclusive ranges, we just make it much clearer.

no change because some people are using the feature

no change

Rules of a decision table have ids but context entries do not. One should be added so it can be reference; for error reporting for example.

Make ContextEntry a DMNElement to inherit its ID

Make ContextEntry a DMNElement in order to inherit its ID.

XSD change: https://github.com/omg-dmn-taskforce/omg-dmn-spec/commit/dc1863fd27b993c908045a8807d756be55dea107

The DMN 1.1 XML schema (dmn.xsd) starts with zero width no-break space character (U+FEFF).

This can be seen with less dmn.xsd:

<U+FEFF><?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://www.omg.org/spec/DMN/20151101/dmn11.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.omg.org/spec/DMN/20151101/dmn11.xsd" elementFormDefault="qualified">
...

Proposal:
Remove the character using sed 's/\xef\xbb\xbf//g' dmn.xsd > fine.xsd

Remove zero-width non-breaking space from DMN XML schema

Remove the character using sed 's/\xef\xbb\xbf//g' dmn.xsd > fine.xsd

Visibility (scope) for variables in Context Boxed Expressions that have a final result box is not clear; The spec does not address whether they are available through dot notation or are they local in scope and not accessible from outside the Context. For Contexts without a final result box it is implied that the variables are accessible through dot notation.

clarify that context entries visible iff no result box

See revised text

Table 37 gives semantics but does not cover empty list

define some... of empty list to be false and every... of empty list to be true

See revised text

Table 45 does not explicitly state semantics of arithmetics for date and duration values

add 4 rows to table 45 (now 49) to account for date input/output

see revised text

on page 109: "Operator precedence is given by the order of the alternatives in grammar rules 1, 2 and 4, in order from lowest to highest."

But grammar rule 2.a and 1.b contains "function definition". Therefore the precedence of a function definition is not clearly specified. Should we use 2.a (lower precedence) or 1.b (higher precedence) for a function definition?

remove redundant grammar rule for function defn and reverse rules 1a and 1b

The current grammar has a duplicate reference to the function definition rule. Rules 1a and 1b are also in the wrong priority order.

This attribute is depicted on boxed function and explain on page 104 but cannot be serialize as it is not part of table 67 presenting function attribute on page 140.

Add kind attribute to FunctionDefinition element

add to MM diagram

XSD Diff: https://github.com/omg-dmn-taskforce/omg-dmn-spec/commit/de4a4ee893b8374ea09395ee9df5a987f18e8189

See revised text for the changes on the attribute table.

Typically, we want to know all the reasons for a conclusion and this requires metadata information about all the Hits even when returning a single conclusion.

For example, for an ‘Any’ Hit Policy Decision Table that results in the conclusion ‘Ineligible’ we want to know that the reasons are ‘Credit score too low’ and ‘Debt-to-income ratio too high’. Similarly, for an aggregated result using ‘Sum’ in the Decision ‘Total Tuition’, besides the total of $1,300, we want to know that the total includes ‘Materials $350’ and ‘Classes $950’.

Possible approaches:
1. Attribute on the Decision Table itself that includes a list of annotation columns to return in full regardless of the Hit Policy.
2. By default, always return all the annotations.

Annotation Outputs

See attached (version 6).
Higher resolution figures attached as pptx.
MM attached.
XSD change linked.

Table 58 on page 131 defines the built-in function date and time(date, time) with parameter name "date" and parameter name "time".

But on page 109 additional syntax rules are listed:
"A name start (grammar rule 28) SHALL NOT be a language keyword."

These two definitions are conflicting.

Since "date" and "time" are language keywords (listed in grammar rule 62 for date time literal) the parameter names are illegal. The invocation of the built-in function with named parameters is not possible:
date and time(date: date("2017-01-01"), time: time("11:00:00"))

The recommendation is to define other named parameter names for the built-in function:

• rename "date" parameter to "date part"
• rename "time" parameter to "time part"

remove date builtins as keywords

see revised text

A row is missing in table 45 to present the addition and subtraction semantic when e1 and e2 are both of type Date.

Clarify semantics of addition/subtraction between dates and date and time values on table 45

Table 45 does not explicitly state semantics of arithmetics for date and date and time values.

The following sentence on page 65 / 69 in paragraph 7.3.2 has been interpreted differently:

"The name of an ItemDefinition element SHALL be unique within the containing instance of Definitions and its associated namespace"

Also, may be common to use same name for input data and an item definition that describes its shape, e.g. PurchaseOrder.

Need to account for namespaces (uniqueness always within Definitions element)

At least, all the 'variables' should have unique names, that is, Decisions, InputData, BKMs, and DecisionServices must have unique names within the containing Definitions. Further, all ItemDefinitions must have unqiue names (but could duplicate an input data, e.g.).

Imported elements are qualified by the name of the import. e.g. short.my-decision + 1

re-phrase unique name constraint for ItemDefinitions

improve description of unique name constraint for ItemDefinitions to make clear that it refers to ItemDefinition only

Table cell of table 58 says that date and time is the needed type, but example in last column uses date. Therefore, please change the text in the Parameter Domain cell to "both are date".

explicitly allow date args to years and months duration builtin

see revised text

10.3.2.11 Function Semantics
FEEL functions can be
 built-in, e.g., decision table (see 10.3.4.6 Decision Table), or

Actually, decision table is not a real builtin function (as DMN12-81 points out), so a better example is something like sum()

should remove textual decision table builtin (ch 10) and use schematic DT boxed expr instead (something like Figure 36)

remove all mention of decision table builtin function

Decision tables are an aggregation of LiteralExpressions, UnaryTests, and other things, but are not actually builtin functions because UnaryTests have no interpretation by themselves. See Revised Text.

I think both mean that 'no mapping is defined' and probably a blank cell would be better. And the text should say 'a blank cell means no mapping is defined'.

replace 'X' and 'TBD' in Table 35 with empty cells

see revised text

change
56. list = "[" [ expression ,

] , "]" ;

add comma to grammar rule 56

see revised text

On page 83 for DMN: "the result of the decision table is the sum of all the distinct outputs"
On page 137 for FEEL built-in function: "return the sum of the outputs"

Same applies to count aggregation.

Why does a DMN decision table only aggregates distinct values, but a FEEL built-in function does not?

Is this difference between the DMN Decision Table in chapter 8 and the FEEL built-in function in chapter 10 the intended meaning?

remove 'distinct' from hit policy aggregation definitions

see attached Word document

page 132/136, in table 58, shows the following example:
time(“T23:59:00z")
The time literal string has a leading 'T'.

Other areas of the spec define time strings as:
"a string value in the lexical space of the time datatype specified by XML Schema Part 2 Datatypes; or a string value that is the extended form of a local time representation as specified by ISO 8601, ..."

As far as I know, XML schema and the ISO standard do not define a leading 'T' for time literals.

Let's clarify this and get all examples consistent.

remove leading 'T' from all time literal examples

remove leading 'T' from all time literal examples

Inputs are said to be a set, and each input is said to contain the input entries. But according to the MM, inputs (really input clauses) are a list, and each input does not contain the input entries, but rather implicitly references the input entries in the rules by position. Similar issue for outputs.

Trouble continues in 8.2.1, where it says there is a double line between input/output expressions and the rule entry cells. There are no output expressions. Probably, given that the clauses in the MM do not include the entry cells (those are contained in the rules), we should say the double line is between the clauses and the rules.

Align text in Ch 8 with metamodel

see revised text

Compare with priority policy. Correct to

if the associated hitPolicy is OUTPUT ORDER, the value of an instance of DecisionTable is the list of the values of the conclusions of all the applicable rules, according to the ordering of the outputEntry in the list
of output values

Remove redundant out of date semantics and point to 10.3.2.8

The 'semantics' in 8.3.1 is redundant with 10.3.2.8. It is also out of date, e.g. there is no 'conclusion' in the metamodel anymore. Let's remove it.

Currently the standard contains a specification of the AST. It does not contain a specification for the CS of the diagrams (e.g. (x,y) coordinates of the DRG elements on the screen).

Having such a specification will make the diagrams portable between different tool providers.

One way of doing it is to have an optional (backwards compatibility) section at the end of the DMN document with DRGElement Views that contain the graphical info (e.g. coordinates, color etc) and references by ID to the AST elements (e.g. DRGElements)

Duplicate of DMN12-20

DMN12-20/DMN12-62 will add Diagram Interchange to DMN.

On page 50 (PDF 54) in Table 14 "BusinessKnowledgeModel attributes and model associations" the attribute variable is defined twice:

Merge duplicate definitions of BKM/@variable in Table 14

Merge the two descriptions into one.

On page 109 (PDF 113) the grammar rule 48 "quantified expression" is missing a comma. It should look similar to rule 46.

Add missing comma in grammar rule 48 "quantified expression"

Add "," to grammar rule 48 similar to rule 46.

Last sentence in Scope section uses both "have" and "has" for the same plural subject "authors".

"The authors have brought forth expertise and experience from the existing decision modeling community and has sought
to consolidate the common ideas from these divergent notations into a single standard notation."

--> Correction: change "has" to ""have".

Change 'has' to 'have'

Fix grammar in one sentence

(raised by Bruce)
By allowing reuse of a value expression, BKMs provide useful semantics. But their representation in DRD adds visual complexity without a lot of value. The Chapter 11 example in the spec is a good example. Representing both the calling decision and the called BKM in the diagram effectively doubles the number of elements in the DRD, while the knowledge requirement connector does not reveal the elements used in the BKM value expression. As an alternative, a distinctive marking in the DRD of a decision invoking a BKM could provide virtually the same information without adding clutter to the diagram. Since DRD is a filtered and truncated view of the DRG, a tool could already do this today, but not in any standardized notation.

*duplicate *

duplicate

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

duplicate

duplicate

Modeling with collections of items are fundamental to much business processing (as was noted in various LinkedIn threads). Simple comparisons such as ‘does A,B contain A’ should be done in decision tables using dedicated operators and not require exiting to FEEL and structures external to the decision tables. Several tools already support these operators. While you can write these expressions in FEEL it is useful that a table segregates each row as a rule so that one row matches "list contains both a and b", the next row matches "list contains c or e", etc. We find these representations of the logic to be both common and easily understood by business folks. The proposal is to add ‘Is In’, ‘Contains’ and ‘Contains Any’ operators and their negation (symbols can be used instead of the full operator textual name).

Attached images show this feature used in a business setting.

Examples below of how these operators work (1st element is the Input Expression result and the 2nd is an Input Entry):

returns True

Contains Any

returns True

returns True

Is In

returns False

duplicate

duplicate

Table 47 gives specific semantics of multiplication and division for various types of operands. It gives a row for division of a number by a duration (e.g. 4 divided by 1 hour) which makes little sense. Instead, the case of dividing a duration by a duration (e.g. 1 hour divided by 15 minutes equals 4) should be specified.

change table 47 to remove number/duration and add duration/duration

Apply editing instructions in Revised Text.

Rule 48 of Feel expression is as follow:
48. quantified expression = ("some" | "every") , name , "in" , expression ,

, "satisfies" ,expression ;

Without a comma, it is really hard to tell when a new “in” part starts. The for expression, in rule 46, does add a comma to split the various in part:
46. for expression = "for" , name , "in" , expression

, "return" , expression ;

Recommend that Rule 48 should be as follow:
48. quantified expression = ("some" | "every") , name , "in" , expression ,

, "satisfies" , expression ;

add comma to grammar rule 48

Apply editing instructions in Revised Text.

The figure 8.18 is NOT the figure of the DecisionTable class diagram (i.e. metamodel).
This diagram was good into the previous beta versions of DMN specification.
This "wrong" diagram was already used as figure 6.8 on page 32 (Decision class diagram i.e. metamodel).

The issue does not exist in the current specification

The MM, now Figure 51, seems fine in OMG formal/2016-06-01

I am developing an application that imports DMN files generated by http://demo.bpmn.io/dmn, in order to get some information about the descision tables.

But, when I try to use the XSD schema to validate the DMN file, I get some errors, for example:

unexpected element (uri:"http://www.omg.org/spec/DMN/20151101/dmn11.xsd", local:"definitions")

Apparently, the path is no longer available. Instead, the OMG site is using http://www.omg.org/spec/DMN/20141115/dmn.xsd

this appears to be a tool issue. The spec is correct.

see further details in the issue.

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.

No agreement about whether this is a good or bad idea

Defer until we can agree to resolve or close.

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

needed, but out of time

Should enhance item definition so it can model function types because that is the type of a BKM's logic

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.

no proposal but possibly still an issue, defer.

Literal expression v. textual expression may be a distinction without a difference.

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.

no simple backward compatible solution was found

perhaps we need to break with backward compatablilty in 2.0

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

similar to generalized unary tests

any boolean expression can be a unary test, so while you cannot enter 20 * rate, you can enter ? = 20 * rate. Defer to make ?= implied if no ? in expression.

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.

cannot change schema for compatibility reasons

reconsider in 2.0?

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.

Need comprehensive set of examples, defer.

Perhaps the next task force can extract some examples from some test cases and add them to the spec.

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.

still no proposals in 4 years, defer.

FEEL chose the simplicity of a single numeric type. Possibly some vendors have extensions, but none has volunteered to make a detailed proposal. There are many numeric builtins and operators; a complete proposal would be somewhat tedious.

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.

Under discussion but no proposal, defer.

See issue comments.

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.

no proposal for this missing feature, defer

Still seems useful.

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

editorial only, can defer

we should identify some typographical conventions and use them consistently.

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

defer for better spec of unary test semantics

defer

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.

did not write proposal to remove global context, defer.

Probably global context can/should be removed, but we did not work out the details.

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

closed by submitter

relevant but out of time

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.

Defer new features without complete proposals due to lack of time

May be more appropriate for DMN 2.0.