${taskforce.name} Avatar
  1. OMG Task Force

MDMI 1.1 RTF — Open Issues

  • Key: MDMI11
  • Issues Count: 15
Open Closed All
Issues not resolved

Issues Descriptions

Standard XMI for MDMI maps

  • Key: MDMI11-11
  • Legacy Issue Number: 14195
  • Status: open  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

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

  • Reported: MDMI 1.0b2 — Fri, 21 Aug 2009 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT

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

  • Key: MDMI11-14
  • Legacy Issue Number: 14154
  • Status: open  
  • 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
  • Updated: Tue, 24 Mar 2015 23:05 GMT

Description attributes in each class

  • Key: MDMI11-13
  • Legacy Issue Number: 14153
  • Status: open  
  • 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
  • Updated: Tue, 24 Mar 2015 23:05 GMT

data translation in the prexecns of structure clashes

  • Key: MDMI11-10
  • Legacy Issue Number: 14571
  • Status: open  
  • Source: Open Mapping Software ( Robert Worden)
  • Summary:

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

  • Reported: MDMI 1.0b2 — Mon, 19 Oct 2009 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT

Associations/opposite properties should be used with MDMIDatatype

  • Key: MDMI11-9
  • Legacy Issue Number: 15361
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

    • SemanticElement::datatype
    • DataRule::datatype
    • MDMIBusinessElementReference::referenceDatatype
  • Reported: MDMI 1.0b2 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT

Domain dictionary reference

  • Key: MDMI11-12
  • Legacy Issue Number: 14143
  • Status: open  
  • Source: SemantX, Inc. ( Mark Eisner)
  • Summary:

    A key concept of MDMI is that it requires a domain dictionary as a hub in its "hub and spoke design". The current specification does not associate a Message Model with a domain dictionary. If the specification is to work, such a reference will be important. Otherwise, the specification will not be clear and maps may be ambiguous.

  • Reported: MDMI 1.0b1 — Wed, 29 Jul 2009 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT

Must all implementations have a design-time activity?

  • Key: MDMI11-15
  • Legacy Issue Number: 12636
  • Status: open  
  • Source: SWIFT ( Frank Vandamme)
  • Summary:

    Current text
    In particular, an implementation needs to support a design-time activity with all of the steps involved in generating the conversion maps, and the runtime application of the generated maps to a source physical message in order to create a target physical message.
    New text
    SEE QUESTIONS & COMMENTS IN NEXT COLUMN
    Rationale
    Must all implementations have a design-time activity? Don't we expect to have more implementations that use the conversion maps than implementations that can create the maps?

  • Reported: MDMI 1.0b1 — Tue, 8 Jul 2008 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT

Urgent issue - Missing datatype

  • Key: MDMI11-8
  • Legacy Issue Number: 15358
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

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

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

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

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

  • Reported: MDMI 1.0b2 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT

Urgent issue - Property Node::/isSyntacticField is not readOnly in the metamodel and has a default value of false

  • Key: MDMI11-6
  • Legacy Issue Number: 15360
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: MDMI 1.0b2 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT

Urgent issue – misspelled property

  • Key: MDMI11-7
  • Legacy Issue Number: 15359
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: MDMI 1.0b2 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT

The description and use of MDMIBusinessElementRule is completely unclear

  • Key: MDMI11-4
  • Legacy Issue Number: 15365
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: MDMI 1.0b2 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT

Section 8.5.3

  • Key: MDMI11-3
  • Legacy Issue Number: 15364
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: MDMI 1.0b2 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT

Section 8.6.3 makes several references to ‘source’ and ‘target’ SemanticElements

  • Key: MDMI11-1
  • Legacy Issue Number: 15366
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: MDMI 1.0b2 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT

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

  • Key: MDMI11-2
  • Legacy Issue Number: 15363
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: MDMI 1.0b2 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT

Property SemanticElementSet::/mesageModelname should have isReadOnly= true

  • Key: MDMI11-5
  • Legacy Issue Number: 15362
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Property SemanticElementSet::/mesageModelname should have isReadOnly= true

  • Reported: MDMI 1.0b2 — Thu, 1 Jul 2010 04:00 GMT
  • Updated: Tue, 24 Mar 2015 23:05 GMT