Currently there are (usually) subtle differences in the XMI files created by different design tools. If runtime engines are going to successfully read MDMI maps, then the standard has to specify a standard format for the XMI for a map
Discussion:
It is agreed that the XMI format of an MDMI map must be consistent. However there are ongoing activities both within OMG and ISO 20022 to more generally define a consistent XMI standard. The MDMI FTF would like to assess the potential of these other formats before defining an XMI format standard just for MDMI.

we beleive the MDMI 1.0 spec has only limited ability to support data translation in the presence of structure clashes bewtween source and target data structures. We suggest ways in which this could be tackled.

These are important for impact analysis and management purposes. The following should be drawn as associations and have opposite properties:

• SemanticElement::datatype

• DataRule::datatype

• MDMIBusinessElementReference::referenceDatatype

The property SemanticElement::datatype has no type itself in the metamodel or UML diagram. According to 8.3.4 (property 4) it should be MDMIDatatype so this is arguably an editorial change.

Likewise MDMIBusinessElementReference::referenceDatatype has the same problem (missing from the model but documented as Property 5 of 8.5.3.)

However it is a fundamental problem with use of the normative metamodel and should be fixed as an urgent issue.

Figures 8.1, 8.2, 8.4, 8.8 also need updating.

Oddly Figure 8.5 is OK (indicating that it is out of date with the metamodel so may be missing other changes. E.g. the property ToBusinessElement::description is missing its datatype of String).

Likewise 8.6 is OK in that respect but is out of date with respect to the metamodel: datatypes of int and bool are shown instead of Integer and Boolean correctly used in the metamodel

Since it is derived from fieldName presumably this means that on creation fieldName is always set to null! I don’t think this effect was intended, so /isSyntacticField should have isReadOnly=true and not have a default.

In the metamodel Choice::contraint is mis-spelled. It is correct in 8.2.6 but not Figures 8.1 and 8.8.

The description and use of MDMIBusinessElementRule is completely unclear. All we have, in 8.5.7 is “some business rules may have to be specified within a map to make sure that the mapping is correct”.

Section 8.5.3 states that a Dictionary is required to have a function that returns a unique id for any use of the ‘same’ business element. However it’s not clear what ‘same’ means here – and this is key to the whole MDMI process. It would help if the operation signature and semantics were to be specified in MOF as part of the metamodel.

Section 8.6.3 makes several references to ‘source’ and ‘target’ SemanticElements. However the metamodel does not use these terms – but ‘context’ (which I presume is ‘source’) and ‘relatedSemanticElement’ (which I presume is ‘target’). The descriptions of the properties sourceIsInstance and targetIsInstance are confusing, do not make sense, and in some cases are outright wrong (e.g. “the relatedSemanticElement owns the relationship by composition”). The scope when sourceInstance=’false’ is unclear – is it all instances of the semanticElement class in the message? The known universe?

It would make sense for the ‘defaultX’ properties of MessageGroup to be optional

Property SemanticElementSet::/mesageModelname should have isReadOnly= true

The standard allows user to specify five diffenet languages that define in what language certain properties are presented. The standard does not put any constraints on these choices. Clearly there are implicit constraints. They should be made explicit.
Resolution:
A section will be added to the report that provides constraints and an appropriate example for each language type that is in the MDMI specification. This section will be added to the description of the MessageGroup class as this is where default languages are specified for all messages in the group.

The first time a property is specified whose value is an expression language reference; a description of any constraints that language must meet will be inserted. Five language references are first mentioned as properties of MessageGroup. The OrderingLanguage property is first mentioned in the description of the SemanticElement class.

The FTF report does not contain a description of each class's associations. These should be added.

Resolution:
For every class in the MDMI metamodel, as described in the Beta 2 document, definitions of the associations for each class have been added as a subsection after the subsection describing the class's properties.

There are a number of references in the specification that need to be changed. For example, the specification still refers to the standard as CM4PM instead of MDMI. In addition, there will be some general editing that will be required, once the specific text associated with the suggested changes in the metamodel is made.Resolution:
A general editing pass will be made on the text of the specification once all the text changes associated with accepted resolved issues is made.

A general editing pass will be made on the text of the specification once all the text changes associated with accepted resolved issues is made.