Model Driven Message Interoperability Avatar
  1. OMG Specification

Model Driven Message Interoperability — All Issues

  • Acronym: MDMI
  • Issues Count: 148
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
MDMI_-165 page 1 section 1 para 2 line 3 grammatical error MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-164 change name of specification MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-166 page 14 section 8.3.1 para 6 MDMI 1.0b1 MDMI 1.0b2 Duplicate or Merged closed
MDMI_-163 The property and datatype qualifier in the ConversionRule class are inappropriate MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-162 Simplifying names of classes MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-159 MessageElement Instance is inappropriate MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-161 Reference to a hub Business Element MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-160 UnqualifiedBusinessElementInstance class is inappropriate MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-154 MDMI DataTypes MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-158 Business Element rules MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-157 Properly handling MessageElementRelationships MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-156 Changing the "position" attribute MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-155 Property qualifiers for MessageElements MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-153 Complex transformation to the central dictionary MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-152 Explicit hierarchy for MessageComposites MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-151 Separating Choice and Set MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-150 One Node in a Bag MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-148 Handling purely syntactic fields MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-147 Handling a multiplicity greater than one for a Node class MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-146 The MessageInstance class is misplaced MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-145 The MessagePackage class is misplaced MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-149 Proper Class name is Bag MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-141 The term and class name "Message Element" may cause confusion MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-140 Description attributes in each class MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-144 Explicit datatypes in datatype rule MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-143 Default language settings MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-142 Source reference for MessageModel MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-139 page 21 section 8.6.3 MDMI 1.0b1 MDMI 1.0b2 Duplicate or Merged closed
MDMI_-138 page 20 section 8.5.4 MDMI 1.0b1 MDMI 1.0b2 Duplicate or Merged closed
MDMI_-137 page 19 section 8.5.3 para 1 MDMI 1.0b1 MDMI 1.0b2 Duplicate or Merged closed
MDMI_-136 page 19 section 8.5.2 fig 8.5 MDMI 1.0b1 MDMI 1.0b2 Closed; No Change closed
MDMI_-135 page 18 section 8.5.1 para 1 line 2 MDMI 1.0b1 MDMI 1.0b2 Duplicate or Merged closed
MDMI_-134 page 17 section 8.4.1 para 1 line 6 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-131 page 16 section 8.3.4 para 1, 7th bullet MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-130 page 16 section 8.3.4 para 1, 3rd bullet MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-129 page 15 section 8.3.3 para 1, 2nd bullet MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-133 page 17 section 8.4.1 para 1 MDMI 1.0b1 MDMI 1.0b2 Duplicate or Merged closed
MDMI_-132 page 16 section 8.3.6 and 8.3.7 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-125 page 14 section 8.3.1 para 1 line 3 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-128 page 15 section 8.3.2 figure 8.3 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-127 page 14 section 8.3.1 para 8 MDMI 1.0b1 MDMI 1.0b2 Closed; No Change closed
MDMI_-126 page 14 section 8.3.1 para 6 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-124 page 13 section 8.2.7 title MDMI 1.0b1 MDMI 1.0b2 Closed; No Change closed
MDMI_-123 page 13 section 8.2.5 para 1 3rd bullet MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-122 page 13 section 8.2.5 para 1 2nd bullet MDMI 1.0b1 MDMI 1.0b2 Closed; No Change closed
MDMI_-121 page 12 section 8.2.2 fig 8.2 MDMI 1.0b1 MDMI 1.0b2 Duplicate or Merged closed
MDMI_-120 page 11 section 8.2.1 para 1 line 3 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-117 page 11 section 8.1.4 general comment MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-119 page 11 section 8.2.1 para 1 line 1 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-118 page 11 section 8.1.5 general comment MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-116 page 10 section 8.1.3 2nd bullet MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-113 page 9 section 8 general comment # 2 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-115 page 10 section 8.1.3 1st bullet MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-114 page 9 section 8.1.1 examples MDMI 1.0b1 MDMI 1.0b2 Closed; No Change closed
MDMI_-112 page 9 section 8 general comment MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-111 page 7 section 7.1.5 para 1 line 3 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-110 page 7 section 7.1.5 para 1 line 1 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-109 page 7 section 7.1.5 general comment MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-108 page 7 section 7.1.2 para 1 line 6 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-104 page 14 section 6.5.3 para 1 line 4 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-103 page 14 section 6.5.2 para 1 line 6 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-106 page 5 section 7 - general comment MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-107 page 5 section 7 para 1 line 4 MDMI 1.0b1 MDMI 1.0b2 Closed; No Change closed
MDMI_-105 page 5 section 7 - title MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-101 page 14 section 6.5.1 para 1 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-100 page 14 section 6.5.1 general comment MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-102 page 14 section 6.5.2 para 1 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-99 page 14 section 6.5.1 title MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-98 page 14 section 6.5 title MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-97 page 13 section 6.4 para 2 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-96 typos MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-94 page 13 section 6.4 para 1 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-93 page 13 section 6.4 general comment MDMI 1.0b1 MDMI 1.0b2 Closed; No Change closed
MDMI_-92 page 13 section 6.4 title MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-91 page 13 section 6.3.3 title MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-95 page 13 section 6.4 para 1 line 2 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-87 page 12 section 6.3.1 para 3 1st bullet MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-86 page 12 section 6.3.1 paera 3 - typo MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-90 page 13 section 6.3.2 in general MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-89 page 13 section 6.3.2 para 1 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-88 page 13 section 6.3.1 para 3 1st bullet MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-85 page 12 section 6.3 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-84 page 12 section 6.3 title MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-83 Remove terms from Annex A MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-82 page 11 sections 6.1 and 6.2 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-81 page 11 section 6.1 para 2 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-80 page 11 section 6.1 para 1 - correction MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-79 page 11 section 6.1 para 1 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-78 page 11 section 6 para 5 line 3 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-77 page 11 section 6 para 5 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-76 page 11 section 6 para 3 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-75 page 11 section 6 para 3 second bullet MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-74 page 11 section 6 para 3 first bullet MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-73 page 11 section 6 para 1 "it is estimated.." MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-72 page 6 section 5.1 MDMI 1.0b1 MDMI 1.0b2 Closed; No Change closed
MDMI_-71 page 6 section 4 "wire format" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-70 page 5 section 4 "UNIFI" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-66 page 5 section 4 "simple message composite" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-69 page 5 section 4 "type" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-68 page 5 section 4 "technical analyst" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-67 page 4 section 4 para TCxx MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-65 page 5 section 4 "semantic map" MDMI 1.0b1 MDMI 1.0b2 Closed; No Change closed
MDMI_-64 page 5 section 4 "semantic element" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-63 page 5 section 4 "runtime application" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-62 page 5 section 4 "qualified business element" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-61 page 4 section 4 "node id" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-60 page 4 section 4 "near synonym" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-59 page 4 section 4 para MTxx MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-58 page 4 section 4 para MSxx MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-57 page 4 section 4 "message syntax translator MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-54 page 4 section 4 "message format" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-53 page 4 section 4 "message composite" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-52 page 4 section 4 "message element relationship model" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-56 page 4 section 4 "message model" and "message syntax model MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-55 page 4 section 4 "message group" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-51 page 3 section 4 "message element" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-50 page 3 section 4 "leaf syntax translator" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-49 page 3 section 4 "location expression language" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-48 page 3 section 4 "location" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-47 page 3 section 4 "leaf format expression language" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-46 page 3 section 4 "leaf format" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-45 page 3 section 4 "keyword list" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-44 page 3 section 4 "group" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-43 page 3 section 4 "federate" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-42 page 3 section 4 "federated dictionary" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-41 page 3 section 4 "environment" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-40 page 3 section 4 "entity" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-39 page 2 section 4 "domain repository" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-38 page 2 section 4 "domain data dictionary" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-37 page 2 section 4 "domain" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-34 page 2 section 4 - remove "business rule" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-33 page 2 section 4 - "business element" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-32 page 2 section 4 - "business analyst" MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-36 page 2 section 4 conversion rule MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-35 page 2 section 4 composition MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-31 page 2 section 4 - "autonomy' MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-30 page 1 section 3 - add reference to ISO 20022 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-29 page 1 section 2 para 1 line 5 - normative/non-normative sections MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-28 page 1 section 2 para 1 line 2 - problem with cross-referencing MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-27 page 1 section 1 para 2 line 11 - remove name of standard MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-24 page 1 section 1 para 2 line 8 remove Payment Message (CM4PM) standard MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-23 page 1 section 1 para 2 line 3 clarification MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-22 page 1 section 1 para 2 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-26 page 1 section 1 para 2 line 10 clarification needed MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-25 page 1 section 1 para 2 line 6 change to message data transformation MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-21 page 1 section 1 para 1 MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-20 name of the standard is repeated in the document MDMI 1.0b1 MDMI 1.0b2 Resolved closed
MDMI_-19 page numbering MDMI 1.0b1 MDMI 1.0b2 Resolved closed

Issues Descriptions

page 1 section 1 para 2 line 3 grammatical error

  • Key: MDMI_-165
  • Legacy Issue Number: 12629
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 05:00 GMT

change name of specification

  • Key: MDMI_-164
  • Legacy Issue Number: 12624
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 05:00 GMT

page 14 section 8.3.1 para 6

  • Key: MDMI_-166
  • Legacy Issue Number: 12735
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Duplicate or Merged — MDMI 1.0b2
  • Disposition Summary:

    Disposition: See issue 12734 for disposition

  • Updated: Sat, 7 Mar 2015 05:00 GMT

The property and datatype qualifier in the ConversionRule class are inappropriate

  • Key: MDMI_-163
  • Legacy Issue Number: 14163
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Simplifying names of classes

  • Key: MDMI_-162
  • Legacy Issue Number: 14162
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:58 GMT

MessageElement Instance is inappropriate

  • Key: MDMI_-159
  • Legacy Issue Number: 14159
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    The class MessageElementInstance will be removed from the specification.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Reference to a hub Business Element

  • Key: MDMI_-161
  • Legacy Issue Number: 14161
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

UnqualifiedBusinessElementInstance class is inappropriate

  • Key: MDMI_-160
  • Legacy Issue Number: 14160
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    The UnqualifiedBusinessElementInstance class will be removed from the specification

  • Updated: Sat, 7 Mar 2015 04:58 GMT

MDMI DataTypes

  • Key: MDMI_-154
  • Legacy Issue Number: 14152
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Business Element rules

  • Key: MDMI_-158
  • Legacy Issue Number: 14158
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Properly handling MessageElementRelationships

  • Key: MDMI_-157
  • Legacy Issue Number: 14157
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Changing the "position" attribute

  • Key: MDMI_-156
  • Legacy Issue Number: 14156
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Property qualifiers for MessageElements

  • Key: MDMI_-155
  • Legacy Issue Number: 14155
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Complex transformation to the central dictionary

  • Key: MDMI_-153
  • Legacy Issue Number: 14151
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Explicit hierarchy for MessageComposites

  • Key: MDMI_-152
  • Legacy Issue Number: 14150
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Separating Choice and Set

  • Key: MDMI_-151
  • Legacy Issue Number: 14149
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:58 GMT

One Node in a Bag

  • Key: MDMI_-150
  • Legacy Issue Number: 14148
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Handling purely syntactic fields

  • Key: MDMI_-148
  • Legacy Issue Number: 14146
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Handling a multiplicity greater than one for a Node class

  • Key: MDMI_-147
  • Legacy Issue Number: 14145
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

The MessageInstance class is misplaced

  • Key: MDMI_-146
  • Legacy Issue Number: 14144
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    The MessageInstance class is removed from the specification.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

The MessagePackage class is misplaced

  • Key: MDMI_-145
  • Legacy Issue Number: 14142
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    The MessagePackage class will be removed from the specification.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Proper Class name is Bag

  • Key: MDMI_-149
  • Legacy Issue Number: 14147
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

The term and class name "Message Element" may cause confusion

  • Key: MDMI_-141
  • Legacy Issue Number: 14138
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Description attributes in each class

  • Key: MDMI_-140
  • Legacy Issue Number: 14137
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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,

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Explicit datatypes in datatype rule

  • Key: MDMI_-144
  • Legacy Issue Number: 14141
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Default language settings

  • Key: MDMI_-143
  • Legacy Issue Number: 14140
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

Source reference for MessageModel

  • Key: MDMI_-142
  • Legacy Issue Number: 14139
  • Status: closed  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    see dtc/2009-09-17 for details

  • Updated: Sat, 7 Mar 2015 04:58 GMT

page 21 section 8.6.3

  • Key: MDMI_-139
  • Legacy Issue Number: 12748
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Description of the associations is missing

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Duplicate or Merged — MDMI 1.0b2
  • Disposition Summary:

    See issue 12720 for disposition

  • Updated: Sat, 7 Mar 2015 04:58 GMT

page 20 section 8.5.4

  • Key: MDMI_-138
  • Legacy Issue Number: 12747
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Duplicate or Merged — MDMI 1.0b2
  • Disposition Summary:

    See issue 12737 for disposition

  • Updated: Sat, 7 Mar 2015 04:58 GMT

page 19 section 8.5.3 para 1

  • Key: MDMI_-137
  • Legacy Issue Number: 12746
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Duplicate or Merged — MDMI 1.0b2
  • Disposition Summary:

    See issue 12716 for disposition

  • Updated: Sat, 7 Mar 2015 04:58 GMT

page 19 section 8.5.2 fig 8.5

  • Key: MDMI_-136
  • Legacy Issue Number: 12745
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Closed; No Change — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:58 GMT

page 18 section 8.5.1 para 1 line 2

  • Key: MDMI_-135
  • Legacy Issue Number: 12744
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Duplicate or Merged — MDMI 1.0b2
  • Disposition Summary:

    Disposition: See issue 12716 for disposition

  • Updated: Sat, 7 Mar 2015 04:58 GMT

page 17 section 8.4.1 para 1 line 6

  • Key: MDMI_-134
  • Legacy Issue Number: 12743
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    Changed text.

  • Updated: Sat, 7 Mar 2015 04:58 GMT

page 16 section 8.3.4 para 1, 7th bullet

  • Key: MDMI_-131
  • Legacy Issue Number: 12740
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Current text
    MessageModelName

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 16 section 8.3.4 para 1, 3rd bullet

  • Key: MDMI_-130
  • Legacy Issue Number: 12739
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 15 section 8.3.3 para 1, 2nd bullet

  • Key: MDMI_-129
  • Legacy Issue Number: 12738
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Current text
    MessageModelName
    New text

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 17 section 8.4.1 para 1

  • Key: MDMI_-133
  • Legacy Issue Number: 12742
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Duplicate or Merged — MDMI 1.0b2
  • Disposition Summary:

    Disposition: See issue 12737 for disposition

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 16 section 8.3.6 and 8.3.7

  • Key: MDMI_-132
  • Legacy Issue Number: 12741
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    What is the value and relevance of these sections?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    Changed text by adding description

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 14 section 8.3.1 para 1 line 3

  • Key: MDMI_-125
  • Legacy Issue Number: 12733
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 15 section 8.3.2 figure 8.3

  • Key: MDMI_-128
  • Legacy Issue Number: 12737
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Association between MessageComposite and MessageElement is missing

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 14 section 8.3.1 para 8

  • Key: MDMI_-127
  • Legacy Issue Number: 12736
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Closed; No Change — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 14 section 8.3.1 para 6

  • Key: MDMI_-126
  • Legacy Issue Number: 12734
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 13 section 8.2.7 title

  • Key: MDMI_-124
  • Legacy Issue Number: 12732
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Closed; No Change — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 13 section 8.2.5 para 1 3rd bullet

  • Key: MDMI_-123
  • Legacy Issue Number: 12731
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    Changed text

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 13 section 8.2.5 para 1 2nd bullet

  • Key: MDMI_-122
  • Legacy Issue Number: 12730
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    The meaning of the isUnique property is not clear.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Closed; No Change — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 12 section 8.2.2 fig 8.2

  • Key: MDMI_-121
  • Legacy Issue Number: 12729
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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)

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Duplicate or Merged — MDMI 1.0b2
  • Disposition Summary:

    Disposition: See issue 14148 for disposition

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 8.2.1 para 1 line 3

  • Key: MDMI_-120
  • Legacy Issue Number: 12728
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 8.1.4 general comment

  • Key: MDMI_-117
  • Legacy Issue Number: 12725
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Value and relevance?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    Changed text, explanation of value will be added.

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 8.2.1 para 1 line 1

  • Key: MDMI_-119
  • Legacy Issue Number: 12727
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 8.1.5 general comment

  • Key: MDMI_-118
  • Legacy Issue Number: 12726
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Value and relevance?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 10 section 8.1.3 2nd bullet

  • Key: MDMI_-116
  • Legacy Issue Number: 12724
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 9 section 8 general comment # 2

  • Key: MDMI_-113
  • Legacy Issue Number: 12721
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 10 section 8.1.3 1st bullet

  • Key: MDMI_-115
  • Legacy Issue Number: 12723
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 9 section 8.1.1 examples

  • Key: MDMI_-114
  • Legacy Issue Number: 12722
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Are these examples of Message Groups or Message Aggregates?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Closed; No Change — MDMI 1.0b2
  • Disposition Summary:

    MessageGroups

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 9 section 8 general comment

  • Key: MDMI_-112
  • Legacy Issue Number: 12720
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 7 section 7.1.5 para 1 line 3

  • Key: MDMI_-111
  • Legacy Issue Number: 12719
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 7 section 7.1.5 para 1 line 1

  • Key: MDMI_-110
  • Legacy Issue Number: 12718
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 7 section 7.1.5 general comment

  • Key: MDMI_-109
  • Legacy Issue Number: 12717
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 7 section 7.1.2 para 1 line 6

  • Key: MDMI_-108
  • Legacy Issue Number: 12716
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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)

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 14 section 6.5.3 para 1 line 4

  • Key: MDMI_-104
  • Legacy Issue Number: 12712
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 14 section 6.5.2 para 1 line 6

  • Key: MDMI_-103
  • Legacy Issue Number: 12711
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 5 section 7 - general comment

  • Key: MDMI_-106
  • Legacy Issue Number: 12714
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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)

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 5 section 7 para 1 line 4

  • Key: MDMI_-107
  • Legacy Issue Number: 12715
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Closed; No Change — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 5 section 7 - title

  • Key: MDMI_-105
  • Legacy Issue Number: 12713
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 14 section 6.5.1 para 1

  • Key: MDMI_-101
  • Legacy Issue Number: 12709
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 14 section 6.5.1 general comment

  • Key: MDMI_-100
  • Legacy Issue Number: 12708
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 14 section 6.5.2 para 1

  • Key: MDMI_-102
  • Legacy Issue Number: 12710
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 14 section 6.5.1 title

  • Key: MDMI_-99
  • Legacy Issue Number: 12707
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 14 section 6.5 title

  • Key: MDMI_-98
  • Legacy Issue Number: 12706
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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)

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 13 section 6.4 para 2

  • Key: MDMI_-97
  • Legacy Issue Number: 12705
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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)

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

typos

  • Key: MDMI_-96
  • Legacy Issue Number: 12704
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 13 section 6.4 para 1

  • Key: MDMI_-94
  • Legacy Issue Number: 12702
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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)

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 13 section 6.4 general comment

  • Key: MDMI_-93
  • Legacy Issue Number: 12701
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Closed; No Change — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 13 section 6.4 title

  • Key: MDMI_-92
  • Legacy Issue Number: 12700
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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)

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 13 section 6.3.3 title

  • Key: MDMI_-91
  • Legacy Issue Number: 12699
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

    Disposition: Resolved

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 13 section 6.4 para 1 line 2

  • Key: MDMI_-95
  • Legacy Issue Number: 12703
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 12 section 6.3.1 para 3 1st bullet

  • Key: MDMI_-87
  • Legacy Issue Number: 12695
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    Changed text

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 12 section 6.3.1 paera 3 - typo

  • Key: MDMI_-86
  • Legacy Issue Number: 12694
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    change UNOIFI to UNIFI

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 13 section 6.3.2 in general

  • Key: MDMI_-90
  • Legacy Issue Number: 12698
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    Changed text

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 13 section 6.3.2 para 1

  • Key: MDMI_-89
  • Legacy Issue Number: 12697
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 13 section 6.3.1 para 3 1st bullet

  • Key: MDMI_-88
  • Legacy Issue Number: 12696
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    What does FRB mean?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 12 section 6.3

  • Key: MDMI_-85
  • Legacy Issue Number: 12693
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 12 section 6.3 title

  • Key: MDMI_-84
  • Legacy Issue Number: 12692
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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)

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

Remove terms from Annex A

  • Key: MDMI_-83
  • Legacy Issue Number: 12691
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 sections 6.1 and 6.2

  • Key: MDMI_-82
  • Legacy Issue Number: 12690
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 6.1 para 2

  • Key: MDMI_-81
  • Legacy Issue Number: 12689
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 6.1 para 1 - correction

  • Key: MDMI_-80
  • Legacy Issue Number: 12688
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 6.1 para 1

  • Key: MDMI_-79
  • Legacy Issue Number: 12687
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 6 para 5 line 3

  • Key: MDMI_-78
  • Legacy Issue Number: 12686
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Current text
    See section 4.4
    This is a wrong reference!

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 6 para 5

  • Key: MDMI_-77
  • Legacy Issue Number: 12685
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 6 para 3

  • Key: MDMI_-76
  • Legacy Issue Number: 12684
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 6 para 3 second bullet

  • Key: MDMI_-75
  • Legacy Issue Number: 12683
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 6 para 3 first bullet

  • Key: MDMI_-74
  • Legacy Issue Number: 12682
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 11 section 6 para 1 "it is estimated.."

  • Key: MDMI_-73
  • Legacy Issue Number: 12681
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Please mention source and year for these estimates

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 6 section 5.1

  • Key: MDMI_-72
  • Legacy Issue Number: 12680
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Closed; No Change — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 6 section 4 "wire format"

  • Key: MDMI_-71
  • Legacy Issue Number: 12679
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 5 section 4 "UNIFI"

  • Key: MDMI_-70
  • Legacy Issue Number: 12678
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 5 section 4 "simple message composite"

  • Key: MDMI_-66
  • Legacy Issue Number: 12674
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 5 section 4 "type"

  • Key: MDMI_-69
  • Legacy Issue Number: 12677
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 5 section 4 "technical analyst"

  • Key: MDMI_-68
  • Legacy Issue Number: 12676
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 4 section 4 para TCxx

  • Key: MDMI_-67
  • Legacy Issue Number: 12675
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 5 section 4 "semantic map"

  • Key: MDMI_-65
  • Legacy Issue Number: 12673
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    What is the exact difference with "conversion rule"?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Closed; No Change — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 5 section 4 "semantic element"

  • Key: MDMI_-64
  • Legacy Issue Number: 12672
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 5 section 4 "runtime application"

  • Key: MDMI_-63
  • Legacy Issue Number: 12671
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 5 section 4 "qualified business element"

  • Key: MDMI_-62
  • Legacy Issue Number: 12670
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Remove this term. It is used only in another definition

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 4 section 4 "node id"

  • Key: MDMI_-61
  • Legacy Issue Number: 12669
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 4 section 4 "near synonym"

  • Key: MDMI_-60
  • Legacy Issue Number: 12668
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 4 section 4 para MTxx

  • Key: MDMI_-59
  • Legacy Issue Number: 12667
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 4 section 4 para MSxx

  • Key: MDMI_-58
  • Legacy Issue Number: 12666
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 4 section 4 "message syntax translator

  • Key: MDMI_-57
  • Legacy Issue Number: 12665
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 4 section 4 "message format"

  • Key: MDMI_-54
  • Legacy Issue Number: 12662
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 4 section 4 "message composite"

  • Key: MDMI_-53
  • Legacy Issue Number: 12661
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 4 section 4 "message element relationship model"

  • Key: MDMI_-52
  • Legacy Issue Number: 12660
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Remove this term. It is used in another defenition

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 4 section 4 "message model" and "message syntax model

  • Key: MDMI_-56
  • Legacy Issue Number: 12664
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 4 section 4 "message group"

  • Key: MDMI_-55
  • Legacy Issue Number: 12663
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 3 section 4 "message element"

  • Key: MDMI_-51
  • Legacy Issue Number: 12659
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 3 section 4 "leaf syntax translator"

  • Key: MDMI_-50
  • Legacy Issue Number: 12658
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Remove this term. It is not used in this document

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 3 section 4 "location expression language"

  • Key: MDMI_-49
  • Legacy Issue Number: 12657
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Remove this term. It is not used in this document

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 3 section 4 "location"

  • Key: MDMI_-48
  • Legacy Issue Number: 12656
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Remove term

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 3 section 4 "leaf format expression language"

  • Key: MDMI_-47
  • Legacy Issue Number: 12655
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Remove this term. It is not used in this document

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 3 section 4 "leaf format"

  • Key: MDMI_-46
  • Legacy Issue Number: 12654
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Remove this term

    It is only used in another definition

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 3 section 4 "keyword list"

  • Key: MDMI_-45
  • Legacy Issue Number: 12653
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 3 section 4 "group"

  • Key: MDMI_-44
  • Legacy Issue Number: 12652
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 3 section 4 "federate"

  • Key: MDMI_-43
  • Legacy Issue Number: 12651
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Remove this term. It is not used in this document

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 3 section 4 "federated dictionary"

  • Key: MDMI_-42
  • Legacy Issue Number: 12650
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 3 section 4 "environment"

  • Key: MDMI_-41
  • Legacy Issue Number: 12649
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Remove this term. It is not used in the document

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 3 section 4 "entity"

  • Key: MDMI_-40
  • Legacy Issue Number: 12648
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 2 section 4 "domain repository"

  • Key: MDMI_-39
  • Legacy Issue Number: 12647
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Remove the term. It is not used in the document

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 2 section 4 "domain data dictionary"

  • Key: MDMI_-38
  • Legacy Issue Number: 12646
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Remove this term. it is only used in another definition

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 2 section 4 "domain"

  • Key: MDMI_-37
  • Legacy Issue Number: 12645
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 2 section 4 - remove "business rule"

  • Key: MDMI_-34
  • Legacy Issue Number: 12642
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 2 section 4 - "business element"

  • Key: MDMI_-33
  • Legacy Issue Number: 12641
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    Changed text to say: "A Business Element is the smallest semantic unit in an external dictionary. For example, in ISO20022 Business Elements are the attributes of Business Component classes and represent a "business concept."

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 2 section 4 - "business analyst"

  • Key: MDMI_-32
  • Legacy Issue Number: 12640
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 2 section 4 conversion rule

  • Key: MDMI_-36
  • Legacy Issue Number: 12644
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 2 section 4 composition

  • Key: MDMI_-35
  • Legacy Issue Number: 12643
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 2 section 4 - "autonomy'

  • Key: MDMI_-31
  • Legacy Issue Number: 12639
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 1 section 3 - add reference to ISO 20022

  • Key: MDMI_-30
  • Legacy Issue Number: 12638
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    page 1 section 3 - add reference to ISO 20022

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 1 section 2 para 1 line 5 - normative/non-normative sections

  • Key: MDMI_-29
  • Legacy Issue Number: 12637
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 1 section 2 para 1 line 2 - problem with cross-referencing

  • Key: MDMI_-28
  • Legacy Issue Number: 12635
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 1 section 1 para 2 line 11 - remove name of standard

  • Key: MDMI_-27
  • Legacy Issue Number: 12634
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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)

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 1 section 1 para 2 line 8 remove Payment Message (CM4PM) standard

  • Key: MDMI_-24
  • Legacy Issue Number: 12631
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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)

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 1 section 1 para 2 line 3 clarification

  • Key: MDMI_-23
  • Legacy Issue Number: 12630
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 1 section 1 para 2

  • Key: MDMI_-22
  • Legacy Issue Number: 12628
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 1 section 1 para 2 line 10 clarification needed

  • Key: MDMI_-26
  • Legacy Issue Number: 12633
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 1 section 1 para 2 line 6 change to message data transformation

  • Key: MDMI_-25
  • Legacy Issue Number: 12632
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page 1 section 1 para 1

  • Key: MDMI_-21
  • Legacy Issue Number: 12627
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

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

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 04:57 GMT

name of the standard is repeated in the document

  • Key: MDMI_-20
  • Legacy Issue Number: 12626
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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.

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    Resolution:
    Fixed in Beta specification
    Revised Text:
    Please see the annotated Beta 2 with markup.

  • Updated: Sat, 7 Mar 2015 04:57 GMT

page numbering

  • Key: MDMI_-19
  • Legacy Issue Number: 12625
  • Status: closed  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    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)

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Disposition: Resolved — MDMI 1.0b2
  • Disposition Summary:

    Resolution:
    Fixed in Beta specification
    Revised Text:
    Please see the annotated Beta 2 with markup.

  • Updated: Sat, 7 Mar 2015 04:57 GMT