Issues for Conversion Model for Payment Messages Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 12624: change name of specification
Issue 12625: page numbering
Issue 12626: name of the standard is repeated in the document
Issue 12627: page 1 section 1 para 1
Issue 12628: page 1 section 1 para 2
Issue 12629: page 1 section 1 para 2 line 3 grammatical error
Issue 12630: page 1 section 1 para 2 line 3 clarification
Issue 12631: page 1 section 1 para 2 line 8 remove Payment Message (CM4PM) standard
Issue 12632: page 1 section 1 para 2 line 6 change to message data transformation
Issue 12633: page 1 section 1 para 2 line 10 clarification needed
Issue 12634: page 1 section 1 para 2 line 11 - remove name of standard
Issue 12635: page 1 section 2 para 1 line 2 - problem with cross-referencing
Issue 12637: page 1 section 2 para 1 line 5 - normative/non-normative sections
Issue 12638: page 1 section 3 - add reference to ISO 20022
Issue 12639: page 2 section 4 - "autonomy'
Issue 12640: page 2 section 4 - "business analyst"
Issue 12641: page 2 section 4 - "business element"
Issue 12642: page 2 section 4 - remove "business rule"
Issue 12643: page 2 section 4 composition
Issue 12644: page 2 section 4 conversion rule
Issue 12645: page 2 section 4 "domain"
Issue 12646: page 2 section 4 "domain data dictionary"
Issue 12647: page 2 section 4 "domain repository"
Issue 12648: page 3 section 4 "entity"
Issue 12649: page 3 section 4 "environment"
Issue 12650: page 3 section 4 "federated dictionary"
Issue 12651: page 3 section 4 "federate"
Issue 12652: page 3 section 4 "group"
Issue 12653: page 3 section 4 "keyword list"
Issue 12654: page 3 section 4 "leaf format"
Issue 12655: page 3 section 4 "leaf format expression language"
Issue 12656: page 3 section 4 "location"
Issue 12657: page 3 section 4 "location expression language"
Issue 12658: page 3 section 4 "leaf syntax translator"
Issue 12659: page 3 section 4 "message element"
Issue 12660: page 4 section 4 "message element relationship model"
Issue 12661: page 4 section 4 "message composite"
Issue 12662: page 4 section 4 "message format"
Issue 12663: page 4 section 4 "message group"
Issue 12664: page 4 section 4 "message model" and "message syntax model
Issue 12665: page 4 section 4 "message syntax translator
Issue 12666: page 4 section 4 para MSxx
Issue 12667: page 4 section 4 para MTxx
Issue 12668: page 4 section 4 "near synonym"
Issue 12669: page 4 section 4 "node id"
Issue 12670: page 5 section 4 "qualified business element"
Issue 12671: page 5 section 4 "runtime application"
Issue 12672: page 5 section 4 "semantic element"
Issue 12673: page 5 section 4 "semantic map"
Issue 12674: page 5 section 4 "simple message composite"
Issue 12675: page 4 section 4 para TCxx
Issue 12676: page 5 section 4 "technical analyst"
Issue 12677: page 5 section 4 "type"
Issue 12678: page 5 section 4 "UNIFI"
Issue 12679: page 6 section 4 "wire format"
Issue 12680: page 6 section 5.1
Issue 12681: page 11 section 6 para 1 "it is estimated.."
Issue 12682: page 11 section 6 para 3 first bullet
Issue 12683: page 11 section 6 para 3 second bullet
Issue 12684: page 11 section 6 para 3
Issue 12685: page 11 section 6 para 5
Issue 12686: page 11 section 6 para 5 line 3
Issue 12687: page 11 section 6.1 para 1
Issue 12688: page 11 section 6.1 para 1 - correction
Issue 12689: page 11 section 6.1 para 2
Issue 12690: page 11 sections 6.1 and 6.2
Issue 12691: Remove terms from Annex A
Issue 12692: page 12 section 6.3 title
Issue 12693: page 12 section 6.3
Issue 12694: page 12 section 6.3.1 paera 3 - typo
Issue 12695: page 12 section 6.3.1 para 3 1st bullet
Issue 12696: page 13 section 6.3.1 para 3 1st bullet
Issue 12697: page 13 section 6.3.2 para 1
Issue 12698: page 13 section 6.3.2 in general
Issue 12699: page 13 section 6.3.3 title
Issue 12700: page 13 section 6.4 title
Issue 12701: page 13 section 6.4 general comment
Issue 12702: page 13 section 6.4 para 1
Issue 12703: page 13 section 6.4 para 1 line 2
Issue 12704: typos
Issue 12705: page 13 section 6.4 para 2
Issue 12706: page 14 section 6.5 title
Issue 12707: page 14 section 6.5.1 title
Issue 12708: page 14 section 6.5.1 general comment
Issue 12709: page 14 section 6.5.1 para 1
Issue 12710: page 14 section 6.5.2 para 1
Issue 12711: page 14 section 6.5.2 para 1 line 6
Issue 12712: page 14 section 6.5.3 para 1 line 4
Issue 12713: page 5 section 7 - title
Issue 12714: page 5 section 7 - general comment
Issue 12715: page 5 section 7 para 1 line 4
Issue 12716: page 7 section 7.1.2 para 1 line 6
Issue 12717: page 7 section 7.1.5 general comment
Issue 12718: page 7 section 7.1.5 para 1 line 1
Issue 12719: page 7 section 7.1.5 para 1 line 3
Issue 12720: page 9 section 8 general comment
Issue 12721: page 9 section 8 general comment # 2
Issue 12722: page 9 section 8.1.1 examples
Issue 12723: page 10 section 8.1.3 1st bullet
Issue 12724: page 10 section 8.1.3 2nd bullet
Issue 12725: page 11 section 8.1.4 general comment
Issue 12726: page 11 section 8.1.5 general comment
Issue 12727: page 11 section 8.2.1 para 1 line 1
Issue 12728: page 11 section 8.2.1 para 1 line 3
Issue 12729: page 12 section 8.2.2 fig 8.2
Issue 12730: page 13 section 8.2.5 para 1 2nd bullet
Issue 12731: page 13 section 8.2.5 para 1 3rd bullet
Issue 12732: page 13 section 8.2.7 title
Issue 12733: page 14 section 8.3.1 para 1 line 3
Issue 12734: page 14 section 8.3.1 para 6
Issue 12735: page 14 section 8.3.1 para 6
Issue 12736: page 14 section 8.3.1 para 8
Issue 12737: page 15 section 8.3.2 figure 8.3
Issue 12738: page 15 section 8.3.3 para 1, 2nd bullet
Issue 12739: page 16 section 8.3.4 para 1, 3rd bullet
Issue 12740: page 16 section 8.3.4 para 1, 7th bullet
Issue 12741: page 16 section 8.3.6 and 8.3.7
Issue 12742: page 17 section 8.4.1 para 1
Issue 12743: page 17 section 8.4.1 para 1 line 6
Issue 12744: page 18 section 8.5.1 para 1 line 2
Issue 12745: page 19 section 8.5.2 fig 8.5
Issue 12746: page 19 section 8.5.3 para 1
Issue 12747: page 20 section 8.5.4
Issue 12748: page 21 section 8.6.3
Issue 14137: Description attributes in each class
Issue 14138: The term and class name "Message Element" may cause confusion
Issue 14139: Source reference for MessageModel
Issue 14140: Default language settings
Issue 14141: Explicit datatypes in datatype rule
Issue 14142: The MessagePackage class is misplaced
Issue 14144: The MessageInstance class is misplaced
Issue 14145: Handling a multiplicity greater than one for a Node class
Issue 14146: Handling purely syntactic fields
Issue 14147: Proper Class name is Bag
Issue 14148: One Node in a Bag
Issue 14149: Separating Choice and Set
Issue 14150: Explicit hierarchy for MessageComposites
Issue 14151: Complex transformation to the central dictionary
Issue 14152: MDMI DataTypes
Issue 14155: Property qualifiers for MessageElements
Issue 14156: Changing the "position" attribute
Issue 14157: Properly handling MessageElementRelationships
Issue 14158: Business Element rules
Issue 14159: MessageElement Instance is inappropriate
Issue 14160: UnqualifiedBusinessElementInstance class is inappropriate
Issue 14161: Reference to a hub Business Element
Issue 14162: Simplifying names of classes
Issue 14163: The property and datatype qualifier in the ConversionRule class are inappropriate
Issue 14167: General editing of the MDMI specification
Issue 14218: Description of associations
Issue 14219: Constraints on various language choices

Issue 12624: change name of specification (cm4pm-ftf)

Current text
Conversion Models for Payment Messages
New text
Model Driven Interoperability (in the Financial Industry)
Rationale
There should be a new name for this specification	   

There are problems with the page numbering (it jumps from page 6 to page 11 at the beginning of section 6 and from page 14 to page 5 at the beginning of section 7)	   

Rationale
There are multiple cases where the name of the standard is repeated in the document. The use of this name may lead to confusion (as it's not about payments) and should be avoided. The list of comments includes some concrete proposals to change the text but has not captured each and every occurrence.	   

Current text: back office security
New text: back office securities
Rationale correction of business meaning	   

Current text
information must be accurately moved from one message format to another. For example, data in FIX messages to data in SWIFT messages.
New text
information must be correctly interpreted and processed by each involved financial system at each step of the financial transaction. This implies - amongst other things - that information must be accurately moved from one system to the next. This may require moving information from one message format to another, e.g., from a FIX pre-trade message into a SWIFT settlement message.
Rationale
clarification 	   

Current text: their
New text: its
Rationale: grammatical error	

Current text
must also be appropriately mapped to the industry standard
New text
must also be appropriately mapped to and from the industry standard
Rationale
this needs to work in both directions	   

Current text
The goal of the Conversion Models for Payment Message (CM4PM) standard
New text
The goal of the current standard
Rationale
use of name may lead to confusion (as it's not about payments)	

Current text
message transformation
New text
message data transformation
Rationale
it's about changing information of the message (and not necessarily the entire message)	

Current text
but also to create a versioning mechanism so that new version of a message can be mapped to older version
New text
but also to support versioning by providing a mechanism to map information between a new and an older version of the same message
Rationale
clarification

Current text
Thus, the Conversion Models for Payment Message standard
New text
Thus, the current standard
Rationale
use of name may lead to confusion (as it's not about payments)	

Current text
that are shown in figures 1 and 2 of the specification (“overview of proposed runtime specification”)
New text
that are shown in figures 7.1 and 7.2 of the specification (see section 7.1 Informal overview of artifacts)
Rationale
problem with cross-referencing

Current text
The runtime aspects of the implementation form the normative part of this specification.
New text

Rationale
According to the specification the models are the normative part (i.e. section 8) and this sections is not about the runtime.	   

page 1 section 3 - add reference to ISO 20022

remove the term "autonomy" It's used only in another definition

remove the term business analyst. It's not used in this document

Current text
A Business Element is a refinement of a Semantic Element that represents a business concept. A Business Element is associated with a Domain Data Dictionary.
New text
Representation of a business concept, as defined in an ISO 20022 data dictionary.
Rationale
Make it less dependent of other definitions

page 2 section 4 - remove the term "business rule". Rationale
Not a term but part of model and therefore explained in section 8.

Current text
A configuration of related entities that result in
New text
A configuration of related entities that results in
Rationale
grammatical error	   

Current text
A feature of a semantic map that describes a rule that is to be applied to a conversion between a value in a source message element and a value in a target business element or target message element.
New text
A rule that is to be applied to convert a value of a source message element into a value of a target business element or target message element.
Rationale
Make it less dependent of other definitions	   

Remove this term. it is not used on its own as a term (only in combination with other words)	   

Remove this term. it is only used in another definition

Remove the term. It is not used in the document

Remove the term. It is used as a normal English word in the document

Remove this term. It is not used in the document

Current text
A federated dictionary is a collection of multiple domains that shares definitions while retaining autonomy over the resources.
New text
A collection of physical Data Dictionaries, whereby each data dictionary contains Business and Message Elements that are relevant to a particular domain of the financial industry and whereby the collection of all Business and Message Elements represents a single logical data dictionary for the financial industry.
Rationale
clarification 	   

Remove this term. It is not used in this document

Remove this term. It is used as normal English in the document

Remove term
It is not a term but part of model and therefore explained in section 8.	   

Remove this term

It is only used in another definition	   

Remove this term. It is not used in this document

Remove term

Either used as a normal English word or as part of model and therefore explained in section 8.	   

Remove this term. It is not used in this document

Remove this term. It is not used in this document

Current text
A Message Element is a refinement of a Semantic Element that represents a smallest semantic concept in a message format
New text
Representation of the smallest semantic concept in a message format
Rationale
clarification 	   

Remove this term. It is used in another defenition

Remove this term. It is not a term but part of model and therefore explained in section 8.

Current text
A message format defines the syntax and semantics of a class of messages. Can be defined in many ways including paper documentation
New text
Definition of the syntax and semantics of a message. Can be defined in many ways including paper documentation
Rationale
Why would it need to be a "class of messages"?	   

Remove this term
Rationale
Either used as a normal English word or as part of model and therefore explained in section 8.	   

Remove these terms. They are not  terms but part of model and therefore explained in section 8.

Remove this term. It is only used once in the whole document. It can be explained when it is used

Current text
MSxx
SWIFT message sets that utilize a standard XML format based on ISO 20022
New text
MXxx
Message format developed according to the ISO 20022 specification.
Rationale
It's MX instead of MS and MX refers to all ISO 20022 messages (not only SWIFT)
NOTE: term needs to be moved at the correct alphabetical position.	   

Current text
MTxx
SWIFT message sets that are based on SWIFT defined EDI formats including the 15022 messages.
New text
MTxx
Message format developed according to the SWIFT EDI specification, including the ISO 15022 messages.
Rationale
consistency & correctness	   

Current text
Near Synonym
A Semantic Element that can be mapped using prescribed mapping rules to a set of other Semantic Elements
New text
Near Synonym
A Semantic Element that can be derived using prescribed mapping rules from a set of other Semantic Elements
Rationale
clarification 	   

Remove this term. Rationale
Not a term but part of model and therefore explained in section 8.

Remove this term. It is used only in another definition

Remove term
Rationale
Used as a normal English word in the document.	   

Current text
An object that represents a concept whose properties are datatype and value. It may also have optional properties that include a description and a Keyword List.
New text
An object that represents a concept whose properties are datatype and value. It may also have optional properties that include a description and a list of keywords.
Rationale
Keyword List is proposed to be no longer defined as term.	   

What is the exact difference with "conversion rule"?	

Remove term
Rationale
Not a term but part of model and therefore explained in section 8.	   

Current text
TCxx
The set of Visa message formats for retail banking transactions.
New text
TCxx
Message format developed according to the VISA EDI specification for retail banking applications.
Rationale
consistency & correctness	   

Remove this term. It's not used in the document

Remove this term. Either used as a normal English word or as part of model and therefore explained in section 8.	

Current text
UNIFI
The name associated with the ISO 20022 message sets associated with the financial service domain
New text
UNIFI
Synonym of ISO 20022, the ISO standard for universal financial industry message schemes
Rationale
correction

Remove this term. It's not used in the document

Shouldn't there be more consistency in the way companies and individuals are mentioned (e.g. either mention all co-authors with their companies or only all companies; mention companies for all individuals or none; …)	   

Please mention source and year for these estimates	   

Current text
Reduce significantly the cost and time needed to map data from one message format to another
New text
Reduce significantly the cost and time needed to define conversion rules to map data from one message format to another
Rationale
Original wording may give the impression that it is about runtime	   

Current text
Handle versioning issues as message standards change

Rationale
Does this refer to the fact that a new version can be linked to an old version through a map? If so, it can either be part of the next bullet or it needs to be described more clearly.	   

New text
Improve the interoperability and STP in end to end financial transactions that are based on multiple message formats.
Rationale
This is an additional benefit that is independent of a move to new standards.	   

Current text
message elements or business element, respectively
New text
message elements or business elements, respectively
Rationale
grammatical error	   

Current text
See section 4.4 
This is a wrong reference!	   

Current text
on the semantic content of the business elements in and
New text
on the semantic content of the business elements in the data dictionary and
Rationale
Missing words

Current text
in the ISO 20022 standard under the rubric “UNIversal Financial Industry message scheme” or UNIFI.
New text
in part 2 of the ISO 20022 standard.
Rationale
correction	

Rationale
The assumption that the data dictionary framework in ISO 20022 will be redesigned is premature. It would probably be better to describe this as a pre-condition to the success of CM4PM (or indicate that failure to do so in ISO 20022 will lead to the need for an additional data dictionary) . 	   

Rationale
Sections 6.1 and 6.2 contain some repetitive and non-confirmed information (regarding the evolution of the dictionary). There is also some information that is not directly relevant to CM4PM as such (the way the dictionary will be populated).  I suggest to have these sections re-written into a single new (condensed) section.	   

Remove the following terms since they are not used in the document: Chips, CLS, FATF, GIovannini, MiFID,Omgeo, RTGS, RIXML, Sepa, Target2, XBRL

Current text
Use of the Conversion Models for Payment Message Standards
New text
Different ways to use the current standard
Rationale
use of name may lead to confusion (as it's not about payments)	   

Rationale
There is a fourth - extremely important - use case that should be described, namely moving data to and from internal data representations with the enormous benefit that the financial institutions only have to understand the dictionary as the conversion from message to dictionary is done by the standards bodies.	   

change UNOIFI to UNIFI

Current text
Only a linear set of transformation must be created among a different message format groups.

Rationale
Something wrong with this sentence; meaning not clear?	   

What does FRB mean?

Current text
By providing CM4PM maps of new versions older versions
New text
By providing CM4PM maps of new versions to/from older versions
Rationale
Missing words	

I suggest to mention that this approach has the (obvious) limitation that new information will not be exploited.	   

The document uses the terms "direct mapping" and "bilateral mapping". Only a single term should be kept.	   

Current text
Basic approach of the Conversion Models for Payment Message Standards
New text
Basic approach for the use of this standard
Rationale
use of name may lead to confusion (as it's not about payments)	

Section 6.4 is to a large extent a repetition of the introductory part of section 6 (e.g. the description of the two stages). I propose to rationalise this by either removing it from the introduction or by combining the introduction and section 6.4.	   

Current text
the artifacts defined for the Conversion Models for Payment Message standards
New text
the artifacts defined for this standard
Rationale
use of name may lead to confusion (as it's not about payments)	   

Current text
conversions as a mapping data
New text
conversions as mapping data
Rationale
grammatical error	

page 13 section 6.4 para 1 line 5 change "additional meta on-data" to "additional meta-data
page 23 section 8.8.3 para 1 line 1 change "The MessageElement has two properties" to The MessageInstance has two properties

	     

Resolution:
Changed text
Revised Text:
Please see the annotated Beta 2 with markup.
Disposition:	Resolved

Current text
The Conversion Models for Payment Message standards is a declarative standard
New text
The standard is a declarative standard
Rationale
use of name may lead to confusion (as it's not about payments)

Current text
Future of the Conversion Models for Payment Message Standard
New text
Future benefits of the standard
Rationale
use of name may lead to confusion (as it's not about payments)	

Current text
Use of Semantic Mapping for Structuring
New text
Dealing with (near) synonyms
Rationale
Current title does not describe well the content of this section.	   

The concept of semantic proximity and how the conversion rules can help to deal with this needs to be explained in a more concrete way in order to be understood (examples may help).
The first part of the paragraph (until "The same mechanism …" doesn't seem necessary / useful.	   

Current text
is the semantic mapping is that it is carried out
New text
is the semantic mapping that is carried out
Rationale
grammatical error	   

Current text
for specific subsection of the financial services industry
New text
for specific subsections of the financial services industry
Rationale
grammatical error	

Current text
A federated set of dictionaries will be more effective to maintain.
New text
A federated set of dictionaries might be more effective to maintain.
Rationale
This needs some further evaluation (as there are maybe other problems that arise with a federated dictionary).	   

Current text
auxiliary storage for lost information can created with
New text
auxiliary storage for lost information can be created with
Rationale
grammatical error	

The link between the title and the content of this section is not clear.	   

This chapter contains again a lot of repetition with parts from section 6. Wouldn't it be better to combine chapters 6 and 7 and make sure that all relevant information is mentioned exactly once and at the right level of detail.	   

Current text
The standard can be used to convert data within a Message Group or across Message Groups.


Rationale
What is the value or relevance of having "Message Groups" (this is not clear at this stage and does not become more clear after having read the full specification).	   

Current text
in ISO 20022v2 compliant data dictionaries
New text
SEE QUESTIONS & COMMENTS IN NEXT COLUMN
Rationale
ISO 20022 v2 does not exist (and there is no guarantee that it will)	   

What is the value or relevance of having "Message Aggregates (this is not clear at this stage and does not become more clear after having read the full specification).	   

Current text
comprise a MessageModel, which is complete
New text
comprise a MessageModel, which is a complete
Rationale
grammatical error	   

Current text
A MessageGroup follow the natural grouping
New text
A MessageGroup follows the natural grouping
Rationale
grammatical error	   

What is missing in this chapter is a systematic explanation of what the different classes, attributes, associations…. Are needed for. In other words: what is their role with respect to the CM4PM standard; why are they necessary; what kind of information will they contain; how will that information be used; ...	   

Why do some views have a name (e.g. CM4PMS_MES in fig 8.3) and others not (e.g. fig 8.1 and 8.2)?	   

Are these examples of Message Groups or Message Aggregates?	

Current text
The messageModelName property is a string that is usually similar to the name of the message format it is modeling.
New text
SEE QUESTIONS & COMMENTS IN NEXT COLUMN
Rationale
How does this work with messages that are multi-functional and where you may need to have a separate model for each function it supports? (e.g. because the meaning of the fields is different for each function).	   

Current text
Together the MessageModel’s composed MessageSyntaxModel and the MessageElementSet uniquely define a message format.

Rationale
What's the difference between a Message Model and a message format? If none, we should not use both.	   

Value and relevance?	   

Value and relevance?	   

Current text
The MessageSyntaxModel and related classes provides
New text
The MessageSyntaxModel and related classes provide
Rationale
grammatical error	   

Current text
semantic unit
New text
semantic element
Rationale
consistency in terminology	

Is there no need to indicate whether a Node is repetitive (a Leaf can be repetitive and this cannot be indicated through a Set as you need at least 2 Nodes for a Set)	   

The meaning of the isUnique property is not clear.	

How do you describe the actual order of the nodes? Is this done with the location? If so, why do you need the isOrdered property?	   

Current text
LeafSyntaxTranslator
New text
SEE QUESTIONS & COMMENTS IN NEXT COLUMN
Rationale
Why is this called a "LeafSyntaxTranslator" and not simply "Leaf"?	   

Current text
because all the semantic units
New text
because all the semantic elements
Rationale
consistency in terminology

Why would the parts of the address be considered as separate semantic elements? Can't we consider address as a data type? 	   

Why would the parts of the address be considered as separate semantic elements? Can't we consider address as a data type? 	   

The used example is not very clear: shouldn't these multiple instances be treated as different semantic elements? If there is no semantic difference how can you ever know where to put/get which information?	   

Association between MessageComposite and MessageElement is missing

Current text
MessageModelName
New text

Rationale
Why is this property needed as the MessageElementSet is anyway contained in the MessageModel?	   

Current text
optional "description"


Rationale
Why is the description optional? Isn't that the basis that will make it possible to link the MessageElement to the correct BusinessElement?	   

Current text
MessageModelName

Rationale
Why is this property needed as the MessageElement is part of the MessageElementSet which is  contained in the MessageModel?	   

What is the value and relevance of these sections?

Current text
A set of the rules will apply to each MessageElement, that set is defined by the in the class
New text

Rationale
Missing words	   

Current text
DataRules are used on extraction for validation, to make sure that the value in a message instance is correct.


Rationale
Does that mean that the message that is received is not pre-supposed to be correct?	   

Current text
an ISO 20022v2-compatible industry repository, for example UNIFI v2.

Rationale
The specification cannot refer to something that does not exist (namely v2 of ISO 20022).	   

According to the model a message element could convert to multiple unqualified business elements. This means that the same thing in a message can mean different things. Is this supposed to be possible?	   

Current text
The UnqualifiedBusinessElement is defined in the framing document for ISO 20022. The CM4PM standard will link to any ISO2022 compliant data dictionary. UnqualifiedBusinessElements must conform to their definition in that standard.

Rationale
The specification cannot refer to something that does not exist (namely v2 of ISO 20022): the current ISO 20022 does not contain unqualified business elements yet.	   

More explanation is required about how the qualifiers need to be used.	   

Description of the associations is missing	   

For better documentation, there is no reason why there should not be a description attribute for each class but this must be integrated into any table or spreadsheet UI.

The MDMI specification identifies the semantic unit in a message to be a Message MessageElement and MessageElementSet.  The term Message Element and associated class names may be confused with the term Message Element in The ISO 20022 specification for those using the specification for financial service mapping.  Since the central hub dictionary used in these mappings will most likely be the ISO 20022 data dictionary.

There should be an optional reference to the definition of the message format whose elements are being mapped.  This reference might be to a formal model such as the location of the message definition in the ISO 20022 repository or it might be a paper document

MDMI currently forces the user to enter a language reference every time one writes any one of the four types of expressions.  The modeler should able to enter a set of default types that would hold unless overwritten by a local attribute value.

The DataRule rules are dealing with datatypes.  It will be difficult to find a rule language and complex to write rules unless the structures of the datatypes (especially complex datatypes) in the rule are explicit and discoverable.

The MessagePackage class is an aggregation of messages that are physically stored in a single Package.  These packages may be different then the MessageGroup.  However, the MDMI specification is a Platform Independent Model (PIM) and this class really relates to a platform dependent characteristic so it should not be included in the specification.

The MessageInstance class is contains a URI to a physical address of an actual instance of a message for which maps are to be applied.  However, the MDMI specification is a Platform Independent Model (PIM) and this class really relates to a platform dependent runtime characteristic so it should not be included in the specification.

The Node class is the core abstract class of a Message Syntax Model.  The current specification only allows a multiplicity of one for these classes.  Given the fact that syntactic groups, especially complex datatypes can be repeated, mapping will be simplified if the Node class is redefined to take care of a multiplicity greater then one.

The current specification does not adequately deal with Semantic Elements that are represented by a multi-field, complex datatype.  While the current specification, in theory, could be used to provide a complete MessageSyntaxModel, the location and format languages would have to be unduly complex and non-standard.  The MDMI specification should be enriched so that the components of a complex datatype, which are, by definition, purely syntactic, can be mapped.

The name of the Set class is formally incorrect.  It contains an attribute that implies that the elements in the "set" may not be unique.  Elements in a set must be unique.  The proper term would be Bag.

There need to be an allowance for the degenerate case where as Bag may only have one Node.  In addition, the default value for the attribute "isUnique" should be True, as a Bag will most commonly be a set, i.e., contain no duplicates.

Having a Choice class inherit from a Set class seems unnecessarily complex.  In addition, a Choice class should involve at least two Nodes whereas a Set could degenerate into having just one Node.

Message Composites form a tree structure.  The MDMI specification would make that structure clearer to discern if the parent of a MessageComposite was included as an attribute.

The current specification can require very complex incoming and outgoing conversions between a MessageElement and a dictionary's Business Element.  The ConversionRule rule language will have to be complex and non-standard.  In addition, important information for an implementation would be buried in those rules as opposed to that information being declarative and accessible.

While a definition of datatypes is not in the specification directly, the structure of a datatype must be known to a runtime implementation so that it can execute the proper transformation.  This is especially true since MessageElements can have very complex datatypes.  Therefore, the specification has at least to have an explicit reference to a declarative structure that describes the MessageElement's datatype.

It would be useful an attribute of the MessageElement contained information that explicitly identified the MessageElement with the message format in which it resides.

The attribute "position" was meant to describe the cardinal position of a repeated MessageElement class (i.e., the "multipleInstance" attribute has a value of "True").  Obtaining such a value may be difficult.  It would be better if the attribute simply described a more general ordering description in which a cardinal position could be an option.

The current MessageElementRelationship class does not seem to handle message relationships properly, especially given the potential for a MessageElement to have multiple instances, i.e., how does one distinguish between relationships to an instance and relationships to a class.

Given that the MDMI standard does not provide a specification for a the hub dictionary and in effect allows mapping to any appropriate dictionary, such as the ISO 20022 Data Dictionary, then some business rules may have to be specified to make sure that the mapping is correct.

The MessageElementInstance class contains the value of a MessageElement.  However, the MDMI specification is a Platform Independent Model (PIM) and this class really relates to a platform dependent runtime characteristic so it should not be included in the specification.

The UnqualifiedBusinessElementInstance class contains a place where a value in the central dictionary could be placed.  However, the MDMI specification is a Platform Independent Model (PIM) and this class really relates to a platform dependent runtime characteristic so it should not be included in the specification.

The current specification is in adequate in indicating the hub Business Element to which a MessageElement is to be mapped.  The actual Business Element cannot be in an MDMI map since the structure of those Business Elements are already defined, given that the MDMI map is tied to an existing hub dictionary.

Simplifying the name of the MessageElementoUnqualifiedBusinessElement class and the name of the UnqualifiedBusinessElementtoMessageElement classes

The actual proper name of a dictionary BusinessElement is not likely to be an "UnqualifiedBusinessElement" so the name should be simplified.

The attributes, propertyQualifier and dataTypeQualifier, refer specifically to dictionary terms in a UN/CEFACT dictionary and are meant to say these terms are all that are legal in a conversion.  The specificity and use of these attributes is muddled.  They should be removed.

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.

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

Descriptions will be added
Revised Text:
Please see the final Beta 2 with markup.

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.