DMN 1.0 FTF Avatar
  1. OMG Issue

DMNFTF — Decision Table Clause metamodel needs clarification

  • Key: DMNFTF-54
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    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

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 22:58 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments: