The feedback below is merged from the AB (Architecture Board) reviewers, BMI meeting review, and other emails, Mar 2011. Note that the revised doc no is 11-03-01…
Suggestion to revert to “classification” and make sure this is consistent.
Needs clarification, eg replace “build on” with “reference”.
References to concrete syntax could be conflated with MOF?
Include multiple vocabularies as an option? Clarify.
Add IMM etc models as options.
Reword to clarify.
“From an a”?
Clarify. Note OMG Diagramming Standard is no longer proposed but a standard.
Reword to clarify that UML (including Class, etc) models could provide the vocabulary.
* Deliverables - MOF & Concrete Syntax? MOF & UML Profile?
6.2 1. Decision model, possibly in MOF
2. Links as required to existing OMG metamodels (MOF should be mandatory given the required deliverables mentioned below)
4, 5. Concrete Syntax (Decision Model Notation)
6 Reuse of logical artifacts
* Concrete Syntax should be specified using the Diagram Interchange specification (that which the BPMN 2.0 notation was defined in ptc/2010-12-18)
1. With regard to MOF, you have made it clearly optional. But you’ve introduced the phrase “integrated via MOF support” on page 3. Such integration would obviously depend on formulating DMN using MOF, so I am surprised that you introduced the phrase. “integrated via MOF support or otherwise” would be nearer the mark, I think.
2. You choose “typology” in 6.5.1 but immediately start talking about classification – “the proposed classification …”. You should stick to one of them. Classification is defined (online) as “the allocation of items to groups according to type”. That seems to be what you want: “the allocation of decision models to groups according to type”
3. You still have an apparent contradiction between “The classification shall explain how different types of models differ in terms of the attributes and properties of decision models according to the proposed metamodel” and “It (the metamodel) shall support a subset of the Decision Model Typology”. If you have a model X containing some aspect that is not in this subset, you are apparently still obliged to explain how it differs (from another model Y which may or may not be in the subset) according to the proposed metamodel, despite the fact that X (and perhaps Y) is not described by the proposed metamodel. The explanation can only possibly extend to those aspects of the compared models that actually are described by the metamodel. I suggest the first sentence could instead be “The classification shall explain how different types of models differ in terms of constructs that are defined by the proposed metamodel”.
The feedback below is merged from the AB (Architecture Board) reviewers, BMI meeting review, and other emails, Sep-Dec 2010.
The title is a bit of a misnomer since it asks for a lot more than a notation. ⇒ need to explain why in abstract
The abstract includes ‘BPMS’ which is not obvious ⇒ expand abbreviations and glossary
The red text – notes to RFP authors - should all be removed. ⇒ Yes :)
Need to emphasise business level standard
6.2 includes the phrase “non-exclusive compatibility” which is not clear ⇒ reword - this is that it should be compatible with BPMN notation, but should also be independent of BPMN
6.2: the sentence “The motivation for OMG submitters to DMN” is not clear – is the motivation for people to submit, or the broader benefits of such a standard? ⇒ need to reword (actually the meaning is surely both :)
Need use cases to explain decisions, decision models, role of DMN… ⇒ New Appendix with BRMS use cases, decision modelling use cases, etc
Clarify NOT a new language per se - will reference & re-use existing standards or subsets thereof
6.3.1: the 3 level CIM/PIM/PSM view of MDA is somewhat outdated ⇒ OK, but replaced by what? Will keep unless alternative suggested
126.96.36.199: Case Management is a real RFP not a ‘proposed RFP’ ⇒ needs updating
Comparison with UML action languages and why these are insufficient for decision modelling… ⇒ needs expanding, how xUML != business model, and xUML is potential PSM mapping from DMN
Value to other domain specs and groups eg C4I, VDM ⇒ add general comment on how other domain standards may want to embed, extend or refer to DMN for decisions
188.8.131.52, 3: what’s’ the relevance of the ISO standard and Codasyl document ⇒ need to explain what these are and how they fit in DMN
6.5.1: what form should the Classification take? ⇒ need to add FOR EACH requirement WHAT form is expected, if any predicated. In this case we could say (1) text description of the classification and (2) metamodel accomodation / placeholders / explanation for potential expansion to cover this classification
6.5.2: What is behind the statement that ’No specific MOF format is required’? Is some sort of MOF format required? ⇒ needs rewording to some MOF format required, with the choice of MOF dialect (EMOF, CMOF, SMOF) to be determined by the submitter; also use “well formedness” in para1
6.5.3: Unclear what is meant by a ‘layer’ of decision. Is it related to 6.5.2 where t seems to refer to incremental development of decision models? ⇒ needs to refer to examples in an appendix… such as ruleflow to DTable, KPI Decision Model to their DTably type, etc
6.5.4: Why exclude interchange of visual notation – especially since we now have Diagram Definition? In fact submitters should be encouraged to use DD to formally define the notation and this should be part of 184.108.40.206. ⇒ needs rewording to explain that an existing OMG DD or BPMN DD format should be used (and should be referenced in 6.3)
6.5.4: Unclear what is meant by the last sentence “External dependencies and constraints may be required for DMN interchange across tools.” ⇒ needs rewording
In Dtables refer to appendix on possible other representations eg DTrees, Score Models, ruleflows, etc
220.127.116.11: ‘visually compatible’ is vague. Surely some interchange is required not just a visual similarity. ⇒ needs rewording - this simply means the notation should have the appearance of being an extension of BPMN2 notation
18.104.22.168: Why only UML Classes and not Properties, Associations, Operations, processes etc. ⇒ needs rewording as clearly this meant to relate to contents of UML Class diagrams, including the related entities (to Class) in UML
In addition to UML why not ODM and in particular IMM. ⇒ indeed these should be options
What about SoaML? ⇒ need to make some comment about vocabularies based on UML eg SoaML etc also should be able to inherit / re-use DMN
How would fwd / bwd chaining - aka inferencing and goal-based reasoning - fit in DMN? ⇒ could be covered in an appendix on possible decision models / notations
Typo: complimentary standards ⇒ :)
Explain role of LOI after DMN Info Day to ensure max support from community
In general the requirements seem very open as to what’s required – are Decision Tables required even? 6.5.3 asks merely for: “at least one detailed visual notation provided for at least one particular decision model type”. 6.5.5 then says Decision Tables ‘should’ be included but unclear whether this is for the notation or just a classification. ⇒ Open requirements a design goal for contributors to have varied approaches - the RFP should not dictate or guide the response, except in the broadest way! But need to reword DTable requirement to be stronger
The level of integration required is very low. I would expect Decisions to refer to data in the models in which they’re embedded and this is a crucial aspect missing. ⇒ needs rewording to clarify that vocabulary sources should be referenced and therefore integrated at runtime (in modelling tools). Also clarify that the execution layer ie mapping to xUML / PRR / vendor varients of these is NOT part of the spec but open to vendor implementation. Probably add that there is little benefit in standardising these transforms if vendors already have their own languages eg DMN to Ilog IRL rather than via PRR…
I would like to see an architecture of how these standards are supposed to fit and the points of integration across a lifecycle. ⇒ needs coverage, agreed
Consider a FAQ appendix for some of these points on this page
Problem statement missing CSMA to edit