There are a bunch of spacing errors (6.4.1 has just one of these) in the document. Word’s grammar checker will find them.

Remove extra spaces

as above

In the XMI file there is a bunch of weird DataType with blank names that are not used.

Fix datatype issues

as above

OWL seems essential, but there is nothing mentioned about OWL until 8.5.3 and no other references.

Add OWL to glossary

Add OWL to glossary

as stated

Add comments to red-line document

as above

as above

Clarify graphics as able

Unable to change some graphics that are too big to fit a standard page legibly.

as above

Make corrections for loading into Cameo

as above but there is no access to Cameo

List of contributors incomplete

Add missing contributor name

Gargi Gajjar contributed to the Finalization Task Force. Her name was added to the list of contributors

The term Admit Data Time used in the example is not correct because Admit Date Time has more syntax than it just in the ADT A01 file.

Add the term "message" to further specify data use

Change " in a HL7 V2.8.2 ADT-A01 there is a field representing Admit Date/Time." to "in a HL7 V2.8.2 ADT-A01 message there is a segment that has is a field representing Admit Date/Time". The change specifies the structure of where a data item of Admit Date/Time would be located for those familiar with HL7 V2.8.2 message model.

The term SNOMED CT is used in the Annex C and it is not included in Annex A

Add the missing definition for SNOMED CT

The definition of the term was added. "The SNOMED CT is a systematically organized computer-processable collection of medical terms providing codes, terms, synonyms and definitions used in clinical documentation and reporting"

The term "MDMI Semantic Element" is incorrect because it represents a proper name and its class name, MDMISemanticElement, should be used.

Change "MDMI Semantic Element" to "MDMISemanticElement" (no spaces)

The term "MDMI Semantic Element" is the proper name of the class MDMISemanticElement in the specification and therefore the term has been changed throughout the document to MDMISemanticElement.

See attached document for specific locations.

The examples provided for the term datum were missing a key concept of time.

Reword sentence to clarify definition

The concept of time as a datum was missing. Change "an atomic datum, such as a name or measurement value" to "an atomic datum, such as a name, measurement, or temporal value"

The file went missing but was recovered. It appears that the recovery munged some of the text.

Reviewer comments:
Lots of elements are strangely duplicated, like Bag, SemanticElementSet, Node, SimpleMessageComposite, ToBusinessElement, MessageSyntaxModel, etc. As I recall, this was one of the files that was lost. I think the recovery was an implosive mix.

Corrected file obtained

File without corruption replaces the one there

The description of the Step 2 process in Annex C for developing the MDMI Healthcare Ontology is incorrect.

Remove ANF reference

ANF was not used as a Reference Model. All sentences after the first sentence in Step 2 were removed.

In the first line:
The goal of the MDMI standard is to provide a declarative, model-driven mechanism to perform message data...

The word "message" is in subscript.

Changed font type of word

"Message" changed from subscript to normal text

No attestation in section 3, Normative References

OWL is mentioned in the document but has no further reference

Added missing reference

Provided link to W3C site for OWL.

Text for the section is missing. It only contains an irrelevant caption.

Added missing diagram

Added diagram for MDMIDatatypes, DataRules - Abstract Syntax

Should this be identified as an RDF/OWL file?
I did find documentation in the RDF file, thank you! However, it might not be aligned with your specification. For example, hasAuthorPersonLegalName is in the RDF, but not in the specification or XMI.
Looking at the RDF itself, I find the following at the beginning that I have questions about:
                <!ENTITY dct "http://purl.org/dc/terms/">
                <!ENTITY mdmi-gsm "https://www.omg.org/spec/MDMI/MDMIGenericStatementModel/">
                <!ENTITY owl "http://www.w3.org/2002/07/owl#">
                <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">
                <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#">
                <!ENTITY skos "http://www.w3.org/2004/02/skos/core#">
                <!ENTITY sm "http://www.omg.org/techprocess/ab/SpecificationMetadata/">
                <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">
 
Questions:
1. Should these be in normative references in the spec?
2. What is the reason for the choices in these standards (annex?)?
3. Except for the minor reference to OWL, there is no other mention of RDF and these related standards. I’m assuming this is important information that is missing from the specification, given that this is a normative machine-readable file.

No changes necessary

Use of RDF is informative not normative

You are burring the lead in the specification scope. I suggest starting with the Scope section with the remainder of the second paragraph: “The goal of the MDMI standard is to provide a declarative, model-driven mechanism…” The remainder text can then follow as background. A better scope will help with adoption as you will be leading with what the spec is to do.

Clarify scope

Change to:

The goal of the MDMI standard is to provide a declarative, model-driven mechanism…

6.4.2 “360  View of diverse IT eco-system” seems like an odd choice for a paragraph title. There is no mention of 360 in the body. Perhaps this is better discussed as enterprise-level definitions and reuse.

Change title of the paragraph

as above

as above

Add normative references

for OWL and RDF

6.2.1.1 Please define ‘conceptsentities’ or fix the typo (missing comma).

Put a space between the words

as above

No references are made to the normative machine-readable,  no RDF/OWL hook to hang your propeller cap. OWL is not defined or discussed.

No changes necessary

Files are informative not normative

as above

No changes necessary

File is required by OMG process

The name, VitalSignObservationActionFocus, in Annex C is inaccurate and the graph description of the correct term is inaccurate.

Remove "Action" from "VitalSignObservationActionFocus" and "ActionFocus"

In the example in Annex C, change the term VitalSignObservationActionFocus to VitalSignObservationFocus. In addition, change the graph description of the DataElementConcept to Focus.

The expression "are synonyms" is incorrect. There are other possible conditions that may cause the condition besides the MDMIBusienssElements being synonyms.

Change statement from definitive to possible

An example of a different condition is that one MDMIBusinessElement has an incorrect specification of its StatementContext or DataElementContext. Proposed change is to change "are synonyms" to "could be synonyms".

In the standard, each MDMISemanticElement must be unique. Having "near-synonyms" with the same MDMISemantic Element violates this principle.

Remove the sentence

Deleting the sentence "In effect, they define the domain of “near-synonyms” that are allowed in a mapping." addresses this issues

There has already been introduced a term in the document for "semantic unit" and it should be used.

Clarify use of "semantic unit"

The term data item has been used previously. Change "to expedite the insertion or extraction of as little as one semantic unit data item of a message" to "to expedite the insertion or extraction of as little as one data item of a message"

With the additional functionality of providing a StatementContext and DataElementConcept to the MDMI Business Element Reference Class, the term registry does not sufficiently express the nature of the SEER.

Change "Registry" to "Repository

same

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