Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Closed Issues

  • Acronym: DMN
  • Issues Count: 79
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN11-26 DecisionRule, InputClause & OutputClause should have ID and label for referencing in execution logs DMN 1.0 DMN 1.1 Resolved closed
DMN11-81 extra level of indirection in decision table serialization is undesirable DMN 1.0 DMN 1.1 Resolved closed
DMN11-45 Define decision service DMN 1.0 DMN 1.1 Resolved closed
DMN11-176 DecisionService has no defined execution semantics, and decision model semantics in 10.4 is hard to understand DMN 1.0 DMN 1.1 Resolved closed
DMN11-164 use refs in XSD only to substitution groups DMN 1.0 DMN 1.1 Resolved closed
DMN11-155 DMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions) DMN 1.0 DMN 1.1 Resolved closed
DMN11-146 DMN XSD, MM, Attribute/Association Tables, and spec text are not consistent DMN 1.0 DMN 1.1 Resolved closed
DMN11-145 8.3.3. still speaks of condition and conclusion - supposedly removed by DMN11-81 DMN 1.0 DMN 1.1 Resolved closed
DMN11-122 DMN 1.1 Beta documents DMN 1.0 DMN 1.1 Resolved closed
DMN11-12 Reference to BMM::Objective, BPMN::Process and BPMN::Task in XMI DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-91 dmn.xsd and dmn3.xsd should be merged and list of machine readable files corrected DMN 1.0 DMN 1.1 Resolved closed
DMN11-89 Remove parameters from BKM MM - these belong at logic level DMN 1.0 DMN 1.1 Resolved closed
DMN11-64 'In DMN 1.0' now not only tedious but wrong DMN 1.0 DMN 1.1 Resolved closed
DMN11-47 Add association connector (artifact) with text label to represent conditional decision DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-99 Need for annotations and comments in DRD DMN 1.0 DMN 1.1 Resolved closed
DMN11-92 Need to clarify which DMNElements must and must not have names DMN 1.0 DMN 1.1 Resolved closed
DMN11-73 XSD: modify Import in tLiteralExpression DMN 1.0 DMN 1.1 Resolved closed
DMN11-69 inputVariable and itemDefinition are redundant in Expression metamodel DMN 1.0 DMN 1.1 Resolved closed
DMN11-58 Decision table default output DMN 1.0 DMN 1.1 Resolved closed
DMN11-54 XSD itemDefinition/typeRef and typeDefinition are underspecified and incorrect DMN 1.0 DMN 1.1 Resolved closed
DMN11-56 XSD; modify tItemDefinition by changing tItemComponent DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-50 Question on boxed invocation format DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-175 typos for DMN 1.1 RTF final report DMN 1.0 DMN 1.1 Resolved closed
DMN11-166 Information item name on DTs not correct in some figures DMN 1.0 DMN 1.1 Resolved closed
DMN11-139 Decision table MM and xsd need output label attribute DMN 1.0 DMN 1.1 Resolved closed
DMN11-137 Need InformationItem for the FunctionDefinition of a BKM DMN 1.0 DMN 1.1 Resolved closed
DMN11-127 would like to annotate Expression with typeRef DMN 1.0 DMN 1.1 Resolved closed
DMN11-123 Decision, InputData, and other containers of InformationItem do not ref ItemDefinition directly DMN 1.0 DMN 1.1 Resolved closed
DMN11-120 Knowledge Source metamodel diagram missing DMN 1.0 DMN 1.1 Resolved closed
DMN11-25 Definitions/@namespace has no purpose DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-24 Constraints on Decision Table elements unclear DMN 1.0 DMN 1.1 Resolved closed
DMN11-22 Expression defined as resulting in single value, but Decision may have multiple values DMN 1.0 DMN 1.1 Resolved closed
DMN11-21 input expression example 'age<25' is not legal in SFEEL grammar DMN 1.0 DMN 1.1 Resolved closed
DMN11-65 In metamodel, 'variable' should move from Information Requirement to Decision / Input Data DMN 1.0 DMN 1.1 Resolved closed
DMN11-32 Decision table completeness undefined, Complete code conflicts with Collect DMN 1.0 DMN 1.1 Resolved closed
DMN11-35 Dangling reference DMN 1.0 DMN 1.1 Resolved closed
DMN11-34 extraneous asterisks (*) DMN 1.0 DMN 1.1 Resolved closed
DMN11-60 Beta2 XSDs are broken DMN 1.0 DMN 1.1 Resolved closed
DMN11-52 authorityRequirement in XSD DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-44 Remove attribute DecisionTable/@isConsistent DMN 1.0 DMN 1.1 Resolved closed
DMN11-43 change "output expression" to "output name" DMN 1.0 DMN 1.1 Resolved closed
DMN11-30 add Definitions optional attributes exporter, exporterVersion DMN 1.0 DMN 1.1 Resolved closed
DMN11-13 DMN 1.1 RTF Issue: Negative numerics in decision tables DMN 1.0 DMN 1.1 Resolved closed
DMN11-147 Nested ItemDefinition doesn't work DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-130 Clarify defaults for decision table outputs DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-7 DMN issue: date syntax in table 29 DMN 1.0 DMN 1.1 Resolved closed
DMN11-6 DMN Issue: typo in 3rd well-formed requirement of KnowledgeRequirement DMN 1.0 DMN 1.1 Resolved closed
DMN11-4 DMN issue: typo in introduction of "Relating Logic to Decision Requirements" DMN 1.0 DMN 1.1 Resolved closed
DMN11-9 XSD internally inconsistent, does not match the spec DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-3 XMI issues from Pete Rivett DMN 1.0b1 DMN 1.1 Closed; No Change closed
DMN11-23 S-FEEL "expression" undefined DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-27 XSD: DecisionTable/rule/condition should be IDREF not IDREFS DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-109 need to add UnaryTests to MM and XSD DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-102 XSD: change type of LiteralExpression/text, ItemDefinition/typeDefinition, and (new) textAnnotation/text to xsd:string DMN 1.0 DMN 1.1 Resolved closed
DMN11-84 Decision Table metamodel and XSD should restrict input entries, input values, and output values to unary tests, and LiteralExpression for input expressions and output entries DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-88 8.2.10 calls crosstab tables "rules as columns" DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-80 XSD: make @id optional in tExpression DMN 1.0 DMN 1.1 Resolved closed
DMN11-62 FEEL/S-FEEL names DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-33 list variables in decision tables DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-76 XSD: Relation and List DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-57 Xsd typeRef and itemDefinitionRef DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-55 XSD: add optional @name to inputVariable DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-53 FEEL concatenate function DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-48 dmn3.xsd DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-42 output data symbol & comment symbol missing in DRDs DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-39 Clarify Decision/outputDefinition, DecisionTable/clause/outputDefinition, DecisionTable/@name, clause/@name DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-29 Examples DMN 1.0 DMN 1.1 Deferred closed
DMN11-152 not all references in DMN are by ID DMN 1.0 DMN 1.1 Resolved closed
DMN11-8 DMN Issue: Boxed context example of XML data is wrong DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-1 Change Tracking Document DMN 1.0b1 DMN 1.1 Closed; No Change closed
DMN11-5 DMN issue: InformationItem is not a specialization of Expression DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-2 Incorporate AB feedback into the FTF Report, the marked-up specification, and the clean specification DMN 1.0b1 DMN 1.1 Closed; No Change closed
DMN11-11 BigDecimal is not the only mapping of number to Java DMN 1.0 DMN 1.1 Deferred closed
DMN11-10 cannot interchange input data style DMN 1.0b1 DMN 1.1 Deferred closed
DMN11-66 No notation for ItemDefinition DMN 1.0 DMN 1.1 Deferred closed
DMN11-46 Consider date and time datatype in S-FEEL DMN 1.0 DMN 1.1 Deferred closed
DMN11-51 alternative indication of reusable logic in DRD DMN 1.0 DMN 1.1 Deferred closed
DMN11-31 Business Context links go both ways DMN 1.0 DMN 1.1 Deferred closed
DMN11-116 Need group artifact in DRD, metamodel, and XSD DMN 1.0 DMN 1.1 Deferred closed

Issues Descriptions

DecisionRule, InputClause & OutputClause should have ID and label for referencing in execution logs


extra level of indirection in decision table serialization is undesirable

  • Key: DMN11-81
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The input and output entries in a decision table are expressions. The expressions are serialized as part of the rule 'clause', with an ID. In the rules, the expressions are represented by IDREF. This level of indirection is undesirable for many reasons:
    1. the expressions are small text strings, typically no bigger than an ID
    2. copy/paste of rules across decision tables won't work (IDs are different)
    3. diff of decision tables is complicated, due to indirection
    4. there is no level of indirection in the notation - the rules appear to contain the expressions, not a reference to them.
    5. complicates JSON serialization
    Proposed: In Figure 44, move Expression ownership from Clause to DecisionRule, and follow logical implications in text and xsd.

  • Reported: DMN 1.0 — Thu, 25 Jun 2015 06:23 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    remove indirection, split Expression into LiteralExpression and UnaryTests

    DecisionRules are ordered in a DecisionTable. By also ordering the inputs and the outputs (requires splitting Clause into InputClause and OutputClause, we can move the inputEntries and outputEntries under DecisionRule and avoid all IDREFs within a decision table, significantly simplifying serialization. Also, we combine a proposal for DMN11-84, which is merged with this issue.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Define decision service

  • Key: DMN11-45
  • Legacy Issue Number: 19754
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    Allow DMN to specify and interchange definitions of decision services, along the lines proposed in Annex B.

  • Reported: DMN 1.0 — Tue, 28 Apr 2015 04:00 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Definition, notation and examples for Decision Service

    Complete proposal in the attached document

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

DecisionService has no defined execution semantics, and decision model semantics in 10.4 is hard to understand

  • Key: DMN11-176
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Now that we have decision services, this is a much better and simpler feature for which to define execution semantics. We can simplify and improve the usefulness of 10.4.

  • Reported: DMN 1.0 — Fri, 30 Oct 2015 16:20 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    replace 10.4 with Execution Semantics of Decision Services

    This proposal depends on adoption of DMN11-143. I think we should specify the execution semantics of decision services. This can replace 10.4, which is the execution semantics of DRGs, which is problematic because the InputData doesn't have much meaning except as the parameter of a decision service. No MM or XSD changes.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

use refs in XSD only to substitution groups

  • Key: DMN11-164
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    use <element name=xx, type=tYY/> instead of <element ref=zz/>
    This will more consistently name subelements as MM attributed names, not as MM class names. This is a stylistic issue only.

  • Reported: DMN 1.0 — Tue, 27 Oct 2015 17:21 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Consistently use MM names in XSD

    Change XSD to use attribute names as defined in meta model aggregations.
    Remove references to global elements where no polymorphism is needed.

    In particular the changes are:

    1. remove unneeded global elements and refs
    2. Revert back to ref="Import" due to polymorphism with ImportedValues
    3. Remove unused element text
    4. Use attribute names from meta model
    5. Consistently prefix type names with t
    (This is only XSD cosmetics and does not affect the actual element names in instance documents)
    6. Consistently name elements with MM class name with lower-case first letter
    (This last change might be a little controversial, as it affects many element names. However, the previous changes result in a mixture of upper and lower case element name, which certainly will be confusing for tool vendors. Especially, since we see in the OMG BPMN Model Interchange Working Group, that many tool vendors are not performing schema validations, we might end up with subtle differences in import/export that prevent interchange. Also when developing tools to analyse or transform DMN files using XSLT or XPath, predictable element names will safe a lot of hassle.)
    7. imported values can only be used in literal expression.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

DMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions)

  • Key: DMN11-155
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    DMN nees to provide a standard way for vendors to serialize extensions (Vendor Extensions). It is proposed that a schema resembling what was done in BPMN and CMMN be used.

    Why DMN should be extensible

    The extension mechanism allows adding Custom Metadata to models in a way that it MAY be interchanged between vendors. Concretely this means that it is possible to add custom attributes and elements in a custom namespace to the XML interchange format.

    Example of a custom attribute

    <DecisionTable id="table1" custom:audit="true" xmlns:custom="http://custom.org/auditing" ...>
    

    Example of a custom element

    <DecisionTable id="table1" ...>
      ...
      <extensionElements>
      <custom:audit xmlns:custom="http://custom.org/auditing">
        <custom:audit-level>full</custom:audit-level>
        <custom:retention>unlimited</custom:retention-level>
      </custom:audit>
      </extensionElements>
      ...
    </DecisionTable ...>
    

    Vendors need to be able to add custom Metadata

    Vendors need to be able to decorate the model with additional metadata. Vendors may implement additional usecases which the standard as such does not address like historization, reporting, fine-grained editing authorizations amd restrictions, ...
    Having the possibility to put this directly into the interchange format allows vendors to roundtrip models. If all vendors participating in the roundtrip re-export the other vendor's extensions than they are not lost during roundtrip which leads to a better inter-operatbility experience for the user.

    Users need to be able to add custom Metadata

    The possibility to extend the model with custom metadata has also proven to be vital to camunda users and customers in the past.
    Many users extend the model with their custom attributes and elements to be able to implement custom extensions.
    Some have custom metadata for their execution environment others for auditing and reporting.
    It is very important at users are able to put custom metadata into the xml file.

    FAQ

    Is BPMN's extension mechanism perfect?

    Probably not. At the XML level it works extremely well. At the Meta Model level it could certainly be improved.
    But the question is whether the practical advantages of a "slightly better approach" would outweigh the advantages of consistency among these standards.

    Does that mean that Vendors can just ignore the Standard?

    No. In order to be compliant, vendors need to implement the standard in the way mandated by the standard.
    If they use custom extensions for realizing non-compliant behavior then they are non-compliant.

    Do tools need to understand the extensions created by other vendors?

    No. Tools do not need to understand extensions created by other vendors. What's more, the specification text explicitly states that tools do not event need to round-trip extension elements by other vendors while still being compliant. There is also no compliance level at which a tool is required to support this. A tool is fully compliant if it is not able to round-trip extension elements.

    Has this actually been successful in BPMN?

    Yes. Extension mechanisms are heavily used and there is ample empiric evidence of this being a successful concept. To see it in action have a look at the demos and test cases of the BPMN Model Interchange Working Group (MIWG) at the OMG.

    For comparison see also the CMMN 1.1 proposal CR-20.

  • Reported: DMN 1.0 — Thu, 22 Oct 2015 13:33 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Add new extension capability to DMN as per that of BPMN and CMMN

    Based on the extension capabilities of BPMN and CMMN the following changes need to be done:

    1. Add two rows to table 3
    2. Add a new figure of the metamodel showing the relation between DMNElement and the extension mechanism in section 6.3
    3. Figure 15 - DMNElement class diagram needs to be updated with ExtensionElements and ExtensionAttribute depiction.
    4. A complete new section 6.3.14 Extensibility needs to be added. This will have a ripple effect on table and figure numbering. Figure of the metamodel should be inserted after the first paragraph of section 6.3.14, in the metamodel we need to add the two classes described
    5. Some changes needed to DMN.xsd, which already contains this mechanism
  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

DMN XSD, MM, Attribute/Association Tables, and spec text are not consistent

  • Key: DMN11-146
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    XSD must use names derived in a consistent way from MM names. XSD types should be used everywhere. Spec text descriptions must agree in name and concept with the MM. XSD must use containment and references in the same way as the MM. For example, DMN11-81 removes references and uses containment for the entries in a DT. But XSD still has lingering ID/IDREFs that must be removed and aligned with current MM.

  • Reported: DMN 1.0 — Thu, 8 Oct 2015 16:10 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Align XSD, MM and spec text as described

    Make following changes to XSD:
    1. Relation.column in XSD should have type tInformationItem, not tContextEntry
    2. Invocation.calledFunction is missing in the XSD
    3. KnowledgeSource.type: change anyType to string
    4. tInvocation/@calledFunction is of type="xsd:string", but in MM it aggregates an Expression => Change XSD to reference abstract element Expression.

    Make following changes to MM:
    1. MM ImportedValues does not contain importedElement, but XSD does. Add attribute to MM
    2. Collapse the classes that are not essential in each diagram, e.g. DMNElement and NamedElement should show attributes only in the DMN Element diagram
    3. Use xsd types (instead of String) for ID, anyURI, QName
    4. rename OrganisationalUnit into OrganizationUnit in MM and spec text.
    5. name association from Decision to InformationRequirement "informationRequirement"
    6. add attribute importedElement : String[1] to ImportedValues in MM
    7. remove attribute "name" from InformationItem in MM
    8. Make NamedElement abstract in MM and XSD

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

8.3.3. still speaks of condition and conclusion - supposedly removed by DMN11-81

  • Key: DMN11-145
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Need to reword to use new MM associations

  • Reported: DMN 1.0 — Thu, 8 Oct 2015 15:59 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    spec text update to decision rule MM in 8.3.3

    This issue describes the changes to Decision Rule meta-model from referencing conditions and conclusions to embedding them.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DMN 1.1 Beta documents

  • Key: DMN11-122
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    We are required to vote on the beta 1.1 documents, submitted with this report. See "Deliverables" section of this report.

  • Reported: DMN 1.0 — Thu, 27 Aug 2015 00:16 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    submit attached beta documents to OMG

    OMG requires a vote on beta documents.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Reference to BMM::Objective, BPMN::Process and BPMN::Task in XMI

  • Key: DMN11-12
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

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

  • Reported: DMN 1.0 — Tue, 29 Jul 2014 12:51 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    unable to find more information about this issue

    Did not hear back from Pete and nobody on RTF is an XMI expert. Not even sure if this still applies.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

dmn.xsd and dmn3.xsd should be merged and list of machine readable files corrected

  • Key: DMN11-91
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    issue 60 has identified 2 critical but easy to fix problems with the beta2 xsds. An even simpler fix is to combine the 2 xsds. Separate xsds invites the problems, and it has been reported that popular XML tools don't like the 2 xsds because it is the included xsd that has the document root. Also, DMN11-89 proposes to use FunctionDefinition (now in dmn3) to consistently serialize all BKM logic.

  • Reported: DMN 1.0 — Mon, 6 Jul 2015 20:55 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Merge contents of dmn3.xsd into dmn.xsd

    Merge contents of dmn3.xsd into dmn.xsd and delete dmn3.xsd.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Remove parameters from BKM MM - these belong at logic level

  • Key: DMN11-89
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The BKM MM defines parameters but has no notation for them. Meanwhile, the FunctionDefinition also defines parameters that duplicate the BKMs. Also, 10.2.1.7 says a BKM's logic must be a FunctionDefinition or a DT, but Table 11 syas a BKM's logic msut be the BODY of the function it defines. To straighten out thsi mess, I propose
    1. remove params from BKM MM
    2. require BKM to contain a FunctionDefiniition, so that the params will always be defined, and always at the decision logic level
    3. allow FunctionDefinition whose body is a DT with simple inputExpressions that reference all parameters, and only parameters, in order, to be denoted using the DT only

  • Reported: DMN 1.0 — Thu, 2 Jul 2015 18:48 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    BKM value expression is a function definition

    change BKM metamodel and XSD to associate BKM to FunctionDefinition instead of separate parameters and body

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

'In DMN 1.0' now not only tedious but wrong

  • Key: DMN11-64
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    There are many occurrences of the phrase 'In DMN 1.0'. Now that we are writing DMN 1.1, this phrase is no longer simply tedious and redundant, but now it is also wrong. All occurrences should simply be deleted. And, all occurrences of 'In DMN' should be deleted. They are redundant. This is the DMN specification! Everything described is by default 'in DMN'!

  • Reported: DMN 1.0 — Thu, 4 Jun 2015 05:18 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Remove superfluous refs to DMN and all refs to DMN 1.0

    Remove all unnecessary use of "In DMN..."
    All remaining refs to DMN 1.0 shoul dbe updated to 1.1

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Add association connector (artifact) with text label to represent conditional decision

  • Key: DMN11-47
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In the chapter 11 example, Fig 63 contains an information requirement connector linking Adjudication to Routing. But in reality Routing is not an input to Adjudication. What is meant is that Adjudication is only performed if Routing has certain output value. That relationship is what Vanthienen calls an action subtable, whereas information requirement reflects a condition subtable relationship. Still it is useful to depict such relationships in DRD. I suggest adding a new connector type, association - an artifact as meant by BPMN, i.e. no operational semantics just annotation - to reflect it. A text label could indicate a particular output value that enables the dependent decision.

  • Reported: DMN 1.0 — Tue, 28 Apr 2015 21:20 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    Close - no change required

    Consensus is not to add new type of information requirement connector.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Need for annotations and comments in DRD


Need to clarify which DMNElements must and must not have names

  • Key: DMN11-92
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In the MM, Fig 15, all classes inherit the optional name attribute. Thus, any DMNElement may or may not have a name. What is closer to the truth, is that some DMNElements MUST have a name, and others MUST NOT. Attached is proposed MM that splits the elements into the named and unnamed. There will be numerous text changes, especially to explain that decision tables, being expressions, do not have names. The apparent 'names' of expressions like DTs are really the name of the Information Item that has said expression as its valueExpression. It is dangerous (misleading) to supply a name for an expression, because it may appear that one could refer to the named expression's value by that name. But you cannot. You can only refer to an Information Item by name in an expression.

  • Reported: DMN 1.0 — Tue, 7 Jul 2015 20:01 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    define NamedElement subclass of DMNElement

    Revised text, MM figures, and XSD (github links)

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

XSD: modify Import in tLiteralExpression

  • Key: DMN11-73
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In XSD, top-level element Import is used to make top-level elements in external DMN, XSD, and possibly other types of files visible to the decision model. Import also is part of tLiteralExpression as a way to import value expressions, but it needs additional information. Propose to give this element a different name and type:
    In tLiteralExpression, replace Import with importedValues, type tImportedValues. Add tImportedValues as follows:
    <xsd:complexType name="tImportedValues">
    <xsd:complexContent>
    <xsd:extension base="tImport">
    <xsd:sequence>
    <xsd:element name="importedElement">
    <xsd:complexType>
    <xsd:simpleContent>
    <xsd:extension base="xsd:string">
    <xsd:attribute name="expressionLanguage" type="xsd:anyURI"/>
    </xsd:extension>
    </xsd:simpleContent>
    </xsd:complexType>
    </xsd:element>
    </xsd:sequence>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>

  • Reported: DMN 1.0 — Thu, 11 Jun 2015 18:20 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    replace Import in tLiteralExpression with importedValues, new type

    Revise spec, MM Fig 26, and XSD as directed.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

inputVariable and itemDefinition are redundant in Expression metamodel

  • Key: DMN11-69
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    These are redundant. InputVariable is a pointer to a variable definition, but any expression MUST only reference a variable with unique name in scope, so the pointer is redundant. An expression referencing a name not defined uniquely in scope is an error.

    Similarly, in tExpression, itemDefinition (a pointer to ItemDefinition representing the expression's output datatype) is redundant. The Decision or BKM element also has OutputDefinition, pointer to ItemDefinition that defines the datatype of the output expression. Any variable referenced by an any literal expression also already has a datatype defined by InformationItem.

  • Reported: DMN 1.0 — Thu, 11 Jun 2015 17:42 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    move inputVariable and itemDefinition from Expression metamodel to InputData and Decision (and correct XSD and explanatory text)

    Revise spec, MM, and XSD as indicated.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Decision table default output

  • Key: DMN11-58
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    This issue also relates to isComplete.
    Level 3 decision tables may specify a default output entry to be selected if no rules match. I dont believe this is allowed for level 2. In any case, the default output entry is missing from both boxed expression and xsd for decision table, possibly missing from metamodel also.

  • Reported: DMN 1.0 — Sun, 17 May 2015 16:14 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Add decision table default output

    Add attribute defaultOutputEntry of type tLiteralExpression

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

XSD itemDefinition/typeRef and typeDefinition are underspecified and incorrect

  • Key: DMN11-54
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    itemDefinition is referenced to a base type defined by either a typeDefinition or typeRef. 7.3.2 says typeDefinition is "a String that defines the data structure", but it simply names a built-in type, does not define a structure. It also says typeRef is "a String that references a built-in data type... or a data structure defined at the top level in an external document", but those statements are incorrect as well. Built-in types are named by typeDefinition, typeRef is not String. Structured types are defined by itemComponent and referenced by typeRef, usually NOT in an external document. So this text is completely wrong. This issue also affects how external references are defined, via namespace prefix or filename, via ID or element name. Referenced typed by DMNElementReference are ambiguous and inadequate to cover the range of external references required.

  • Reported: DMN 1.0 — Fri, 15 May 2015 16:23 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    simplify and correct MM and XSD for ItemDefinition

    Proposal is to Merge and close DMN11-25, 56, 57, 71.

    The latest MM diagram (attached) shows ItemDefinition containing itemComponents, which are also tItemDefinition. It also shows ItemDefinition has attribute typeRef and typeDefinition. It is better to have a consistent referencing scheme via typeRef, so typeDefinition should be removed from the MM. Otherwise, the MM is correct, but the XSD is not consistent with this.

    The corrected XSD deletes tItemComponent and defines itemComponent as tItemDefinition. This makes ItemComponent recursive, which resolves and closes DMN11-56 and DMN11-71.

    Also, to make ItemDefinition consistent with DMN11-67, allowedValue is renamed allowedValues, type tUnaryTests, maxOccurs=1.

    It is important that types be referenced consistently via typeRef or itemDefinition, whether the type is:

    (1) a base type (without restriction) in the ItemDefinition's typeLanguage; (2) a custom type (including base types with allowed values) defined in the current Definitions; (3) a custom type defined in an imported DMN model; or (4) a type defined in an imported XSD (or WSDL or other type language). Normally types have names unique in their namespace, and outside of DMN they do not have ids. Therefore tDMNElementReference, a pointer to id, will not work; the best way to reference types is by standard QName. This also resolves 11-25, since now Definitions/@namespace has a purpose.

    A base type in the specified typeLanguage should not require ItemDefinition, nor should an imported type. ItemDefinition is required only for custom types defined in the current document.

    QName is namespace-prefixed pointer to either ItemDefinition/@name (or, for imported XSD type, to xsd:simpleType/@name or xsd:complexType/@name). The prefix must be declared in DMN via xsd:schema/@xmlns:[prefix]="[namespace URI]". This means references to FEEL base types must use prefix for the FEEL namespace, just as references to XSD base types must use prefix for the XSD namespace. For imported DMN documents, the prefix must reference the Definitions/@namespace attribute of the import.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

XSD; modify tItemDefinition by changing tItemComponent

  • Key: DMN11-56
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    ItemDefinition defines the datatype of each variable used in DMN expression. As currently defined, it "works" for FEEL base types, although inefficiently (since it has both @name and typeDefinition, two strings that both name the type). It "sort of works" for imported XSD complex types, as long as you ensure the FEEL elements have valid XML element names (e.g. no spaces, etc.) In that case ItemDefinition/@name names the FEEL type and typeRef is a QName pointer to complexType defined in imported XSD. In the general case, for FEEL complex types defined inside the DMN model, it doesn't work very well.

    It is clumsy for defining data structures more than 2 levels deep. ItemDefinition may contain a list of itemComponents, each with a name and pointer to another ItemDefinition. So to define a type that is 3 levels deep, you would have to define one or more 2-level ItemDefinitions, and then the top-level ItemDefinition would use those as itemComponents and point to their ItemDefinitions. Also, the current schema is missing cardinality information (in xsd, @minOccurs and @maxOccurs), important in the definition of a complex type:

    I propose a change to tItemDefinition by changing tItemComponent. Child itemComponents are now contained in a parent itemComponent, not referenced, just like a complexType in XSD. I would like to make ItemDefinition/@name a required attribute, since it names the type, but am unable to do this without making it required for all tDMNElement. So the spec should just say, even though optional in schema, ItemDefinition/@name is required.

    See attached doc with diagram. I will provide also revised dmn.xsd.

  • Reported: DMN 1.0 — Sat, 16 May 2015 17:56 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    no longer relevant

    no longer relevant

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Question on boxed invocation format

  • Key: DMN11-50
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In Chapter 11 examples, most boxed invocations - Fig 76, 78, 80, 81 - have format in which the "tab" names the invoking element and the top line of the box, above the parameter list, names the invoked element. Fig 82 is different. The tab names the invoking element, the top line of the box lists the parameters of the invoking element, then the parameter list, and the bottom row names the invoked element.

    That seems inconsistent and a mistake.

  • Reported: DMN 1.0 — Mon, 4 May 2015 21:41 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    issue seeking clarification only

    issue was clarified in comments

  • Updated: Tue, 29 Mar 2016 15:07 GMT

typos for DMN 1.1 RTF final report

  • Key: DMN11-175
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    All reviewers, please log minor typos here.

  • Reported: DMN 1.0 — Thu, 29 Oct 2015 17:26 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    errata found in review of V4 of clean spec

    see revised text. Some of these are clearly more than typos, more like omission of some editing instructions.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Information item name on DTs not correct in some figures

  • Key: DMN11-166
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    The top box of a DT should display the Information Item determined by the table, i.e. the name of the decision or BKM for which the DT is the logic.

    In Figs 32, 34 and 36, "table name" should read "information item".

    We should also clarify by adding to the first bullet point in 8.1 "Usually this will be the name of the Decision or Business Knowledge Model for which the Decision Table provides the decision logic."

  • Reported: DMN 1.0 — Thu, 29 Oct 2015 08:57 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Correct figs 29, 31 & 33 and clarify DT information item

    Correct figs 29, 31 & 33 (32, 34 & 36 in v3) by replacing "table name" with "information item name"

    Clarify the typical use of this box in the Introduction to Decision Tables (8.1)

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Decision table MM and xsd need output label attribute

  • Key: DMN11-139
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Decision table notation has an output name (renamed output label by DMN11-43) but there is no place in the MM for this label. Cannot use output clause name because this is the name of the component in a multiple component output.

  • Reported: DMN 1.0 — Wed, 30 Sep 2015 23:43 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    add outputLabel attribute to DecisionTable MM (and xsd)

    see attached MM

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Need InformationItem for the FunctionDefinition of a BKM

  • Key: DMN11-137
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    At the decision logic level, one does not 'invoke' a BKM; rather, one invokes the FunctionDefinition that is contained in the BKM. How does one refer to the FunctionDefinition by name? Logic refers to InformationItems by name, it does not refer to the DRGElements directly by name. Therefore, a BKM should contain an InformationItem of the same name whose value expression is the FunctionDefinition contained in the BKM.

  • Reported: DMN 1.0 — Thu, 24 Sep 2015 21:58 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Add InformationItem child to BKM

    see attached MM figure. Need git pointer to XSD.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

would like to annotate Expression with typeRef

  • Key: DMN11-127
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    when we removed the redundant variable references from Expression, we also removed the redundant InformationItem (now typeRef) reference. The result type of an expression is redundant because you can always compute the result type from the input types, and a good tool will have to perform this computation anyway in order to verify that the redundant value is correct. However, simple tools may benefit from a declaration of the expected type of an expression, and the benefit may outweigh the drawbacks of redundancy, hence the issue.

  • Reported: DMN 1.0 — Fri, 28 Aug 2015 23:33 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    add typeRef attribute to Expression, and derived association to ItemDefinition

    Affects MM, XSD, and spec text

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Decision, InputData, and other containers of InformationItem do not ref ItemDefinition directly

  • Key: DMN11-123
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The InformationItem has a typeRef, which may ref ItemDefinition (derived association)

  • Reported: DMN 1.0 — Thu, 27 Aug 2015 15:51 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    replace associations to InformationItem with typeRef (datatype) and derived associations

    This corrects DMN11-86, which is already on ballot 6. Also, replace attached figures, relevant changes highlighted.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Knowledge Source metamodel diagram missing

  • Key: DMN11-120
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    section 6.3.10 describes the KnowledgeSource metamodel but has no diagram. KnowledgeSource and AuthorityRequirement is shown in figs 17,19 in a confusing manner and need correction.

  • Reported: DMN 1.0 — Mon, 24 Aug 2015 22:50 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Add Knowledge Source diagram and clean up KnowledgeSource in Figs 17 and 19

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Definitions/@namespace has no purpose

  • Key: DMN11-25
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    p38 says "An instance of Definitions has a namespace, which is a String. The namespace identifies the default target namespace for the elements in the Definitions and follows the convention established by XML Schema." I think this is mistaken. The convention established by XML Schema relates to schema/@targetNamespace in the XSD. Definitions/@namespace "follows" (or did in the beta version) the convention established by BPMN 2.0, which is specifically for identifying external references as a variant of QName, using the prefix of the declared target namespace and the ID of the element in that namespace. DMN FTF no longer uses that convention, so Definitions/@namespace has no purpose, although it is a required attribute. I would like to see a return to the beta format of external references (making Definitions/@namespace relevant), since there are explicit pointers from DMN to BPMN processes and tasks, and it makes no sense for DMN to use a different referencing mechanism (based on filename not namespace) than the one BPMN uses to reference other BPMN models.

  • Reported: DMN 1.0 — Mon, 9 Mar 2015 19:30 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    treat namespace as part of the qualified name for imported elements

    presumably if a decision D requires an imported decision E from namespace S, then D's logic can refer to S.E (but where do we say that?)

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Constraints on Decision Table elements unclear

  • Key: DMN11-24
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    The S-FEEL and FEEL grammars of chapters 9 and 10 suggest a much wider range of allowed syntax in decision tables than are illustrated in any examples of the spec. For example, input entries and output entries may reference one or more "names" - presumably variables - but in the examples they reference only literal values. Also, all examples of input expressions are simply variable names, not expressions. Additional text is needed to explain what is allowed and not allowed in decision table elements.

  • Reported: DMN 1.0 — Mon, 9 Mar 2015 19:00 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Text to explain constraints on decision table elements

    These edits reflect grammar rule changes consistent with what is allowed in decision table elements under DMN11-49, resolving ambiguity of the terms "name", "expression", and other inconsistencies. This proposal was reviewed and agreed by Jan Vanthienen and myself and is ready for consideration by RTF.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Expression defined as resulting in single value, but Decision may have multiple values

  • Key: DMN11-22
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    This is related to DMN11-9. Expression class is defined in 7.3 and 7.3.1 as "return a single value when interpreted", but Decision (e.g. DecisionTable, concrete subclass of Expression) may return multiple values, in two ways. Compound output tables, and multi-hit Collect tables. I suggest removing the "single value" comment from definition of Expression, or applying it only to a different class than the superclass of DecisionTable.

  • Reported: DMN 1.0 — Mon, 9 Mar 2015 18:44 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Revise text to clarify Expression as "single value".

  • Updated: Tue, 29 Mar 2016 15:07 GMT

input expression example 'age<25' is not legal in SFEEL grammar

  • Key: DMN11-21
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    8.2.3 says "Input expressions are usually simple, for example, a name (e.g. CustomerStatus) or a test (e.g. Age<25)." However, under the S-FEEL grammar of 9.1, Age<25 is not a simple expression.

  • Reported: DMN 1.0 — Mon, 9 Mar 2015 17:51 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Revise SFEEL grammar to allow comparison in input expression

    The revisions to S-FEEL grammar allow comparison in CL2 input expression. Attachments for discussion only and not part of proposal.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

In metamodel, 'variable' should move from Information Requirement to Decision / Input Data

  • Key: DMN11-65
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In 6.3.11 it says the notation for an information requirement is a plain arrow (from a required decision or input data). Arrows have no labels. Yet, table 14 shows a 'variable'. Presumably, this variable must be the same as the required decision or input data. Therefore, the variable should be removed from the InformationRequirement class, and the Decision class and InputData class should extend the InformationItem class. Variables are of type InformationItem.

    Proposed: remove 'variable' from table 14. Make DRGElement extend InformationItem (figures 15, 17, 19, 20 and supporting text). Remove 'informationRequirement' and 'valueExpression' from table 20. Define the qualified name of an imported DRGElement to be of the form prefix . localPart where prefix must be distinct for each import element.

  • Reported: DMN 1.0 — Thu, 4 Jun 2015 05:31 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    text changes to support move of InformationItem in MM/xsd

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Decision table completeness undefined, Complete code conflicts with Collect

  • Key: DMN11-32
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    All figures showing decision tables need to be reviewed for correct hit policy and completeness codes. Many examples of UC and HC, which are not allowed in FTF version.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 18:45 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Remove completeness info from model and notation

    we can define completeness of decision table rules, so that tools behave consistently, but there seems to be no clear need to model or notate completeness as a separate flag.

    Many DT figures have a 'C' meaning Complete - these must all be removed.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Dangling reference

  • Key: DMN11-35
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    FEEL datatypes are listed in 10.3.2.2. There is no such list. They are described below, in numbered sections, but not in a list.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 20:39 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    replace ref to 10.3.2.2

    rewording in revised text

  • Updated: Tue, 29 Mar 2016 15:07 GMT

extraneous asterisks (*)

  • Key: DMN11-34
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    No idea what the asterisks mean:
    FEEL([1+1, 2+2]) *is [2, 4]*.
    Proposed: replace with bold text between asterisks and remove asterisks.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 20:36 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Remove extraneous asterisks in 10.3.2.1

    In clause 10.3.2.1, the example
    FEEL([1+1, 2+2]) is [2, 4]
    should not contain the asterisks, which are the result of a copy-paste error from JIRA.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Beta2 XSDs are broken

  • Key: DMN11-60
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Both dmn.xsd and dmn3.xsd at http://www.omg.org/spec/DMN/1.0/Beta2/ have problems. Two small issues prevent any use of dmn3.xsd. Four occurrences of type="tExpression" must be changed to type="tLiteralExpression" in dmn.xsd before it can be used to serialize decision tables and enumerations.

  • Reported: DMN 1.0 — Fri, 22 May 2015 17:54 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    correct 2 issues in dmn3.xsd and 1 issue (4 occurrences) in dmn.xsd

    Note that previous issue DMN11-91 has combined dmn3.xsd into dmn.xsd
    2 occurrences of type="tExpression" to type="tLiteralExpression" made by this issue, and
    2 occurrences of type="tExpression" to type="tUnaryTests" made for issue DMN11-81.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

authorityRequirement in XSD

  • Key: DMN11-52
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    tAuthorityRequirement is incorrect. This element is contained in a decision, BKM, or KnowledgeSource. It should reference a KnowledgeSource, but in XSD it is a choice between requiredDecisionRef, requiredInputRef, and requiredAuthorityRef. Propose replace that choice with requiredAuthorityRef, pointer to the KnowledgeSource.

  • Reported: DMN 1.0 — Thu, 7 May 2015 18:47 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    issues seeking clarification

    issue clarified

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Remove attribute DecisionTable/@isConsistent

  • Key: DMN11-44
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    I think this attribute is inappropriate. It reflects a model validation condition, not a design-time property. Moreover, it has default value "false", suggesting that any model that omits this attribute is intentionally inconsistent, which makes no sense to me.

    This is a bit different from isComplete, where false could possibly be intentional at design time.

  • Reported: DMN 1.0 — Thu, 23 Apr 2015 22:32 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    *Remove consistency info from model *

    we could define the concept of consistency, so that tools will behave consistently, but it does not seem to belong in the model. Rules are either consistent or not, regardless of what some flag might say.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

change "output expression" to "output name"

  • Key: DMN11-43
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In decision table, Fig 27, 28, and third bullet on p66 refer to output expression. The other figures and the metamodel/schema refer to output name. I don't believe the output column heading can be an expression, just a name. Suggest replace "output expression" with "output name".

  • Reported: DMN 1.0 — Thu, 23 Apr 2015 22:02 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    correct callouts in Figs 27&28, create additional figures for multiple outputs

    attached figures to be replaced/inserted, with indicated revised neighboring text. No MM or XSD change.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:
    • Fig27-30Prop118.docx 753 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

add Definitions optional attributes exporter, exporterVersion

  • Key: DMN11-30
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    For model interchange, BPMN has shown these attributes useful for identifying the tool name and version used to create the serialization. The importing tool may have special mappings for certain exporters.

  • Reported: DMN 1.0 — Sun, 12 Apr 2015 16:03 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    add Definitions/@exporter, @exporterVersion

    optional string attributes used to identify the tool that created the serialization, to aid in model interchange

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

DMN 1.1 RTF Issue: Negative numerics in decision tables

  • Key: DMN11-13
  • Legacy Issue Number: 19731
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    The syntaxes defined in 9.1 (S-FEEL grammar) and 10.3.1.2 (FEEL grammar) do not permit decision table input entries to contain negative numeric values.

    9.4.3: An input entry is a simple unary tests, defined using:

    14: simple unary tests

    13: simple positive unary tests

    7: simple positive unary test

    8: interval

    18: endpoint

    19: simple value

    33: simple literal

    36: numeric literal: [0-9] & “.”

    I suggest a numeric literal should be allowed to start with a minus sign.

  • Reported: DMN 1.0 — Mon, 2 Mar 2015 05:00 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    allow numeric literal to start with minus sign

    according to the current grammar, numeric literals cannot have a minus sign, so neither can range endpoints, which are not arbitrary expressions.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Nested ItemDefinition doesn't work

  • Key: DMN11-147
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The intent of ItemDefinition and itemComponent was to allow nested structures, such as Order contains a list of items, each item having an ID, Description, and Quantity. This isn't possible without having to create intermediate ItemDefitions and refs.

  • Reported: DMN 1.0 — Fri, 9 Oct 2015 18:21 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    close as duplicate

    close as duplicate

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Clarify defaults for decision table outputs

  • Key: DMN11-130
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    The spec states (8.2.12) "Incomplete tables may specify a default output. The default value is underlined in the list of output values." This needs two points of clarification:

    (a) When a default is specified, a decision table is ipso facto complete. I propose we drop the word "incomplete".
    (b) The spec does not say how to use defaults when the output is compound. Can we specify defaults for some output columns and not for others? If so, what value would the output take on default, for the columns where no default was specified? If not, we should say that defaults must be specified for all output columns or none.

  • Reported: DMN 1.0 — Wed, 2 Sep 2015 14:14 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    close, addressed by other proposals

    closed, no longer relevant

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DMN issue: date syntax in table 29

  • Key: DMN11-7
  • Legacy Issue Number: 19691
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36

    On page 116, in clause 10.2.2.1, the Beta 2 document introduces Table 29, “String, date, time and duration comparisons, which shows one FEEL Expression: “2012-12-31 in (2012-12-25..2013-02-14)”. The example is invalid because FEEL has no literal syntax for dates. This example should use the date() built-in function.

    Also, this table should be combined with Table 28, immediately above since they both give examples of the same kind.

  • Reported: DMN 1.0 — Wed, 17 Dec 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Combine tables 28 & 29 and change formatting

    revise text as indicated

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DMN Issue: typo in 3rd well-formed requirement of KnowledgeRequirement

  • Key: DMN11-6
  • Legacy Issue Number: 19690
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Reference the DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG document number dtc/14-11-36

    On page 61, clause 6.3.12 describes the “Knowledge Requirement metamodel”. In the section on well-formed KnowledgeRequirements, the third bullet beginning “if the InformationRequirement element …” should instead read “if the KnowledgeRequirement element ….”

  • Reported: DMN 1.0 — Tue, 16 Dec 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Correct typo in 3rd well-formed requirement of KnowledgeRequirement

    On page 51, clause 6.3.12 describes the “Knowledge Requirement metamodel”. In the section on well-formed KnowledgeRequirements, the third bullet beginning “if the InformationRequirement element...” should instead read “if the KnowledgeRequirement element.…..”

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DMN issue: typo in introduction of "Relating Logic to Decision Requirements"

  • Key: DMN11-4
  • Legacy Issue Number: 19688
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36

    The bullet at the top of page 64, in clause 7.1, contains the following garbled sentence: “The variables that are used in the body of the function defined by a business knowledge model element in the DRG must be bound to the information sources each of the requiring decision.”

  • Reported: DMN 1.0 — Tue, 16 Dec 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    correct the typo

    see revised text

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XSD internally inconsistent, does not match the spec

  • Key: DMN11-9
  • Legacy Issue Number: 19724
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    I believe the XSDs are seriously messed up. On the surface, this would be apparent to anyone who tried to open the level 3 xsd in an XML editor, since the “include” fails right off the bat and the tool goes ding ding ding. Not only does it point to the wrong filename, but the namespace is different, not allowed with include. You can fix those things by making the namespaces match and fixing the filespec. Actually I don’t care that much about the level 3. I am more concerned with the 14-08-19.xsd, the Level 1 and 2.

    That one has an element named ItemDefinition and another one named itemDefinition with different datatype, which is confusing. I believe that the latter is a pointer to the former. If so, you will have a lot less confusion by renaming the latter itemDefinitionRef.

    But the problem with the XSD goes a lot deeper. Maybe it is my lack of understanding of the spec, I don’t know. I think the central problem is that tExpression (the datatype for inputExpression, inputEntry, outputEntry, range of allowed values, and many other elements) is just a list of inputVariables and possibly a single itemDefinition(Ref). It is NOT an expression, in natural language, S-FEEL, or anything else. Maybe the intent was to allow literal expressions, but the XSD does not reference tLiteralExpression, just tExpression. Or maybe the intent was to do like BPMN and make tExpression a mixed-content type, where the expression string is the direct content of the element, but the XSD does not say that, either. Or maybe the intent is to put the expression in the any ##other element or attribute? That would work but be very weird. Anyway, without that I think it would be an impossible challenge to serialize even the simplest decision table per the XSD. And maybe that is why there are no serialization examples in the spec.

  • Reported: DMN 1.0 — Tue, 17 Feb 2015 05:00 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    overall, early list of possible xsd issues subsumed by more focussed issues

    All the substantive have been addressed by other issues. This can be closed.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XMI issues from Pete Rivett

  • Key: DMN11-3
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    There are some issues with the XMI:

    • The top level element should be a uml:Package not a uml:Model
    • There is a proprietary namespace at the top of the file which should just be deleted: there is no longer any need for such a profile and it should be removed from the original MagicDraw model xmlns:cmof_Profile="http://www.magicdraw.com/schemas/cmof_Profile.xmi">
    • Likewise you don’t need the UML StandardProfileL3.
    • On the other hand you do need a MOF tag to declare the namespace prefix
    • The default value which is an enumeration should have a “type” property referencing the enumeration

    Attached is the updated file.

  • Reported: DMN 1.0b1 — Tue, 19 Aug 2014 07:15 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    these are issues with 1.0 - will try to incorporate into 1.1

    these are issues with the XMI produced for 1.0. We are not changing 1.0.
    I have tried to avoid these issues in 1.1

  • Updated: Tue, 29 Mar 2016 15:07 GMT

S-FEEL "expression" undefined

  • Key: DMN11-23
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    The S-FEEL grammar in 9.1 references "expression" in rules 21-26, but "expression" is undefined in S-FEEL. Probably "expression" in those rules should be replaced by "simple expression", which is defined.

  • Reported: DMN 1.0 — Mon, 9 Mar 2015 18:47 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    duplicates issue 24

    duplicates issue 24

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: DecisionTable/rule/condition should be IDREF not IDREFS

  • Key: DMN11-27
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    This element is a pointer to one inputEntry (and implicitly to its clause) so it should be IDREF, not a list. The element is unbounded, so references to other inputEntry elements are contained in other condition elements of the same rule.

  • Reported: DMN 1.0 — Mon, 9 Mar 2015 19:42 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    merge with issue 81 to remove the level of indirectlion

    we think that intra-decision table references are a significant complication with no useful purpose. Thus, merge with 81.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

need to add UnaryTests to MM and XSD

  • Key: DMN11-109
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    This is to complete the proposal begin by issue DMN11-24 proposal DMN11-67

  • Reported: DMN 1.0 — Thu, 6 Aug 2015 16:31 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    solved as part of DMN11-81

    The necessary changes have been done in DMN11-81.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: change type of LiteralExpression/text, ItemDefinition/typeDefinition, and (new) textAnnotation/text to xsd:string

  • Key: DMN11-102
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Currently these are mixed content type in which the direct content is untyped, and any additional child elements must be in a different namespace. they should simply be string.

  • Reported: DMN 1.0 — Tue, 21 Jul 2015 17:22 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    change mixed content elements to string

    xsd change only

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Decision Table metamodel and XSD should restrict input entries, input values, and output values to unary tests, and LiteralExpression for input expressions and output entries

  • Key: DMN11-84
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Current MM allows any expression for input entries. The spec restricts these to text strings with syntax of unary tests (or simple unary tests). Also, unary tests are not expressions and are not literal expressions.

  • Reported: DMN 1.0 — Fri, 26 Jun 2015 23:26 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    *merge with 81 - removing indirection from decision table *

    So that all the decision table MM and XSD changes can be done together, we combine these issues.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

8.2.10 calls crosstab tables "rules as columns"

  • Key: DMN11-88
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Figure 41 and 42 are crosstab (columns and rows are input values) but called vertical/rules-as-columns. Surrounding text in 8.2.10 also incorrect.

  • Reported: DMN 1.0 — Mon, 29 Jun 2015 23:12 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    OK as is

    I agree with comments, withdraw the issue.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: make @id optional in tExpression

  • Key: DMN11-80
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Except for DT rule conditions and conclusions, id pointers to expressions are rare (maybe none?). Propose change @id in tExpression from required to optional.

  • Reported: DMN 1.0 — Fri, 19 Jun 2015 16:14 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Change tExpression/@id to use="optional"

    Change value of attribute 'use' from 'required' to 'optional'.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

FEEL/S-FEEL names

  • Key: DMN11-62
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    S-FEEL grammar rules 30-32 list characters that can be part of names. I do not see space (\u20) as one of the allowed characters or "additional symbols". There are lots of Unicode characters and symbols that probably should not be allowed.

  • Reported: DMN 1.0 — Sat, 30 May 2015 22:25 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    name symbols mostly copied from xml, but we do add the space!

    can open new issue in 1.2 if spaces are really a problem for implementations

  • Updated: Tue, 29 Mar 2016 15:07 GMT

list variables in decision tables

  • Key: DMN11-33
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Is it correct to say that a list is not allowed as an input expression in S-FEEL? That would mean that a supporting decision with Collect hit policy could not provide input to a dependent decision table. If it is allowed, I don't think S-FEEL input entry can distinguish "every member of the list is in [literal list]" from "any member of the list is in [literal list]". I believe it would be allowed in full FEEL... but unclear if decision table can use this.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 19:16 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    no change required for input expression

    If an input variable is a list, then input expression can reference it.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: Relation and List

  • Key: DMN11-76
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Relation is a particular boxed expression format for a list of similar contexts. It is a two-dimensional grid. Each row (unlabeled) represents a context, and each column a context entry. dmn3.xsd does not properly represent this. Also, Gary suggested organizing the grid in the xsd by rows (contexts) rather than by columns, as it is now in dmn3.xsd.

  • Reported: DMN 1.0 — Thu, 11 Jun 2015 19:04 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    Modify tList and tRelation in dmn3.xsd

    Withdrawn.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Xsd typeRef and itemDefinitionRef

  • Key: DMN11-57
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In xsd, ItemDefinition links the type either to a base type via typeDefinition or some other type via typeRef. If the other type is defined externally in imported xsd, typeRef should be QName, pointer to a name, which it is. But to reuse a type defined in another ItemDenition, it should be itemDefinitionRef, pointer to an id. Propose that itemDefinitionRef be added to the choice in ItemDefinition.

  • Reported: DMN 1.0 — Sun, 17 May 2015 16:09 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    Resolved in DMN11-54

    Resolved in DMN11-54

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: add optional @name to inputVariable

  • Key: DMN11-55
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In a decision logic expression, inputVariable is an ID reference to an InformationItem, which provides the variable's name. The expression (e.g. binding expression or literal expression) then references the variable by name. This works operationally, but the logic of the XML would be much easier to follow and debug if the inputVariable allowed an optional name attribute to hold the variable's name.

  • Reported: DMN 1.0 — Fri, 15 May 2015 20:07 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    Merged with and Resolved by DMN11-69

    I submitted this issue but now I think better approach is to remove id references like inputVariable in tExpression and use names instead. This issue is thus merged with DMN11-69 and resolved by that proposal.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

FEEL concatenate function

  • Key: DMN11-53
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In Table 58, concatenate and append are essentially the same list function in FEEL. There is no concatenate string function in Table 57. Propose concatenate be moved to Table 57 as a string function (where it is most needed).

  • Reported: DMN 1.0 — Tue, 12 May 2015 00:03 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    string concatenation uses the "+" operator rather than a builtin function

    string concatenation is defined in Table 42

  • Updated: Tue, 29 Mar 2016 15:07 GMT

dmn3.xsd

  • Key: DMN11-48
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    This issue separates the dmn3.xsd issues from DMN11-9, which otherwise concerns dmn.xsd.
    There are a number of serious problems with dmn3.xsd:
    1. Syntactically incorrect. The include of dmn.xsd points to the wrong filename. The only reason why include is needed (syntactically) is to reference tExpression.
    2. tExpression is not the right datatype for the elements. See DMN11-9 for why.
    3. dmn3.xsd does not represent what 12.2.2 says it does. It is not an interchange format for Level 3 decision models! It is just a schema for a context. And it is not even the right schema for a context. Serialization of a context does not use elements named ContextEntry, List, Relation, etc. You can see that from 10.3.3.3.1 and 10.3.3.3.2. I think it is meant to clarify the semantics of context, but it would never be used in serialization.

    For these reasons I propose that 12.2 is modified and dmn3.xsd is removed from the specification. If a separate schema is needed to serialize Level 3, it must contain the whole thing, starting from Definitions. I don't think a separate schema is needed, but we should check if the existing element for output variable, InformationItem, can describe a context.

  • Reported: DMN 1.0 — Thu, 30 Apr 2015 15:14 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    close and merge with dmn11-91

    The issues with dmn3.xsd are addressed by dmn11-61, dmn11-94 and others.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

output data symbol & comment symbol missing in DRDs

  • Key: DMN11-42
  • Legacy Issue Number: 19746
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Please add an optional output data symbol and a comment symbol, which I both urgently miss, as discussed in the LinkedIn DMN group at
    https://www.linkedin.com/groups/Why-no-output-data-symbol-4225568.S.5976658175284244483

    Summary: Why is there no output data symbol in DMN 1.0's DRDs?
    Decisions have results, which may be complex, and currently their output data may only be indicated by the decision's name (e.g. "determine X": output is X; "check X": result is Boolean). That is not very clear.

    An optional output data symbol would make decision output graphically explicit, and provides for symmetry.

    DMN also lacks a comment symbol which could otherwise be used for this on DRDs.

  • Reported: DMN 1.0 — Fri, 17 Apr 2015 04:00 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    add text annotations in DMN11-99 but decline to add output symbol

    output symbol seems redundant with existing decision symbol (an decision has always exactly one output) and we don't want to clutter a large DRD

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Clarify Decision/outputDefinition, DecisionTable/clause/outputDefinition, DecisionTable/@name, clause/@name

  • Key: DMN11-39
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    The issue is illustrated by Fig 36 on p71. The resolution should be clarified in the text.
    8.2.5 says (I think) that Decision/@name = DecisionTable/@name = label in output column header in the decision table.
    For a single-output DT, Decision/outputDefinition* and DecisonTable/clause/outputDefinition* both point to an itemDefinition defining the data type of the output.
    For a compound-output DT, the compound output name is DecisionTable/@name. Decision/outputDefinition is a pointer to an itemDefinition for the compound output, but the spec does not describe how such a compound output should be constructed. Each individual output name is given by DecisionTable/clause/@name (for an output clause), and the clause/outputDefinition is a pointer to its datatype.

    • renamed outputDefinitionRef in proposed revision to dmn.xsd, see DMN11-9. In any case, these elements should be given different names.
  • Reported: DMN 1.0 — Thu, 16 Apr 2015 19:30 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    Merge with DMN11-43

    Some of this is resolved by other MM changes to decision table. The issue of output names and clause names is the focus of DMN11-43.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Examples

  • Key: DMN11-29
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    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.

  • Reported: DMN 1.0 — Sun, 12 Apr 2015 15:39 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    no volunteers, no time for 1.1

    agreed to be important for 1.2

  • Updated: Tue, 29 Mar 2016 15:07 GMT

not all references in DMN are by ID

  • Key: DMN11-152
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    new typeRef is by name, not ID, as claimed in beta2 spec 12.3.2

  • Reported: DMN 1.0 — Wed, 21 Oct 2015 01:38 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Correct text for XSD references (12.3.2)

    see revised text

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DMN Issue: Boxed context example of XML data is wrong

  • Key: DMN11-8
  • Legacy Issue Number: 19692
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36

    Clause 10.3.3.3.3 on page 144 shows a boxed context that is supposed to be the equivalent of the XML example shown in clauses 10.3.3.3.1 and 10.3.3.3.2. This boxed content is missing a horizontal line immediately below the row that contains “tns$Employee”.

  • Reported: DMN 1.0 — Wed, 17 Dec 2014 05:00 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    the line is there in the 'real' spec

    line was missing in a version used by reviewer

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Change Tracking Document

  • Key: DMN11-1
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    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.

  • Reported: DMN 1.0b1 — Tue, 21 Oct 2014 06:32 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    transferred automatically from FTF

    transferred automatically from FTF

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DMN issue: InformationItem is not a specialization of Expression

  • Key: DMN11-5
  • Legacy Issue Number: 19689
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36

    On page 75, in clause 7.3.4, the 6th paragraph starts “As a concrete specialization of Expression, an InformationItem element ….” However, none of the UML diagrams show a generalization relationship between InformationItem and Expression.

  • Reported: DMN 1.0 — Tue, 16 Dec 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    merge with issue to clarify relationship of Information Item and Expression

    proposal for issue 65 resolves this issue as well

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Incorporate AB feedback into the FTF Report, the marked-up specification, and the clean specification

  • Key: DMN11-2
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

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

  • Reported: DMN 1.0b1 — Sat, 13 Sep 2014 20:37 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    automatically transferred from FTF

    nothing to do in RTF

  • Updated: Tue, 29 Mar 2016 15:07 GMT

BigDecimal is not the only mapping of number to Java

  • Key: DMN11-11
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    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.

  • Reported: DMN 1.0 — Wed, 9 Jul 2014 21:23 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    no one volunteered, we'll try again in 1.2

    roll forward to 1.2

  • Updated: Tue, 29 Mar 2016 15:07 GMT

cannot interchange input data style

  • Key: DMN11-10
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    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.

  • Reported: DMN 1.0b1 — Sat, 9 Nov 2013 00:33 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    defer to 1.2

    no proposal submitted for 1.1

  • Updated: Tue, 29 Mar 2016 15:07 GMT

No notation for ItemDefinition

  • Key: DMN11-66
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    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.

  • Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    carry over to 1.2

    carry over to 1.2

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Consider date and time datatype in S-FEEL

  • Key: DMN11-46
  • Legacy Issue Number: 19755
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    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.

  • Reported: DMN 1.0 — Tue, 28 Apr 2015 04:00 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    defer to 1.2

    No proposal was submitted for 1.1

  • Updated: Tue, 29 Mar 2016 15:07 GMT

alternative indication of reusable logic in DRD

  • Key: DMN11-51
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    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.

  • Reported: DMN 1.0 — Tue, 5 May 2015 17:58 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    no time in 1.2

    defer to 1.2

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Business Context links go both ways

  • Key: DMN11-31
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    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.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    defer to 1.2

    minor issue, no strong advocate to change in 1.1

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Need group artifact in DRD, metamodel, and XSD

  • Key: DMN11-116
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    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.

  • Reported: DMN 1.0 — Thu, 20 Aug 2015 00:13 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

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

  • Updated: Tue, 22 Dec 2015 15:43 GMT
  • Attachments: