Issue 17389: An XMIReferenceElement cannot be used for serializing a composite property (mof2xmi-rtf) Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com) Nature: Uncategorized Issue Severity: Summary: Specification: OMG MOF XMI Mapping Specification, Version 2.4.1 (formal/2011-08-09) Subclause 9.4.1 EMOF Package requires that “A property, type is not a PrimitiveType or Enumeration, isComposite=true” have an XMI representation of “Nested XMIObjectElement”. Nothing in Subclause 9.4.2 CMOF Package alters this. The BNF for an XMIObjectElement is given in Subclause 9.5.2 Object Structure by production 2a:XMIObjectElement. This production does allow such an element to include 2d:XMIAttributes, but such attributes do not include hrefs. The production 2m:Link is the one for hrefs, and this is used in 2l:LinkAttribs, which is, in turn, used only by 2c:XMIReferenceElement. It is not included directly in 2a:XMIObjectElement. So, the conclusion is that something like “<packagedElement href=”…”/> would not be a valid EMOF/CMOF serialization, since that is an XMIReferenceElement, not and XMIObjectElement, and packagedElement is a composite property. Divide a large model based on its hierarchical composition structure into across multiple XMI files, resulting in tool-specific approaches for such modularization in most major UML tools. Suggested resolution: In the last line of the table in Subclause 9.4.1, change the XMI representation of “XMIObjectElement” to: Choice of: 1. Nested XMIObjectElement 2. Nested XMIReferenceElement Resolution: Revised Text: Actions taken: May 22, 2012: received issue Discussion: End of Annotations:===== m: Ed Seidewitz To: "issues@omg.org" CC: "Pete Rivett (pete.rivett@adaptive.com)" , Cory Casanave , "Tom Digre (tom.digre@yahoo.com)" Date: Tue, 22 May 2012 11:09:44 -0400 Subject: An XMIReferenceElement cannot be used for serializing a composite property Thread-Topic: An XMIReferenceElement cannot be used for serializing a composite property Thread-Index: Ac04K6d+iX8dkyIZQ6W0+HANv0crTA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|-0.998843|0.83964|0|white|ugly|3454|2|0|0 X-Mailprotector-Results: null_ptr subject_50_chars clean X-Mailprotector-Score: 60 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0.83964 p=-0.998843 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-11172-c X-Mailprotector-ID: 17cefd4b-81c2-44ce-af61-9145eabe1bb4 Specification: OMG MOF XMI Mapping Specification, Version 2.4.1 (formal/2011-08-09) Subclause 9.4.1 EMOF Package requires that .A property, type is not a PrimitiveType or Enumeration, isComposite=true. have an XMI representation of .Nested XMIObjectElement.. Nothing in Subclause 9.4.2 CMOF Package alters this. The BNF for an XMIObjectElement is given in Subclause 9.5.2 Object Structure by production 2a:XMIObjectElement. This production does allow such an element to include 2d:XMIAttributes, but such attributes do not include hrefs. The production 2m:Link is the one for hrefs, and this is used in 2l:LinkAttribs, which is, in turn, used only by 2c:XMIReferenceElement. It is not included directly in 2a:XMIObjectElement. So, the conclusion is that something like . would not be a valid EMOF/CMOF serialization, since that is an XMIReferenceElement, not and XMIObjectElement, and packagedElement is a composite property. Divide a large model based on its hierarchical composition structure into across multiple XMI files, resulting in tool-specific approaches for such modularization in most major UML tools. Suggested resolution: In the last line of the table in Subclause 9.4.1, change the XMI representation of .XMIObjectElement. to: Choice of: 1. Nested XMIObjectElement 2. Nested XMIReferenceElement