The terms of clause 10.2.1 with respect to interpretation of Kind values are not normative.
Similarly, the syntactic and semantic requirements for external functions in 10.3.2.11.2 are not phrased normatively.

The text of Clauses 10.2.1 and 10.3.2.11.2 is rephrased to clarify the normative requirements

figures 81 and 84 (in beta3) are boxed contexts. Boxed contexts cannot be BKMs. They lack the mandatory parameter list, in a box just beneath the name box.

add parameter lists to Figure 81 and 84 so they are valid boxed function definitions.

The Collect operators are listed as sum, min, count. We agreed that max should have been included.

Add max to the collect operators.

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.

The FTF recognizes that the choice of BigDecimal may not be ideal for many Java functions, but it can support any required values. The alternative is to allow more user control of the mapping of FEEL datatypes to programming languages. This would involve creation of additional capabilities for external functions that will be better addressed after there is significant user and implementation experience. Therefore the FTF prefers to defer this issue.

10.3.4.3 contains the following:

Additional constraints on input domains:
1. start position must be a non-zero integer (0 scale number) in the range [-L..L], where L is the length of the string. length must be in the range [1..E], where E is L – start position if start position is positive,
and –start position otherwise.
2. flags must be …

(2) needs to be completed or removed.

Table 56 (beta3) refers by superscript 2 to the 'additional constraints on input domains' (but for some reason these constraints are before the table - maybe should be after - and there are several tables with these additional constraints, they should be consistent). Constraint 2 should be as revised. We need a normative reference to XPath 2.0 http://www.w3.org/TR/xpath-functions

Clause 10.3.1.3 says:
"FEEL supports the following datatypes:
...

• duration
  o days and time duration
  o years and months duration"
  But 10.3.2 only defines the two subtypes, which correspond to XPath Datamodel datatypes, which are respectively integer counts of seconds and months. It does not refer to the XML Schema 'duration' type.

Similarly, the "duration" function in clause 10.3.4.1 requires the string value to be in the lexical space of one of these two subtypes, not that of xs:duration, per footnote 6 to table 54 (beta-3) [Note: the footnote erroneously refers to Xpath. It should be XDM.]

It is apparently not intended that a supporting tool needs to support xs:duration at all. For that reason, the supertype 'duration' should be omitted from the list in 10.3.1.3. Alternatively, it might say that support for the more general 'duration' type is not required.

Finally, 10.3.4.1 defines a function that produces a yearMonthDuration as the difference between two date/time values (which presumably truncates the duration result), but no function that produces a dayTimeDuration (which could be exact). This is a shortcoming for stating rules relating to elapsed time.

Remove 'duration' from the list in 10.3.1.3 and elevate the two sub-bullets:

• years and months duration
• days and time duration

The reference to classes BMM::Objective, BPMN::Process and BPMN::Task does not seem to work in the metamodel XMI file

DMN metamodel references BMM and BPMN, and the XMI will not validate due to unresolved refs.

page 50 -> usingProcess, usingTask not on diagram
page 51 -> usingProcess, usingTask not in text
page 52 -> in table replace usingProcesses and usingTasks with usingProcess, usingTask

Add attributes in text and diagram

In 10.3.2.11, Table 41 (beta-3), in the row for date-time + year month duration, the operation definition adds seconds to months.

In the same table, in the row for time +/- day time duration, it is easily possible to get a result that is not in the value space of time [0s, 86400s], and it is not clear what inverse value-sub-t returns.

In table 41, the description of date time +/- years and months duration is corrected.
In 10.3.2.3.4, constrain the inverse of value\t to [0, 86400], by taking the operand modulo 86400.

DMN Beta 4

There are 4 lists of 'Additional constraints on input domains' (tables 55, 57, 58, 59). The list of additional constraints is meant to be like a footnote to the table, and should be after the table. (In 10.3.4.1, Table 55, all the additional constraints were rewritten by Issue 216. In 10.3.4.3, one of the additional constraints was rewritten by Issue 200. And the text of issue 19 has the additional constraint after the table; so the moving up and moving back should never have happened.)

undo the unauthorized editorial change (of mysterious origin) in Beta-3 that moved the Tables behind the additional constraints

The text in sections 7.3 and 8.3 mentions an attribute named "valueDefinition" that has been renamed as "itemDefinition"

Replace 'valueDefinition' by 'itemDefinition' everywhere in the text

answer must be checked

Supply the correct answer to the example in clause 11 so that readers can check their understanding.

In section 6.3.10, after the sentence :
It has a type, which is a String, and an owner, which is an OrganisationalUnit
add
The type is intended to identify the kind of the authoritative source, e.g. Policy Document, Regulation, Analytic Insight.

The resolution of issues 73 and 77 change the name of one hit policy from Unordered to Collect, and reduces the built-in aggregators to Collect, Sum, Count and Min.

The metamodel needs be modified in consequence.

Modified DecisionTable metamodel section to account for resolution 110 of issues 73 and 77.

Names (labels) of DRGElements must be distinct in a DRD, even if some are imported.

A compliant implementation must label each displayed DRG element in a DRD with different labels, and the method used to disambiguate between DRG elements with different names must be consistent, in order to enable the user to recognize a same DRG element in different DRDs.

Need new draft of Beta spec rolling up all resolutions from Ballots 5 and 7.

see parent issue

Figure 37 DecissionTable class diagram

Class DecissionTable
Attribute aggregation
missing
DataType - BuiltinAggregator
Default - COLLECT.

small DT MM change combined w/ other issue

There is the unsatisfied href to 08-11-13.xmi. If you really want to extend BMM it should use the proper OMG URI for Objective within BMM. This is just completing BMM 1.2

• DecisionTable::aggregation has no datatype: I assume it should be BuiltInAggregator

• DecisionTable::aggregation property’s default value of COLLECT is not validly specified. Easy once you set the type

• The default value of DecisionTable::hitPolicy of UNIQUE is differently but also not validly specified. In MD I was easily able to delete the Opaque Expression by right-clicking the default value; and then it gave me the correct list from the enumeration

• The association outputClause2outputEntry has an owned constraint with body of “ordered”. Ordering should be specified at the property level (which is what you have done) so the constraint should just be deleted. BTW by convention association names should start with a capital.

• The association DecisionTable2rule has an owned constraint with body of “ordered”. Ordering should be specified at the property level (which is what you have done) so the constraint should just be deleted. BTW by convention association names should start with a capital.

• There is an association end property on class Import of type Definitions that is not named

• There should be a MOF Tag for the namespace Prefix (and optionally the nsURI)

XMI has been corrected of the errors listed in the issue, and modified to account for the resolutions of other issues when relevant. The final XMI document passes NIST validator (except for the references to the BMM and BPMN metamodels, wihch ar enot loaded in the validator).

There is inconsistency in the values for BuiltInAggregator – the model (and section 7.2.13 of the spec) includes AVERAGE, the XSD instead has ANY.

• The following attributes are inconsistent: they declare a type of anyURI but then provide a default value that is not a URI:

• <xsd:attribute name="expressionLanguage" type="xsd:anyURI" use="optional" default="FEEL" />
  <xsd:attribute name="typeLanguage" type="xsd:anyURI" use="optional" default="FEEL" />

• I’m concerned about the many definitions which use xsd:qName as the type of elements. I don’t like the very non-standard use of qNames described in 11.3.2 of the spec: I don’t see why normal hrefs cannot be used for external files

• <xsd:element name="drgElement" type="xsd:QName" minOccurs="0" maxOccurs="unbounded" />

1. There is inconsistency in the values for BuiltInAggregator – the model (and section 7.2.13 of the spec) includes AVERAGE, the XSD instead has ANY

--> corrected in bmi-13-08-03 (corrected issue 1).xsd (also replacing FIRST with COUNT) [attached]

2. The following attributes are inconsistent: they declare a type of anyURI but then provide a default value that is not a URI:
a. <xsd:attribute name="expressionLanguage" type="xsd:anyURI" use="optional" default="FEEL" />
b. <xsd:attribute name="typeLanguage" type="xsd:anyURI" use="optional" default="FEEL" />

--> Change target namespace for level 3 (FEEL) XSD to http://www.omg.org/spec/FEEL/20140401 and use that URI for FEEL. No URI specific to Simple FEEL. Corrected in bmi-13-08-03 (corrected for issue 1).xsd [attached]

3. I’m concerned about the many definitions which use xsd:qName as the type of elements. I don’t like the very non-standard use of qNames described in 11.3.2 of the spec: I don’t see why normal hrefs cannot be used for external files: <xsd:element name="drgElement" type="xsd:QName" minOccurs="0" maxOccurs="unbounded" />

--> move to new issue DMNFTF-99

Since DMN is a standard (and in particular claims to be a business standard), then it must stick with its own definition of terms in all cases. Otherwise, in what sense is it a standard (especially a business standard)?

In defining “decision” DMN had two fundamental choices (from Merriam-Webster Unabridged dictionary):

1. a : the act of deciding; specifically : the act of settling or terminating (as a contest or controversy) by giving judgment

1. b : a determination arrived at after consideration : SETTLEMENT, CONCLUSION

DMN explicitly chose the first meaning. I strongly prefer the second, but then I’m a big fan of all things declarative. So in BRS TableSpeak an outcome by definition is a decision.

Since DMN explicitly chose the first meaning, however, an outcome (conclusion) is by definition not a decision. A decision is an act, never the result of the act.

If DMN somehow allows ‘overloading’ of the term “decision” – the central term in the standard – all bets are off. For example I have read elsewhere that the 'output' of a decision can be treated as a decision in DMN.

A term that you can use any way you want when it happens to suit you is a term that has not been standardized at all.

This comment appears to have been made against an earlier draft.
After review of the current beta draft, the task force believes the definition of decision as an act of choosing among possible options is the correct definition, and is consistent with the current text. This captures the notion of applying decision logic in the making of a decision.

In the glossary (p. 166), the definition of "Authority Requirement" reads "The dependency of a decision or business knowledge model on a knowledge source which provides a source of authority for the decision logic.".

Figure 13, however, shows two Authority Requirement dependencies in which knowledge source is the dependent item. So Input Data and Decision can provide a source of authority for the knowledge source. This seems confirmed by the text under "b" at the bottom of p. 34.

Point 1. The definition appears to need revision.

Point 2. To say "Input Data and Decisions can provide sources of authority for analytic models." seems to me to be really stretching the English language. I've never heard anyone in either business or IT say something like that. Perhaps this is aimed at some Community I'm not familiar with? It seems like over reduction, or over abstraction, or over something, to me.

I have proposed a number of edits to resolve this issue and create a consistent definition that handles the various uses.

We need a beta 2 spec to consolidate Ballots 1-4, making it easier to propose further document changes that incorporate agreed-upon changes.

Consolidate resolutions from Ballots 1-4 into a beta 2 specification.

change maritalStatus in ["M","S"] to maritalStatus in ("M","S")

change in ["M","S"] to in ("M","S")

Consider an ItemDefinition (ID) for an Invoice that contains 2 sub-items, shippingAddress and billingAddress, both of type Address, containing sub-items street and city, both strings, etc.

Clearly, Invoice, Address, and string are all IDs. But shippingAddress, billingAddress, street, and city are not IDs. Rather, they are InformationItems. The MM in Figure 26 of the spec has an itemComponentRef from ID to ID. This is an attempt to model a compound ID like Invoice as a collection of sub-IDs. This incorrect. Invoice is a collection of 2 sub-InformationItems, shippingAddress and billingAddress. Both these IIs refer to the Address ID. The Address ID in turn is a collection of IIs for street, city, etc. These have an ID of string.

Proposal: replace itemComponentRef (in Figure 26) with a composition from ID to II named itemComponent.

The ID (e.g. Invoice) owns its itemComponents (e.g. shippingAddress and billingAddress).

Removed the ItemComponentRef attribute and added an ItemComponent class

section 10.3.2.7 should be removed, and 10.3.4.5 should refer to figures in section 8.2, and the formal semantics should be aligned with the informal semantics. Replace all refs to 'rule test (cell)' with 'input entry'.

replace clauses 10.3.2.7 and 10.3.4.5 with the attached

last paragraph of 6.1 of the alpha spec says:

Using a value expression of type invocation is never required, even when possible: FEEL specifies its own invocation mechanism for more complex usages, and a FEEL literal expression can always be used instead of a value expression of type invocation.

I would like this to say instead:

A boxed invocation SHOULD be used instead of a literal FEEL invocation when possible. In general, a boxed expression SHOULD be used instead of a literal FEEL expression when possible. Note that Conformance Level 3 specifies additional boxed expressions.

Because 'boxed expression' isn't defined until 6.2, the rewritten para should be moved to the end of 6.2 (or even 6.3)

Also, I notice that 6.1 defines a decision table to be a tabular representation of decision logic. Would it be a good idea to do a global replace of 'boxed expression' with 'tabular expression'?

Define boxed expressions available at each conformance level, and recommend their use over equivalent literal expressions.

According to alpha version section 9.2.1.7, a boxed function (decision logic for a BKM) must have a parameters box and a body box.
Figure 8 is misleading or wrong, the boxed expression for Business knowledge 1 should be a boxed function (have a parameters box and body box instead of 'value expression' box.
All these examples - Figures 59, 61, 63, 65, 67, 69, 71, 74, 75, 77, need a parameters box beneath the name box. That is because these examples must be boxed functions, because they are invoked by the boxed invocations in Figures 58, 60, etc.

The consistency of the invocation logic, e.g. Figures 58, 60, etc. may be misleading. The actual parameters and formal parameters just happen to always be the same identifier. This is not required, and in fact is why it is important to list the formal parameters in the boxed function, so that the actual parameters can be substituted properly. For example, valid alternatives to Figure 66 include the following expression text in a box:

Application risk score model (Applicant Data . Age, Applicant Data . Marital Status, Applicant Data . Employment Status)

or the following:

Application risk score model (Marital Status: Applicant Data . Marital Status, Employment Status: Applicant Data . Employment Status, Age: Applicant Data . Age)

Note that Figures 74 and 77 desperately need parameter lists in order to know how to match actuals to formals in invocations.

One last example - a decision table dt1 with input x-y and some rules. There would be at least 2 ways to invoke dt1. E.g. dt1(x: 1, y: 2) and dt1(x-y: -1).The different invocations would result in different parses of the target function. In the first, x-y is a subtraction whereas in the second, x-y is a name. To avoid this problem,
you need a context, independent from any invocation, to indicate whether x-y is a name, or whether x and y are the names. Explicit parameter names attached to the boxed function definition provides such a context. Thus, the decision table needs to be the body in a boxed function definition, which is to say, there needs to be both the DT and the parameter list. The parameter list is a box containing (x,y) or (x-y). These are the parameters for all invocations.

Allow decision table notation to serve as a boxed function, i.e., not require parameter lists, if the input expressions are simple and can be interpreted as parameter names.

The Figure can be interpreted as a boxed context, with 2 entries. First entry is the DT named partial score, and the second entry is the unnamed result, containing 'Aggregate = sum', which looks like valid FEEL, but is not intended to be. BTW, the valid FEEL is 'sum(partial score)'. Isn't this as clear as 'Aggregate = sum' ?

This is a duplicate of the Aggregation issue.

and(true,null,true) should be null.

A better example is

and(false,null,true) = false

Also,

and(0)=or(0)=and(null)=or(null)=null

We get to define the truth values of and([]), or([]) (0-ary and/or). RIF says and()=true and or()=false, so we'll go with that.

Revise examples as indicated.

Priority and Output order hit policies are not supported for compound output tables.

Jacob Feldman commented in the LinkedIn DMN group:

"Building real-world decision models, practitioners always face complex issues related to diagnostic and resolution of rule conflicts. Some systems can effectively verify decision model consistency and diagnose rule conflicts. But until recently there were no practically used BR products that claim that they may automatically resolve rule conflicts.

"While we did not had an update about the current state of the DMN for a while, it does not seem that the first version will include any means to define superiority relations among contradictory rules. I believe at some point DMN may and should be extended in this direction."

(This was functionality I originally wanted, too, but for some reason we did not cover it in v1.)

The example he provides could be handled by a very simple extension to DMN (see attached file). I propose we extend the Priority and Output order hit policies to compound output decision tables, by making the first output column the Priority marker regardless of how many columns there are.

In clause 8.2.11, replace:

"To reduce complexity, decision tables with compound outputs support only the following hit policies: Unique, Any, First, Rule order and Collect without operator, because the priority schema or collect operator over multiple outputs are undefined."

with the attached.

FEEL has but one kind of number. There is no integer type.

Sometimes, it is required to convert a number such as 1.7 to the number 1.

This is not easy with the existing set of builtins. Note that decimal(1.7, 0) = 2.

Proposed:

floor(1.7) = 1

ceiling(1.1) = 2

x[i] = x[floor(i)]

Add floor and ceiling builtins

At the end of 10.3.4.1, we have the text:

Issues:

1. Extended time zone, e.g. 23:59:00@America/Los_Angeles

As the SBVR date/time spec notes, the timezone offset from XML date-times (referenced by FEEL)
is insufficient for most business uses, because it does not handle daylight savings time well.
Unfortunately, the SBVR spec gives a complex metamodel but no usable syntax.

I propose that we make the minor extension suggested by the current spec text. Wherever a timezone offset (i.e. +/-HH:MM) can appear in the lexical space of a date/time, an 'extended timezone' can be used. E.g.
2014-02-06T23:59:00@America/Los_Angeles instead of 2014-02-06T23:59:00-08:00.

The timezone IDs and associated time zone offsets (which change due to DST and other legal decrees) are maintained at http://www.iana.org/time-zones

Because the IANA tz form is commonly used in Java, Python and other implementation languages, implementers consider it desirable to support it, even though it extends the XML Schema standard forms in a way that has no formal designation. The specification of FEEL conversion operators in clause 10.3.4 is therefore modified to support the IANA form as a valid alternative.

The BMM metamodel has an OrganizationUnit class, that is referenced from BMM::BMM::Objective, which is itself associated with DMN::Decision

The DMN metamodel has an OrganizationalUnit placeholder class. Although the two classes do not play the same role in BMM and DMN, obviously, it might be a good idea, from an adoption and implementation viewpoint, as well as from the future evolution viewpoint, to give them the same name...

Changing the name will not help much if future versions of DMN need to share the same class as is used in BMM to represent organisational units. On the other hand, using the class BMM::OrganisationUnit in DMN would require extending it (i.a. to make it a subclass of BusinesContextElement, and thus of DMNElement),which does not make much sense, since BMM;;OrganisationUnit, like DMN::OrganisationalUnit, is a placeholder, "anticipating a defnition to be adopted from other OMG meta-models, such as OMG OSM when it is further developed".
So that neither change is worth the effort.

one must write something like date("2001-09-11") but this is technically an invocation of a builtin (not a BKM) which is not allowed at level 2

We need to allow an invocation with a string literal argument to be a simple literal. This will allow typographical date/time literals to be used in S-FEEL and in FEEL range expressions.

Update 10 says only that it is a string.

already applied to alpha/beta specs

The figure shows 3 levels:
1. DRD
2. boxed expressions
3. FEEL

and groups 1&2 as notation.

The problem is, FEEL is both notation and semantics.

The figure shows the FEEL semantic function, and thus is highlighting the semantic aspect of FEEL. The fact that the cells in the boxed expressions contain FEEL syntax is not highlighted.

The figure could be improved in one of 2 ways:
1. rename the callout from 'Expression Language (FEEL)' to 'Execution Semantics'. This more accurately describes the FEEL(...) in the dotted ovals, or
2. delete the FEEL(...) in the dotted ovals. Instead, callout some FEEL expressions from above, e.g., Application.Date - Application . Applicant Date of Birth, not(UK), <18, etc.

Implement improvement 2 from the description.

Also, there is a problem in the boxed invocation. The cell with

Application.Date - Application.Applicant Date of birth

does not result in a numeric age (it results in a days and time duration).

KnowledgeSource has a"type" attribute that is not explained or documented anywhere, only mentioned in table 13.

I propose that we remove it from DMN 1.0: KnowledgeSources may have a description, anyway, since they are DMNElements.

Explain the intent of type.

What is the target namespace for the DMN XML Schema?

The correct namespace for DMN 1.0 is http://www.omg.org/spec/DMN/20130901

In clause 8.3.2, as revised by Issue 54 resolution, the last paragraph before Table 24 reads:
"In a tabular representation of the containing instance of DecisionTable, the representation of an instance of Clause depends on the orientation of the decision table. For instance, if the decision table is represented horizontally (rules as row, see section 7.2.2), instances of Clause are represented as columns, ... All the instances of Clause made of a set of inputEntry (that is, the input clauses), MUSTSHALL be represented on the right left of any instance of Clause made of a set of outputEntry (or output clauses)."
This "For instance" suddenly becomes a rule, and it is only true when the table is represented horizontally. When the table is represented vertically (which is a different "for instance"), the inputs must be ABOVE the outputs, not to the LEFT of them.
The text should be corrected to give both rules, or neither.

separate inputs and outputs

inputs before outputs in horizontal tables - not explicit

I attach proposed editorial corrections to the replacement text adopted as the resolution to Issue 99.

minor wording change

Lists minor issues and edits in comments, for application in the beta 5

correct minor typos as indicated in issue attachment and comment

correct minor typos

Beta 5, including corrected XMI and XSD files

Final Specification (clean copy and convenience copy)

This is the proposed DMN 1.0 document and the 'convenience document' that details issue-by-issue changes since beta 1.

text says "which is <an instance of OrganisationalUnit?>."

remove brackets and question mark in text.

I am having trouble mapping the specified decision table notation and semantics in 8.2 to the metamodel in 8.3. Let me just interject some comments in red on some beta1 spec text:
8.3.2 Decision Table Clause metamodel
In a decision table, a clause
clause is a new term that is not used in the definition of the notation or semantics in 8.2. I am neutral about whether or not this is a useful concept/name (some old DT literature calls these 'stubs'). As suggested below, this should really be an abstract superclass of what we are elsewhere calling inputs and outputs (if needed at all) specifies a subject this italicized term implies it should be defined somewhere, or used in the MM, but it is not, which is defined by an input expression good, input expression is defined and used extensively and I think consistently throughout the spec or an output domain this is an undefined term. I think output values may be intended, and the finite set of the sub-domains of the subject’s domain that are relevant for the piece of decision logic that is described by the decision table the italics are mine, this time. I think input values are intended here.
In DMN 1.0, the class Clause is used to model a decision table clause.
An instance of Clause is made of an optional inputExpression and of a set of inputEntry, or of an optional name and a set of outputEntry, which are instances of Expression. A Clause element MUST have a set of inputEntry if it has an inputExpression, it MUST have a set of outputEntry if it does not have an inputExpression. A Clause element MUST NOT have both inputEntry and outputEntry
An instance of Clause may have a name, which is a String, and it may reference an outputDefinition, which is an ItemDefinition element. An instance of Clause that does not have an inputExpression MUST reference an outputDefinition. An instance of Clause that contains an inputExpression MUST NOT reference an outputDefinition. If a Clause element that references an outputDefinition does not have a name, its default name is the name of the referenced ItemDefinition element.
.It seems this could be represented more succinctly as 2 disjoint subclasses, Input(Clause) and Output(Clause). I think the outputDefinition is required iff output values are present in the decision table
The valueDefinition of an inputEntry element MUST be Boolean an example inputEntry is [21..35[ and this certainly is not Boolean and it MAY be omitted. The inputEntry elements MUST test the value of its containing clause’s inputExpression, possibly implicitly. The inputExpression is something like age and the inputEntry is something like [21..35[. The execution semantics are defined by mapping to FEEL age in [21..35[. But this FEEL in expression is not stored explicitly in the MM!
...
In a tabular representation of the containing instance of DecisionTable, the representation of an instance of Clause depends on the orientation of the decision table. For instance, if the decision table is represented horizontally (rules as row, see clause 8.2.2), instances of Clause are represented as columns, with the inputExpression or the name of the Clause element represented in the top cell, its domain of value optionally listed in the cell below, and each of the cells below representing one of the inputEntry or outputEntry in the Clause. All the instances of Clause made of a set of inputEntry, MUST be represented on the right of any instance of Clause made of a set of outputEntry.The above paragraph is concerned with linking the notation and the MM. This is made more difficult due to the introduction here of a new concept Clause, which is not defined where the other notation elements of input expression, input entry, etc. are defined in 8.2. Also, not all of the notation elements from 8.2 are accounted for here by name (e.g. input values, output values, and compound (multiple) output. We should not re-specify the notation here using different terminology from 8.2. We should use the same terminology to make the linkage between MM and notation simple, obvious, and complete

Proposed edits in the text of the Clause and DecisionRule metamodel descriptions (sections 8.3.2 and 8.3.3) to better align the terminology with section 8.1 and 8.2.

This section raises a few related issues, listed below:

1. In Fig 35, the labels 'output entry a', 'output entry b', 'output entry c' should instead be 'output value 1a', 'output value 1b', 'output value 1c'
2. It is misleading that the column with optional input/output values in Fig 36 is dropped in Fig 35. This column is optional independent of whether or not the 'shorthand' is employed. I think it should be possible to use the shorthand and also display the allowed values for the inputs (e.g. input value 1a, ...), but this might look ugly. Either way, we need to specify this clearly.
3. Why call this format a 'shorthand'? It is really limited-entry outputs. Whether or not it is 'shorter' depends on application values. It is curious that we previously (in 8.2.8) dismiss limited-entry inputs as not interesting. It seems no more or less interesting than limited-entry outputs.
4. The metamodel has no attributes that distinguish whether or not to use the shorthand. So whereas we interchange a DT's orientation, we do not interchange whether to use 'shorthand' output entries or not.
5. Because the metamodel uses a Clause for both inputs and outputs, we could add a boolean 'limitedEntry' attribute to Clause and thereby support limited entry inputs and outputs. There is something appealing about supporting limited entry for both inputs and outputs, or for neither.
6. Limited entry seems to work for both horizontal and vertical orientation. Why limit to vertical?
7. There is nothing that states that every rule must have exactly 1 'X' in its limited output entry cells. I think we must say that, in Fig 35, 'output entry 1a' is the column of 3 cells containing, from top to bottom, 'X', '-', '-'. The constraint is that exactly 1 of the output entry's cells must contain an 'X', and the others must contain a '-'.
8. Why use '-' instead of a blank cell? '-' means something different in input entries.

Clarify shorthand notation for vertical tables with revised text and figures.

In figs 31, 32, 33, 34, we have 'input value 1a', 'output value 1a' etc whereas in figs 27, 28, 36 we only have 'value 1a', etc for both input values and output values.
Also, we should not use italics to represent an optional cell because italics are used to represent a typographical string literal.

In addition, the revised text corrects many related decision table issues and includes many editorial improvements.

Input and output entries labeled consistently.
Cells indicated in inverse are optional.
Numerous related decision table issues are resolved.

should this be 10.2.1.7?

Revise reference.

The heading row, with column heads Name(parameters), Parameter Domain, Description, Example should be present in all 4 tables.

Copy the header from the table in 10.3.4.1 onto the tables in 10.3.4.2, 10.3.4.3 and 10.3.4.4.

In the semantic domain, we use boldface '=' to mean identity. But in FEEL syntax, italic '=' is specified in 9.3.2.11, primarily in table entries for grammar rule 51.a.

(side comment: all the tables in 9.3.2.11 need table numbers.)

Also confusingly, the semantic mapping table entry for 51.a where FEEL Syntax is 'e1 < e2' also applies to 'e1 = e2'. This must be clarified.

To avoid doubt about whether '=' means equals or identical, we should write identical(a,b) (or 'a is b') instead of a=b when inquiring whether or not 2 elements of the semantic domain are identical. For example,

identical("1", 1) is false

"1" = 1 is null

We should clarify the existing rules that imply that

1/0 = null is true

1/0 = 1/0 is null

1/0 != 1/0 is null

1/0 != null is false

1/0 in (0, null) is true

By symmetry, we should also have

null = 1/0 is true

null != 1/0 is false

The semantic rules don't explicitly cover the symmetry.

Semantics of if/then/else must be clarified as 'if identical(test, true) then ... else ...' A true test result will return the interpreted then part. A false or null (or anything other than true) test result will return the interpreted else part. Similarly, a list filter retains list items where the test is true and omits items where the test evaluates to anything other than true.

Revise FEEL semantics in clause 10.3 as indicated.

I think the intent was to overload '+', so that

1 + 1 = 2

"1" + "1" = "11"

"1" + 1 = null (incompatible input types)

If so, then we need to add a row in the table on pg 119 of the revised submission to account for the string case.

Overload '+' for string concatenation

From Ron Ross:

In the glossary (p. 166), the definition of "Authority Requirement" reads "The dependency of a decision or business knowledge model on a knowledge source which provides a source of authority for the decision logic.".

Figure 13, however, shows two Authority Requirement dependencies in which knowledge source is the dependent item. So Input Data and Decision can provide a source of authority for the knowledge source. This seems confirmed by the text under "b" at the bottom of p. 34.

Point 1. The definition appears to need revision.

Point 2. To say "Input Data and Decisions can provide sources of authority for analytic models." seems to me to be really stretching the English language. I've never heard anyone in either business or IT say something like that. Perhaps this is aimed at some Community I'm not familiar with? It seems like over reduction, or over abstraction, or over something, to me.

Thx,

Ron

We agreed it is a duplicate of the other issue

Consider a DRD with 10 decisions that all require the same InputData I. The DRD will have 10 InformationRequirement arrows, and the MM will have 10 InformationRequirement instances. Because, according to Fig 26, the InformationRequirement owns the InformationItem, then there will be 10 (hopefully) identical copies of the InformationItem for I. Why is this a good idea? What happens if the 10 copies diverge in value?

Proposal: InputData and Decision should own the InformationItem that denotes their output.

The revised text does not completely resolve the issue, but it reflects agreement that imported DRD elements may need to be referenced by something more than a simple Name.

According to the beta, the "variable" attribute is mandatory in the definition of an InformationRequirement.

However, it is useful only if the decisionLogic of the requesting Decision element is defined AND that decisionLogic uses the corresponding InformationItem.

It is not blocking to have to create and carry around the InfoItem anyway, but it is inconvenient. There is a risk that validating implementations will reject models where the unused variables are not defined.

Propose to make variable optional in InformationRequirement (so you do not have to create and interchange it, e.g. when no decision logic is specified that uses it)

The FEEL builtin is called 'mean' but when aggregation is defined, and in the MM, 'average' is used.

Replace "average" with "mean"

Whereas the items from InputData can be defined by associating an ItemDefinition to the InputData element, the only way to define the outcome of a decision is by associating a decisionLogic to the Decision, and an ItemDefinition to the decisionLogic.

Proposal: Add an outcomeDefinition association that is an ItemDefinition to Decision, and make the itemDefinition of a decisionLogic a derived attribute (or otherwise constrain the itemDefinition of the decisionLogic to be the same as the outcomeDefinition of the owning Decision).

Proposed resolution to add an optional outputDefinition attribute to the Decision element, and to require that the output definition of a decision be the same as the item definition of its decision logic, if they are all specified.

given a list L = [10, 20, 30]

L[1] = 10

L[item = 10] = [10]

L[item = 10][1] = 10

Proposed:

L[item = 10] = 10

Note that because a non-null non-list element is treated as a singleton list when used in a list context, the following still holds:
L[item = 10][1] = 10

Singleton list is equal to its content

7.2.11 Hit policy

p. 74

"Tools may support only a subset of hit policies, but the table type must be clear and therefore the hit policy indication is mandatory."

The empty subset is not considered valid.

Require unique hit policy to be supported.

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.

Defer the issue. Everything else related to interchanging the notation and layout as been deferred (except decision table orientation).

Convert the 'alpha' DMN submission into an OMG specification. Only boilerplate and formatting may change. There will be no changes to technical material. This will give a more appropriate baseline for subsequent change proposal.

Change from submission to OMG spec boilerplate.

For example, in addition to minumum([1,2]) FEEL should accept minimum(1,2). In both cases, the result is 1.

make the following builtins n-ary: min, max, sum, mean, and, or

Congratulations on using RFC-2119 language pretty consistently ("must", "should" etc). However, if the spec ever gets sent to ISO, it would have to switch to ISO language. The main difference is that ISO insists on "shall" instead of "must". Fortunately, "shall" is also in RFC-2119, so by switching all instances of "must" to "shall", you can comply with both. See: http://isotc.iso.org/livelink/livelink?func=ll&objId=4230456

Replace all occurrences of "MUST" with "SHALL", many occurrences of "should" with "SHOULD".

The Normative References section is very incomplete. The specification includes parts of JSON, PMML and Java by reference, so we need references to their defining documents. There are probably others too.

The Normative References list is modified to reflect all specifications that are normatively referenced in the body of the DMN specification. Some references in the body of the specification are corrected to refer to the names of the normative references introduced in Clause 3.

The reference to IETF RFC 2119 is deleted, because the requirements keywords have been changed to those mandated by ISO Directives.

The sole reference to RIF, in Annex A, is not normative, and apparently refers to the RIF-PRD specification as a relative of OMG PRR.

It is unclear whether the following is syntactically correct

{x:1}.x=1

or whether the following must be used:

({x:1}).x=1

The intent is that both are correct.

Split grammar rule 1 into 1a and 1b and note in the 'Additional Syntax Rules':

Operator precedence is given by the order of the alternatives in grammar rules 1, 2 and 4. E.g., (boxed) invocation has higher precedence than multiplication, multiplication has higher precedence than addition, and addition has higher precedence than comparison. Addition and subtraction have equal precedence, and like all FEEL infix binary operators, are left associative.

Grammar rule 2i shows:

i. literal | unary test | name | "(" , textual expression , ")" ;

A unary test such as "-" or "not(1,3)" can only be used as notation within a decision table condition cell and do not directly map to the semantic domain. For example, the following is not valid:

not(1)=0

Proposal: replace grammar rule 2i with

i. literal | simple positive unary test | name | "(" , textual expression , ")" ;

Note: make corresponding change in simple feel and review the mappings of "-" and "not" to ensure they map to FEEL that does have valid syntax and semantics.

change grammar rule 2i in clause 10.3.1.2

grammar rules have msword artifacts by mistake.

replace 'smartquotes' with regular quotes

Correct syntax should be

color in (red, green, blue)

not

color in red, green, blue

change grammar rule 51c and add 51d as proposed

The paragraph is:
Again, although Figure 2 depicts these decision modeling constructs as interlinked, it is possible to use them independently or in any combination. For example, it is possible to use DMN only to draw DRDs, or only to define decision tables, or only to write FEEL expressions.

However, the reality is that It is not possible to interchange a DT or an expression in a standard way without a containing DRG. The DT and expression MM is in Figure 26 of the alpha/beta 1 spec. To interchange a DT or expression directly, it would need to be immediately contained in a Definitions. By the MM in Figure 16, this isn't allowed.

Given that we do not support independent interchange, I think this paragraph in the spec is misleading. From an interchange point of view, you cannot have a 'standalone' decision table or expression. Semantically, 'standalone' expressions are usually not very interesting. Usually, expressions are interpreted in a context (which comes from the DRG, containing boxed context, formal parameters, etc.). The context must also be interchanged.

Delete the offending paragraph.

Many tables in chapter 10 are not numbered. This makes it difficult to reference these tables. They should be numbered even if they are not referenced in the spec text. Also, it seems that many tables that are numbered have their caption on top, whereas the figures have their caption on bottom. Is this intentional?

Number all tables in Clause 10.

A date range can be written (using typographical literals) as, e.g., [2012-01-01Z..2013-01-01Z)
This is defined to be [date("2012-01-01Z")..date("2013-01-01Z")). The grammar rules do not permit range endpoints to be invocations. We need to slightly generalize the syntax to support typographical literals without allowing arbitrary expressions (which causes difficulty because '[ expr' also looks like the start of a list).

adding 'date time literal' resolves both issues

Opening on behalf of Barb and Larry:

Larry and I would like to raise an issue allowing for Rule Families to be compliant for Level 1 DMN Conformance. I believe, this has always been our intent and would not be comfortable if we couldn't be Level 1 conforming.

The good news is that I believe I have a very simple edit-change to the document that should be acceptable to all:

Current text (page 16): An implementation claiming conformance to Conformance Level 1 shall comply with all of the specifications set forth in sections 5 (Decision Requirements), 6 (Decision Logic) and 7 (Decision Table) of this document.

Revised text (page 16): An implementation claiming conformance to Conformance Level 1 shall comply with all of the specifications set forth in sections 5 (Decision Requirements), 6 (Decision Logic) and, if using decision tables, 7 (Decision Table) of this document.

So, this revision preserves the decision table formats for compliance but also allows for other representations that work.

conformance levels have been extensively discussed and level 1 shall include both DRDs and decision tables with 'uninterpreted' expressions

the language 'alphabet' is not directly specified. E.g. 'and' is a keyword, so is 'ham and eggs' a legal name? What about 'return date'?

The grammar rules are fine but we need a 4th and 5th 'additional syntax rule' at the end of 10.3.1.2

The table in 10.4 shows that InputData is associated with a 'sample data' boxed expression. There is no such association in the metamodel. The intent is that the input data values come from 'somewhere' and are mapped to the FEEL domain AS IF the input data was given by a literal FEEL expression. For example, if the input data is XML, then the mapping is described in 10.3.3. This needs to be explained here.

define notion of binding case data to InputData, and that the case data can be notated as a boxed expression

The problem is that higher risk scores mean lower risk. This is not intuitive, and indeed the risk category decision tables require existing customers to have lower risk (higher scores) than new customers, which is likely not the intent.

Exchange "true" and "false" in the Existing Customer column.

The example does not include any Knowledge Sources and should do.

add knowledge sources to Fig 55

In the example every decision is linked to a BKM and decision tables/decision logic are specified only for the BKMs. The notation does not require a BKM for each decision and this is a common point of confusion. Those decisions that do not use reusable logic should be linked directly to decision tables instead leaving the reused logic (affordability for instance) as a BKM.

Replace figures 1 and 2.
Changes to clause 11 (Example) are described in 193 (subtask to issue 101).

"Decision tables with the Unique hit policy do not contain rules with overlapping input entries" should be "Decision tables with the Unique hit policy SHALL NOT contain rules with overlapping input entries". You should also specify absolutely precisely what "overlapping" means. All through this section 8.2.11, please substitute ISO/RFC 2119 language (e.g. "A single hit table returns the output of one rule only" -> "A single hit table SHALL return the output of one rule only").

Define overlapping and disjoint rules and inputs.

"the hit policy is summarized using a single character in a particular decision table cell." Please expand this sentence by saying precisely which character (i.e. the initial letter of Unique, Any, Priority, First) and which cell.

Specify precise hit policy codes and locations.

"Evaluation of the expressions in a decision table does not produce side-effects." Since those expressions can include calls to external Java code, this Ain't Necessarily So. Better to put this outside the scope of conforming implementations by saying something like: "Where expressions in a decision table are are expressed solely in FEEL, with no externally-defined functions, their evaluation does not produce side-effects. The behaviour of decision tables that call externally-defined functions with side-effects is undefined."

Expand on the definition and rationale for no side-effects. We say elsewhere that externally defined functions should not have side-effects - this is true in general and is not specific to decision tables.

"An instance of DecisionTable SHOULD BE represented as specified by its preferedOrientation, as defined in clause 8.2.2." You're saying that a conforming implementation is allowed to read a Decision Model written by another tool but display it with a different orientation. This is will greatly upset users, who get very attached to graphical elements being displayed exactly as they drew them. I suggest changing this to "An instance of DecisionTable SHALL be represented as specified by its preferedOrientation, as defined in clause 8.2.2."

The preferred orientation is preferred and this preference is something that vendors must maintain. However it is a PREFERRED orientation so there is not requirement that it be used to display the table.

For "count", you need to specify carefully whether the result is the number of rules that match or the number of distinct outputs (they're different if two or more rules return equal outputs). Specify how aggregation is specified in the written decision table (I only found out from the example on a later page).

aggregation replaced by collect operator

is in the interval [e1..e2] also noted [e1..e2], if and only if o ≥ e1 and o ≤ e1". This "also noted" subclause is redundant. The follow bullet has a typo: "is in the interval [e1..e2] also noted [e1..e2[" should be "is in the interval [e1..e2) also noted [e1..e2[" (See what I mean about those backwards brackets being confusing? .

Revise text as indicated.

"Arthmetic exponentiation (grammar rule 4c) is defined as the multiplication of the first operand by itself as many time as indicated by the second operand. It is defined only when the first operand is a number and the second operand is an integer." Given the context, "integer" should presumably read "positive integer". But why the constraint? 1.2**3.6 is perfectly well-defined. Is there a good reason to outlaw it? Also, "Arithmetic" is misspelled.

don't restrict the exponent to be an integer.

"Output priorities are specified in an ordered list of values, for example, the list of expected output values." I don't understand how this is different from the "First" single hit policy, or how/where this list of output priorities is specified (other than in the rule order). Please clarify.

Clarify that the output priority is given by the order of output values.

"all of the matching rules show the same output". Please precisely specify what "same" means here (presumably all output entries are equal using the equal operator defined for their type). What happens if a table specifies "Any", but a pair of matching rules return non-equal outputs? Presumably the behaviour is undefined.

Define that 'same' means equal, and that if the hit policy is Any and two matched rules do not have equal output entries, the result is undefined.

"Dates, times, and durations may be compared, but only if they have been given names" Why? Given that there is a syntax for specifying anonymous dates (e.g. date("2012-12-25")), why force dates to be named before they can be compared?

Allow typographical date/time/durations to be compared, and use underline in Table 27 to callout the unary tests so as not to conflict with typographical styles (italic and bold italic)

"An expression to be tested satisfies an instance of simple unitary tests (grammar rule 9) ..." That "9" should be "14".

Revise reference to grammar rule.

Are you sure this example is syntactically valid? It contains an anonymous date, which section 10.2.2.1 says is illegal (see previous issue report), and a use of [ ] that doesn't seem to have anything to do with intervals.

Add descriptions to FEEL examples in clause 10.6

Typo: "as many time" -> "as many times".

Correct the typo.

guarantee that the syntax for open intervals that potentially involves brackets facing the wrong way will drive users crazy (e.g. "[1..5["). The alternative syntax that uses unmatched bracket types (e.g, "(1..5]") is almost as bad. There must be a better way!

See for example http://en.wikipedia.org/wiki/Interval_(mathematics)
There's even an ISO standard: http://en.wikipedia.org/wiki/ISO_31-11

Table entries "SHOULD NOT conflict with FEEL syntax" (4 places). OK, I know why you're saying this, but that "SHOULD NOT" is such a weak statement as to be useless. I suggest making it part of the conformance criteria: "At Conformance level 1, there is no restriction on table entries, which are not interpreted. However, at conformance levels 2 or 3, table entries SHALL comply with FEEL syntax".

Add an expression language URI to indicate that expressions are not meant to be machine interpreted; edit text to introduce the URI and clarify its recommended usage.

Fig 27, 28, 30, 31 ... The meaning of the letters "HC" in these tables is not introduced for another 30 pages. It's a long wait.

Define hit policy and completion code earlier in clause 8.

"The ordering is represented by the explicit numbering of the rules in the diagrammatic representation of the DecisionTable." This seems to be the only place that rule numbering is mentioned. Please introduce it (even if only with one sentence) in section 8.2. Specify exactly how rules are numbered (integers? Natural numbers? Any sequence with a total ordering? Is numbering mandatory? Must the numbers be sequential? Can I "number" my three-rule table "A" "B" and "M"?).

Define rule numbers as consecutive natural numbers starting with 1.

Fig 27, 28, 30, 31, 32 ... In several of these figures the "value 1a", "output entry 1a" etc labels are the same or different across rows and columns for no apparent reason. If there's no reason for them to match, please make them all different (e.g. I'm pretty sure there's no reason for putting "value 1a" in both the input and output columns in Figure 27). Otherwise it's confusing.

Split each figure into two: a schematic layout and an example, to better explain the decision table cell contents.

"IF input expression 1 matches x AND ..." The word "matches" is a bit vague - I think "satisfies" would be better - and perhaps supply a couple of extra sentences saying what this means for S-FEEL and non-S-FEEL Decision Tables.

Issues 55, 66-70, and 74 all affect clauses 8.1-8.2.2. Combined revised text is attached

Decision tables (section 8, p 70 onwards). Almost all the decision table examples and explanations have two input expressions. It would be worth making clearer that all decision tables (other than crosstab tables) can have 1, 3, 4 ... input expressions.

examples with 3 inputs added

IMO sections 5.3 "Scope and uses of DMN" and section 5.2 "Basic concepts" should be in the other order. To have read section 5.3 would be useful background when first reading 5.2.

Swap sections 5.2 (Basic Concepts) and 5.3 (Scope and Uses of DMN)

"Using a value expression of type invocation is never required, even when possible: FEEL specifies its own invocation mechanism for more complex usages, and a FEEL literal expression can always be used instead of a value expression of type invocation." I'm not clear what point is being made here.

The resolution of DMNFTF-13 removes the paragraph that is at issue. Nothing further to do.

'To avoid having to discerning whether HIGH, DECLINE is "HIGH" "DECLINE" or "HIGH, DECLINE", typographical string literals should be free of "," characters.' Why not "SHALL be free of" commas? Also, broken grammar: "having to discerning".

Ban commas from typographical string literals and correct grammar.

fig 22 - The dotted line style used in this figure, and throughout the specification is indistinguishable from a solid line on my printer. Make the "dottedness" more apparent?

Dotted lines are too hard to distinguish in some renderings. Use solid lines instead.

DMN elements are referenced by their ID with the same file, and by a QName built from a prefix and their ID, where the prefix in the QName must be assigned to the namespace of the Definitions element that contains the referenced element.

However, two different definitions in two different XML files may be in the same namespace: since ID are unique only within their XML file, two different DMN elements can, therefore, have the same reference.

One way to repair that would be by using a bare name XPointer as the value of an XLink href attribute instead, for referencing DMN elements, where the XPointer would consist of the URL of the file containing the Definitions suffixed with the element's ID (separated by #).

Replacement for 12.3.2: Proposes to use href attribute w/o XLink with bare Xpointers to reference DMN elements that may need be referenced across Definitions elements (and thus across XML files).

The definition of "Decision" on page 23, section 5.2.1 defines "Decision" as an activity ("act"). It mentions a Decision has an "output" value, however, an "output" shape coming out from the decision activity is not shown in the diagrams.

It may be useful to draw and show an output shape coming out from the Decision box. That could be named "Decision output".

This suggestion applies to Figures 1, 2, 3, 4, 5 and other similar diagrams. While the value of the decision output may not need to be explicitly depicted on all BPMN process diagrams and on other diagrams, at least the initial few diagrams where the concepts are defined it should be depicted explicitly.

On Figure 1, in the Decision Model area, the dotted line connecting this area to the BPMN model should have a label such as "Routing Decision Output" (which the BPMN diagram implicitly assumes has a value of "ACCEPT" or "DECLINE". Similarly, diagrams 2, 3, 4, and 5 could have an "Decision Output" coming out of the Decision box and connected to it with an arrow pointing from the Decision shape to the Decision Output shape.

We do not want every decision (including sub-decisions) to have both a decision symbol (rectangle) and some symbol for the output. This would add clutter for no reason, because every decision has exactly 1 output. We discussed the possibility of having only the 'top' decision(s) show an output, but again, this is not needed and it is possible to discern the top decisions - those that are not required by any other decision.
Finally, we note that decisions have much metadata that can be used to link decisions to BPM activities, provide business motivation, etc. There is no standard notation for much of this metadata, so as not to over-constrain tools.

The overall process is (up to) 3 top-level decisions:
1. decide strategy
2. decide routing
3. review application and decide to Accept or Decline
Why do we not model the 3rd decision (to some level of detail) and associate it with the human task just like other decisions are associated with the business rule tasks?

Update DMN Example with human decisions (and decisions without BKMs)

It is unclear (i.e. unspecified) what are the use cases for connecting Knowledge Sources to Decisions versus Knowledge Sources to Business Knowledge (models) in the cases where the Knowledge Source is the Authority for the Decision or Business Knowledge (model). The text does not make the case for either scenario in DRDs containing all 3 entities.

Example: Customers may connect a Knowledge Source as the authority to either or both the Decision or its related Business Knowledge (model).

Suggested resolution: A table defining the use cases for connecting a Knowledge Source to a Decision, Business Knowledge (model)

Replace the text of clause 6.2.3 as follows:

Confusion over the notation has been propagated even before the DMN spec is finalised. For example see http://www.slideshare.net/alcedocoenen/intro-dmn-10 slide 19 which was a conference presentation on DMN gives incorrection notation interpretation. Another example was a customer version of a DMN DRD that demonstrated confusion over the shape and connector meanings.

Suggested resolution:
Add a graphical notation to the text of the cells in table in chapter 6.2.3 pg 35 showing shape-connector-shape to avoid any possible misinterpretation

Add graphical notation to the text in the table in 6.2.3

Input Data entity definition appears to be quite sparse versus the data specification requirements likely to be needed in decision modelling. Also not well represented in the ch 11 DMN Example where it is used there for input samples rather than input specifications.

Example: an end user defined a DRD and labelled the Input Data in their DRD with the name of the XSD of the data source. They then questioned how to annotate an Input Data with a specific named XSD - especially is the input data is constrained to a 3rd party format (such as an industry standard that is specified as an XSD), which they considered (as a tag) a business level concept, even if the details of the XSD might not be.

Suggestion: Input Data should be more vigorously defined e.g. as a specification of input data / source (message, invocation, etc) associated with Boxed Invocation, maybe renamed Source of Data. Sample Data could be specified as a Knowledge Source for Input Data. Specifications of the format (e.g. industry XSDs) of Input Data could also be Knowledge Sources

Distinguish input data from case data.

Boxed Invocation is defined in Ch7.2.3. In Ch8 Decision Table "builds on" Ch7 but has no reference to Boxed Invocation (e.g. while one might expect a reference with regard to invocation of Decision Tables). Likewise Annex B refers to Decision services but has no reference to Boxed Invocations.

Example: an end-user defined a DRD and associated Decision Tables (to reflect BKMs) expected to have to define Boxed Invocations to represent the interface to Decision Tables.

Suggested solutions:
1. Either add an explanation that Boxed Invocations are conceptual and only relevant to FEEL, or add how they are represented when defining Decision Tables (Ch8) and in the DMN Example (Ch11) and Annex on Decision Services (Ann B).

2. Show the DMN XMI model for the DMN example relating the example to the metamodel concepts in preceding chapters including Boxed Invocations.

In order to make it more explicit which figures in clause 11 are boxed invocations, in 11.3, change 'invokes' to 'is a boxed invocation of'

It is not clear from the spec whether it is valid to have a decision tables with no inputs. In such a table all rows would always be true (i.e. facts, rather than rules). This would be useful on occasions, e.g. for generating a list of items to be filtered in subsequent decisions (although it would be possible to provide the same functionality using boxed contexts or raw FEEL).

Is this valid? If so we need to provide an example.
If not the spec needs to be clarified anyway.

0 input decision tables are explicitly allowed in beta3 (there is no example)

After careful review, we have found several minor wording changes to the final DMN specification that have been (or soon will be) made but do not have approved editing instructions. The resolution to this issue will provide thtese instructions.

minor edits

see attached

Map all DMNFTF issues to editing instructions expressed as
change <snippet from beta 1> to <snippet from change bar document>
Cover all changes in the cbar document, and comment on changes resulting from multiple issues.

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

In the FTF Report,
for DMNFTF-6 and DMNFTF-17, use the format Replace <old text> with <new text>,
for DMNFTF-93, also use Replace/with, and identify the old text as all occurrences of invokes in 11.3, and
for DMNFTF-221, describe the change as a restoration of the relative text positions that were unintentionally changed by a prior edit.

In the specification,
make changes to mark-up and comments as described in the subtask (issue 246).

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