Issue 7648: XMI 2.0 terminology (mof2xmi-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: I am reading through the XMI 2.0 "convenience document" ptc/04-06-11 and I am getting stuck trying to figure out the terminlogy. In particular, what precicely is a "reference," what is an "association end," and what is an "association role?" "Reference" and "association end" seem to be leftovers from MOF 1.4, while "association role" is maybe a leftover from UML 1.x. But, as far as I can tell these constructs do not exist any more in MOF 2, so some definitions for them are need. Are these suitable definitions?: Reference: A reference is a Property owned by a Class (ownedProperty) with isComposite=false and a type that is a subtype of Class. Association End: An association end is a Property owned by an Association (ownedEnd). Association Role: An association role is an association end. In section 7.8.4, there is a statement "For multi-valued Properties, no XML attributes are declared; each value is encoded as an XML element." However, the OMG-provided XMI 2.0 representations of the EMOF/CMOF models use attributes to represent multi-valued Properties that meet the definition of "Reference" above. This seems to be a contradiction. I assume that the XMI spec should say "For multi-valued Properties, no XML attributes are declared; each value is encoded as an XML element, unless the Property is a Reference." Resolution: Revised Text: Actions taken: August 13, 2004: received sisue Discussion: End of Annotations:===== te: Fri, 13 Aug 2004 10:41:52 +0200 From: Martin Matula Subject: [Fwd: XMI 2.0 terminology] To: mof2xmi-ftf@omg.org X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 Anybody wants to reply? Return-path: Received: from conversion-daemon.bohemia2-mail1.czech.sun.com by bohemia2-mail1.czech.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I2900601VYYZN@bohemia2-mail1.czech.sun.com> (original mail from owner-jmi-interest@JAVA.SUN.COM) for mm109185@bohemia2-mail1.Czech.Sun.COM; Wed, 11 Aug 2004 10:14:38 +0200 (CEST) Received: from sunpraha.Czech.Sun.COM (sunpraha [129.156.75.4]) by bohemia2-mail1.czech.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0I2900090W8EXZ@bohemia2-mail1.czech.sun.com> for mm109185@bohemia2-mail1.Czech.Sun.COM (ORCPT martin.matula@SUN.COM); Wed, 11 Aug 2004 10:14:38 +0200 (CEST) Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sunpraha.Czech.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id i7B8EZn05929 for ; Wed, 11 Aug 2004 10:14:36 +0200 (CEST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id i7B8EUV00542; Wed, 11 Aug 2004 01:14:30 -0700 (PDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i7B8ETsZ028507; Wed, 11 Aug 2004 02:14:29 -0600 (MDT) Received: from mms22es.sun.com (mms22es.sun.com [150.143.232.34]) by relay22i.sun.com with ESMTP; Wed, 11 Aug 2004 08:14:28 +0000 (Z) Received: from mms21bas.mms.us.syntegra.com (mms21bas.mms.us.syntegra.com [192.12.251.10]) by mms22es.sun.com with ESMTP; Wed, 11 Aug 2004 08:14:28 +0000 (Z) Received: from swjscmail2.java.sun.com (swjscmail2.java.sun.com [192.18.99.108]) by relay21.sun.com with ESMTP; Wed, 11 Aug 2004 08:14:28 +0000 (Z) Received: from swjscmail1 (swjscmail1.Sun.COM [192.18.99.107]) by swjscmail2.java.sun.com (Postfix) with ESMTP id 7C599214E1; Wed, 11 Aug 2004 02:07:51 -0600 (MDT) Received: from JAVA.SUN.COM by JAVA.SUN.COM (LISTSERV-TCP/IP release 1.8e) with spool id 37523768 for JMI-INTEREST@JAVA.SUN.COM; Wed, 11 Aug 2004 02:03:10 -0600 Received: from night.its.uiowa.edu (night.its.uiowa.edu [128.255.56.106]) by swjscmail1.java.sun.com (Postfix) with ESMTP id 491BC4942 for ; Wed, 11 Aug 2004 01:53:09 -0600 (MDT) Received: from [129.255.176.248] (host176-248.uihc.uiowa.edu [129.255.176.248]) by night.its.uiowa.edu (8.12.10/8.12.9/ns-mx-1.16) with ESMTP id i7B84JSi018044 for ; Wed, 11 Aug 2004 03:04:19 -0500 Date: Wed, 11 Aug 2004 03:04:19 -0500 From: Brian Smith Subject: XMI 2.0 terminology Sender: Discussion list for Java Metadata Interface To: JMI-INTEREST@JAVA.SUN.COM Reply-to: Discussion list for Java Metadata Interface Message-id: <4119D303.30201@uiowa.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: list Delivered-to: JMI-INTEREST@JAVA.SUN.COM User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Original-To: JMI-INTEREST@JAVA.SUN.COM Original-recipient: rfc822;martin.matula@SUN.COM Hi, I am reading through the XMI 2.0 "convenience document" ptc/04-06-11 and I am getting stuck trying to figure out the terminlogy. In particular, what precicely is a "reference," what is an "association end," and what is an "association role?" "Reference" and "association end" seem to be leftovers from MOF 1.4, while "association role" is maybe a leftover from UML 1.x. But, as far as I can tell these constructs do not exist any more in MOF 2, so some definitions for them are need. Are these suitable definitions?: Reference: A reference is a Property owned by a Class (ownedProperty) with isComposite=false and a type that is a subtype of Class. Association End: An association end is a Property owned by an Association (ownedEnd). Association Role: An association role is an association end. In section 7.8.4, there is a statement "For multi-valued Properties, no XML attributes are declared; each value is encoded as an XML element." However, the OMG-provided XMI 2.0 representations of the EMOF/CMOF models use attributes to represent multi-valued Properties that meet the definition of "Reference" above. This seems to be a contradiction. I assume that the XMI spec should say "For multi-valued Properties, no XML attributes are declared; each value is encoded as an XML element, unless the Property is a Reference." Thanks, Brian Smith