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

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

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

Should changed text as above. Should change all instances of CM4PM to MDMI

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

Disposition: See issue 12734 for disposition

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.

The attributes propertyQualifier and datatypeQualifier will be removed from the ConversionRule abstract class

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.

These classes will be renamed "To Business element" and "To SemanticElement"

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 class MessageElementInstance will be removed from 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.

The UnqualifiedBusinessElement class is replaced with a class that references a Business Element in a dictionary. No assumption is made about the format of the Business Element in the central dictionary.

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 UnqualifiedBusinessElementInstance class will be removed from the specification

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.

While the specification does not deal with datatypes directly, some restrictions on complex datatype definition are necessary for syntactic modeling. In addition, there has to be some restrictions on complex datatypes to ensure that a runtime engine will do proper transformation utilizing the maps that are linked through a business element in the central dictionary. These restrictions include: 1) that the simple datatypes be from a known standard, such as the XML simple datatypes or the Java simple datatypes; 2) that every element in a complex has a named field for the simple datatypes it contains. Therefore, the datatype for the attribute "datatype" will be changed to a datatype of "MDMIDatatype".

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.

An MDMIBusinessElementRule class will be added that has a many-to-one association with the MDMIBusinessElementReference class

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.

To handle correctly SemanticElementRelationships, two changes will be introduced.
1. In the SemanticElement class, an association will be added to declare explicitly a parent/child relationship, as defined in a message format.
2. Second, in the SemanticElementRelationship class the Boolean attributes sourceIsInstance and targetIsInstance will be added. If the source SemanticElement has multiple instances then:
· when the sourceIsInstance is true, the defined relationship is for each Instance of the source SemanticElement
· when the sourceIsInstance is false, the defined relationship is for the SemanticElement class as a whole
· when the targetIsInstance is true, the defined relationship is for each Instance of the target SemanticElement
· when the targetIsInstance is false, the defined relationship is for the SemanticElement class as a whole
There are also two additional attributes that are there to help a runtime parse a message. These are minOccurs, which says how many instances of the target at a minimum must be involved in the relationship; and maxOccurs\, which says how many instances at most can be involved in the relationship.

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 attributes "position" and "positionLanguage" will be changed to "ordering" and "orderingLanguage" respectively. The description of the "ordering" attribute will be that it specifies the method of ordering for SemanticElements that have multiple instances.

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

An attribute "propertyQualifier will be added that will allow modifiers to be enumerated for the SemanticElement, such as a tag associated with the value in the original message format.

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.

MDMI will provide a clearer map if the association between a SemanticElement and a central dictionary's BusinessElements is isomorphic or represents well defined "near synonyms". This requires that transformations that are more complex are needed to prepare for that isomorphism be more explicitly included in the map. Towards that end, the new attribute "elementType" will be added to the SemanticElement class.
This attribute is defined by an enumeration that currently has three values each of which defines the type of Semantic Element.
· NORMAL - a "NORMAL" semantic element is equivalent to the current definition of a SemanticElement, i.e., a semantic element, contained in a message format, which is to be mapped to a central dictionary.
· LOCAL - a "LOCAL semantic element contains some technical information need that is needed to correctly map NORMAL semantic element, e.g., it may contain an index that is used to provide the ordering for a semantic element that has multiple instances.
· COMPUTED - a "COMPUTED" semantic element that is to be mapped to the central dictionary but contains a value that is not extracted from a message Instead, a "COMPUTED" semantic element's value is computed from the value of other SemanticElements in the message.
Three additional attributes are added to provide rules for computed values:
1. computedValue - An MDMIExpression that computes the value of the SemanticElement, which can refer to the value of other SemanticElements This attribute is most often used for SemanticElements of the type LOCAL.
2. computedInValue - an MDMIExpression that computes a value for a SemanticElement, when it is a target, based on the values of one or more BusinessElements and SemanticElements. The value when it is a source is directly mapped.
3. computedOutValue – an MDMIExpression that computes a value for a SemanticElement, when it is a source, based on the values of one or more SemanticElements. The value when it is a target is directly mapped.

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.

An "owner" association will be added to the MessageComposite class.

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.

The Choice and Set class separately inherit from the Node class.

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.

The multiplicity for the association will be changed from 2...* to 1...* and the default for the isUnique attribute will be changed to "True"

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.

A modeled MDMI complex datatype is composed of classes, where the classes themselves can be complex datatypes or a class with a single valued simple datatype. Ultimately, all complex datatypes resolve to a set of simple datatypes that correspond to fields (or subfields) in a message format. Therefore, to accommodate Semantic Elements that are complex datatypes, a "fieldname" attribute will be added to the Node abstract class, which holds the name of the simple datatype class. For computational efficiency, a derived Boolean attribute is also added that says this node contains a syntactic element that is part of a complex datatype.

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.

Two attributes are added to the abstract class Node, minOccurs and maxOccurs. If MinOccurs is zero, it indicates that this node is optional. If maxOccurs is greater than one, it indicates that the message format allows up to maxOccurs instances of this Node. The attribute "isOptional" is deleted, as it is now redundant.

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 MessageInstance class is removed from the specification.

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 MessagePackage class will be removed from the specification.

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.

The class name "Set" will be changed to "Bag". In addition, the default value for the attribute "isUnique" will be True, as a Bag most commonly will be a set, i.e., contain no duplicates.

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.

A global change in the MDMI metamodel and the specification document of the term MessageElement to SemanticElement has been made and the phrase or sub-phrase "Message Element" to "Semantic Element" has been made.

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.

For class definitions that did not have a "description" attribute, a "description" attribute was added. These include the following classes: MessageGroup, MessageSyntaxModel, MessageElementSet, Keyword, SimpleMessageComposite, MessageComosite, ConversionRule, MessageElementRelationship, SemanticElementIBusinessRule, and MDMIBusinessElementRule,

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.

Even though datatypes are not part of the standard, there are restrictions required for the form of datatypes, especially complex datatypes. Section 8.4 of the document will be revised to take into account these requirements. The specific change to the model will be to include a "datatype" attribute in the "DataRule" class with a multiplicity of [1...*] to provide explicit references to the datatypes used in the rule expression. This is necessary so that DataRules expressions can be properly parsed.
While the class specification for DataRule does not change much, a large amount of explanatory text is included in the Beta 2 document to properly resolve this issue. First, there is the addition of a URI "reference" property in the MDMIDatatype class. In addition, associations are removed from the MDMIDatatype class and the MDMIDatatype class is simply used to define the type of any "datatype" property in the model. This was necessary in order to define the type for DataRule's new property, "datatype".
Then a section is added that presents an example of a metamodel for a "complex datatype" so the need for the explicit "datatype" property is clearer, as it exposes the type of structure that a DataRule language would have to access.

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 MessageGroup class will add six attributes that define a default language that will hold for all for all classes in the message model unless locally over-ridden. MDMI does not choose any expression language, allowing the user to specify them. However, there required constraints for each of these languages. These constraints are outlined in the property description of each default language type.

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

see dtc/2009-09-17 for details

Description of the associations is missing

See issue 12720 for disposition

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

See issue 12737 for disposition

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.

See issue 12716 for disposition

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?

Discussion:
The conversion of a SemanticElement to an MDMIBusinessElementReference is strictly defined. These conversions are simple arithmetic or character expressions.
Disposition: Closed, no change

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

Disposition: See issue 12716 for disposition

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?

Changed text.

Current text
MessageModelName

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

Resolution:
Agree that this property was not needed and so the bullet was deleted.
Revised Text:
None.
Disposition: Resolved

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?

Discussion:
Description are purely informational.
Disposition: Closed, no change

Current text
MessageModelName
New text

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

Resolution:
Changed text.
Revised Text: (section 8.3.3 bullet 3.)
3. A "MessageModelName" property, whose value is constrained to be the same as the name property in the MessageModel that contains the SemanticElementSet. This derived property is included for implementation convenience.
.
Disposition: Resolved

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

Disposition: See issue 12737 for disposition

What is the value and relevance of these sections?

Changed text by adding description

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

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

Association between MessageComposite and MessageElement is missing

Resolution:
Fixed in diagram.
Revised Text:
Please see the annotated Beta 2 with markup.
Disposition: Resolved

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?

Discussion:
They are a vector of the same SemanticElement. The order attribute instructs on accessing elements in the vector.
Disposition: Closed, no change

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

Resolution:
Changed text, deleted the example, as it was incorrect.
Revised Text:
Please see the annotated Beta 2 with markup.
Disposition: Resolved

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

Discussion:
Author's prerogative
Disposition: Closed, no change

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?

Changed text

The meaning of the isUnique property is not clear.

Discussion:
It means the elements in the Bag
Disposition: Closed, no change

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)

Disposition: See issue 14148 for disposition

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

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

Value and relevance?

Changed text, explanation of value will be added.

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

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

Value and relevance?

Resolution:
Changed text, MessagePackage has been removed from the specification.
Revised Text:
Please see the annotated Beta 2 with markup.
Disposition: Resolved

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.

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

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

Changed all figures to be consistent with Beta 2 specification. Inconsistencies removed.

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

Discussion:
You have only one MessageModel per message format. Different purposes are handled because SemanticElements can only have one semantic meaning. Thus, one field in a message format can have numerous associated SemanticElements
Disposition: Closed, no change

Are these examples of Message Groups or Message Aggregates?

MessageGroups

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

Changed text to add a description of all classes, in many cases a better description of the attributes and a description of the "associations" associated with a class.

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

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

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

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

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

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

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)

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

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

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

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

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

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.

Changed text in section 7.1.2 to reflect the use of uniqueIdentifiers to perform mapping at runtime. Deleted old section 7.1.3 as it is not consistent with the uniqueIdentifier approach. Also deleted the redundant section 7.1.4 section on bilateral mapping and added some of that content to section 6.2.4 (old section 6.3.3)

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

MessageGroups have default expression languages and a set of DataRules that are associated with all the MessageModels in the group.Disposition: Closed, no change

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

No Data Available

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

No Data Available

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.

No Data Available

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

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

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.

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

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)

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)

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

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

No Data Available

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)

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

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.

Discussion:
There is more detail in section 6.4
Disposition: Closed, no change

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)

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

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

Resolution:
Changed text
Revised Text: The term direct mapping has been replaced with bilateral mapping.

Disposition: Resolved

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

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

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?

Changed text

change UNOIFI to UNIFI

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

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

Changed text

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

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

What does FRB mean?

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

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.

Changed text, added a new section 6.3.3 and moved the current 6.3.3 to 6.3.4

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)

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

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

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

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.

Changed text to reflect the new realities of ISO 20022 and to be more general about how the standard can be used.

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

Changed text to reflect the fact that MDMI has modified how it relates to Business Elements in a central dictionary such as the ISO 20022 Repository. The paragraph below is compatible with that revised relationship.

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

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

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

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

Current text
See section 4.4
This is a wrong reference!

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

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

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

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.

Resolution:
Added bullet
Revised Text:
Please see the annotated Beta 2 with markup.
Disposition: Resolved

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.

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

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

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

Please mention source and year for these estimates

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

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; …)

Discussion:
The document is consistent
Disposition: Closed, no change

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

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

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

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

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

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

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

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

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

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

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

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

What is the exact difference with "conversion rule"?

A conversion rule is an arithmetic expression. It is used in a semantic map
Disposition: Closed, no change

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.

No Data Available

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

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

Remove this term. It is used only in another definition

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

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

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

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

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

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

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

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.

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

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

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

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"?

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

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

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

Remove this term. It is used in another defenition

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

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

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

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

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