Issue 4398: supplierDependency reference is missing from ModelElement (cwm-rtf) Source: International Business Machines (Dr. Daniel T. Chang, dtchang@us.ibm.com) Nature: Revision Severity: Significant Summary: The supplierDependency reference is missing from ModelElement, which existed in the CWM Adapted Specification.This change makes the model illogical and unbalanced. Dependency is always defined between two ModelElements (a client and a supplier). Its definition involves two associations and four association ends. Either the supplierDependency reference should be put back (which makes a more flexible model) or the client reference on Dependency should also be removed (which makes a more restrictive model, but at least it is logical and balanced). (This is a revised write-up for issue #3398.) Resolution: Revised Text: Actions taken: July 20, 2001: received issue Discussion: End of Annotations:===== mportance: High Subject: Two errors on ModelElement To: Doug.Tolbert@unisys.com Cc: cwm-rtf@omg.org, "Jing Chu" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Dan Chang" Date: Fri, 20 Jul 2001 11:06:01 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/20/2001 12:06:02 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: &%Wd970hd9X<$!!#^?!! Doug, We just found two errors on ModelElement, which make CWM 1.0 incompatible with the CWM Adapted Specification. I hope you can make the correction and generate a new ObjectCore.cat asap, since this is affecting our ability to implement CWM 1.0. (1) ModelElement is missing a "supplierDependency" reference to Dependency. (It has a clientDependency reference to Dependency, and Dependency has both client and supplier references to ModelElement.) (2) ModelElement is missing a "taggedValue" reference to TaggedValue. (ModelElement owns TaggedValue. StereoType also owns TaggedValue and has a requiredTag reference to TaggedValue.) Thanks in advance. Regards, Dan e-business Data Technology and Standard IBM Silicon Valley Laboratory Notes: Dan Chang/Santa Teresa/IBM@IBMUS Internet: dtchang@us.ibm.com VM: IBMUSM50(DTCHANG) Phone: (408)-463-2319 From: "Tolbert, Doug M" To: Dan Chang Cc: cwm-rtf@omg.org, Jing Chu , "Baisley, Donald E" Subject: RE: Two errors on ModelElement Date: Fri, 20 Jul 2001 17:50:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: !FUd9KJFe9Y^Sd9DOZd9 Dan, You are right about (2), the taggedValue reference should be on ModelElement. I think its absence is a hangover from some of the repackaging efforts late in CWM 1.0. Why don't you start an issue on the OMG web page and we can add the fix in 1.1. (I can send you an update cat file as you requested for your use in the mean time). However, (1) is as designed. There are several places in CWM where there is no reference on one side of an association. This is to support distributed metadata and is in compliance with MOF rules. The choice to leave off the reference on one end allows that end to be referenced from other extents in the same way, as for example, the type an attribute can occur in a different extent. In this case, it makes sense for a ModelElement to see what it depends on, but not for it to see what depends on it -- hence no supplierDependency reference on ModelElement. Doug -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Friday, July 20, 2001 11:06 AM To: Doug.Tolbert@unisys.com Cc: cwm-rtf@omg.org; Jing Chu Subject: Two errors on ModelElement Importance: High Doug, We just found two errors on ModelElement, which make CWM 1.0 incompatible with the CWM Adapted Specification. I hope you can make the correction and generate a new ObjectCore.cat asap, since this is affecting our ability to implement CWM 1.0. (1) ModelElement is missing a "supplierDependency" reference to Dependency. (It has a clientDependency reference to Dependency, and Dependency has both client and supplier references to ModelElement.) (2) ModelElement is missing a "taggedValue" reference to TaggedValue. (ModelElement owns TaggedValue. StereoType also owns TaggedValue and has a requiredTag reference to TaggedValue.) Thanks in advance. Regards, Dan e-business Data Technology and Standard IBM Silicon Valley Laboratory Notes: Dan Chang/Santa Teresa/IBM@IBMUS Internet: dtchang@us.ibm.com VM: IBMUSM50(DTCHANG) Phone: (408)-463-2319 Subject: RE: Two errors on ModelElement To: "Tolbert, Doug M" Cc: cwm-rtf@omg.org, "Baisley, Donald E" , Jing Chu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Dan Chang" Date: Fri, 20 Jul 2001 16:18:20 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/20/2001 05:18:23 PM MIME-Version: 1.0 Content-Disposition: inline Content-Type: multipart/mixed; Boundary="0__=88256A8F007DD1358f9e8a93df938690918c88256A8F007DD135" X-UIDL: =HX!!_cN!!$L,e9o'k!! Doug, I do not agree with you on (1) for two reasons: (a) This makes CWM 1.0 incompatible with the CWM Adapted Specification for no justifiable reason. (b) ModelElement has a clientDependency reference to Dependency. Dependency has both client and server references to ModelElement. Why should one (supplierDependency) out of the four references involved be removed in CWM 1.0? Please note that Dependency is always used with two ModelElements; a client and a supplier. (Embedded image moved to file: pic24993.pcx) Regards, Dan e-business Data Technology and Standard IBM Silicon Valley Laboratory Notes: Dan Chang/Santa Teresa/IBM@IBMUS Internet: dtchang@us.ibm.com VM: IBMUSM50(DTCHANG) Phone: (408)-463-2319 "Tolbert, Doug M" To: Dan Chang/Santa Teresa/IBM@IBMUS "Baisley, Donald E" Subject: RE: Two errors on ModelElement 07/20/01 03:50 PM Dan, You are right about (2), the taggedValue reference should be on ModelElement. I think its absence is a hangover from some of the repackaging efforts late in CWM 1.0. Why don't you start an issue on the OMG web page and we can add the fix in 1.1. (I can send you an update cat file as you requested for your use in the mean time). However, (1) is as designed. There are several places in CWM where there is no reference on one side of an association. This is to support distributed metadata and is in compliance with MOF rules. The choice to leave off the reference on one end allows that end to be referenced from other extents in the same way, as for example, the type an attribute can occur in a different extent. In this case, it makes sense for a ModelElement to see what it depends on, but not for it to see what depends on it -- hence no supplierDependency reference on ModelElement. Doug -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Friday, July 20, 2001 11:06 AM To: Doug.Tolbert@unisys.com Cc: cwm-rtf@omg.org; Jing Chu Subject: Two errors on ModelElement Importance: High Doug, We just found two errors on ModelElement, which make CWM 1.0 incompatible with the CWM Adapted Specification. I hope you can make the correction and generate a new ObjectCore.cat asap, since this is affecting our ability to implement CWM 1.0. (1) ModelElement is missing a "supplierDependency" reference to Dependency. (It has a clientDependency reference to Dependency, and Dependency has both client and supplier references to ModelElement.) (2) ModelElement is missing a "taggedValue" reference to TaggedValue. (ModelElement owns TaggedValue. StereoType also owns TaggedValue and has a requiredTag reference to TaggedValue.) Thanks in advance. Regards, Dan e-business Data Technology and Standard IBM Silicon Valley Laboratory Notes: Dan Chang/Santa Teresa/IBM@IBMUS Internet: dtchang@us.ibm.com VM: IBMUSM50(DTCHANG) Phone: (408)-463-2319 [] pic24993.pcx From: "Pete Rivett" To: "'Dan Chang'" , "'Tolbert, Doug M'" Cc: , "'Baisley, Donald E'" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references Date: Sat, 21 Jul 2001 13:09:40 +0100 Message-ID: <004e01c111de$05950a30$114c04c8@CHIMAY> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Content-Type: text/plain; charset="us-ascii" X-UIDL: nNQ!!B>J!!1'6!!_IIe9 I agree with Dan's point about the need to have 2-way navigation of dependencies and also with the Doug's point about the need to facilitate federation. I believe both needs can be met with existing models and specifications and I describe this below. Obviously there remains an incompatibility between UML 1.3 and UML 1.4, but there was a reason for the change - as Doug described. To reprise, Dan's issue is the dropping of the supplierDependency reference from ModelElement to Dependency. Firstly I should say that the information will still be present in the XMI file - either through the Dependency element or through the Association/Link elements. Secondly when using APIs one does not have to use a reference to navigate an association: to get from a ModelElement to the Dependencies for which it is the supplier one can use the Association itself: For ModelElement, the IDL contains: DependencySet client_dependency () The equivalent for supplier can be gained by using DependencySet supplier_dependency (in ModelElement supplier) on interface: interface ASupplierSupplierDependency : Reflective::RefAssociation So for a ModelElement M, instead of calling: M.supplierDependency() one would call: A.supplier_dependency(M) Where A is obtained from the following attribute on the package extent: readonly attribute ASupplierSupplierDependency a_supplier_supplier_dependency_ref; It would thus be possible, for convenience, to define the equivalent of supplierDependency as a derived reference on ModelElement IF AND ONLY IF you knew which package extent(s) to use for querying the Association: it is precisely the lack of this knowledge in the general federated case that has led to dropping the reference from the standard UML metamodel. But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. Hope that helps, Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: 21 July 2001 00:18 > To: Tolbert, Doug M > Cc: cwm-rtf@omg.org; Baisley, Donald E; Jing Chu > Subject: RE: Two errors on ModelElement > > > > Doug, > > I do not agree with you on (1) for two reasons: > (a) This makes CWM 1.0 incompatible with the CWM Adapted > Specification for > no justifiable reason. > (b) ModelElement has a clientDependency reference to > Dependency. Dependency > has both client and server references to ModelElement. Why should one > (supplierDependency) out of the four references involved be > removed in CWM > 1.0? Please note that Dependency is always used with two > ModelElements; a > client and a supplier. > > (Embedded image moved to file: pic24993.pcx) > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > > > "Tolbert, Doug > > M" To: Dan > Chang/Santa Teresa/IBM@IBMUS > cwm-rtf@omg.org, Jing Chu/Santa Teresa/IBM@IBMUS, > nisys.com> "Baisley, Donald > E" > Subject: RE: > Two errors on ModelElement > 07/20/01 03:50 > > PM > > > > > > > > > Dan, > > You are right about (2), the taggedValue reference should be on > ModelElement. I think its absence is a hangover from some of the > repackaging efforts late in CWM 1.0. Why don't you start an > issue on the > OMG web page and we can add the fix in 1.1. (I can send you > an update cat > file as you requested for your use in the mean time). > > However, (1) is as designed. There are several places in CWM > where there > is > no reference on one side of an association. This is to > support distributed > metadata and is in compliance with MOF rules. The choice to > leave off the > reference on one end allows that end to be referenced from > other extents in > the same way, as for example, the type an attribute can occur in a > different > extent. In this case, it makes sense for a ModelElement to > see what it > depends on, but not for it to see what depends on it -- hence no > supplierDependency reference on ModelElement. > > Doug > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Friday, July 20, 2001 11:06 AM > To: Doug.Tolbert@unisys.com > Cc: cwm-rtf@omg.org; Jing Chu > Subject: Two errors on ModelElement > Importance: High > > > Doug, > > We just found two errors on ModelElement, which make CWM 1.0 > incompatible > with the CWM Adapted Specification. I hope you can make the > correction and > generate a new ObjectCore.cat asap, since this is affecting > our ability to > implement CWM 1.0. > (1) ModelElement is missing a "supplierDependency" reference > to Dependency. > (It has a clientDependency reference to Dependency, and > Dependency has both > client and supplier references to ModelElement.) > (2) ModelElement is missing a "taggedValue" reference to TaggedValue. > (ModelElement owns TaggedValue. StereoType also owns > TaggedValue and has a > requiredTag reference to TaggedValue.) > > Thanks in advance. > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. From: John_Poole@hyperion.com Subject: RE: Two errors on ModelElement - navigating without references To: "Pete Rivett" Cc: "'Dan Chang'" , "'Tolbert, Doug M'" , , "'Baisley, Donald E'" , "'Jing Chu'" Date: Mon, 23 Jul 2001 10:55:19 -0400 Message-ID: X-MIMETrack: Serialize by Router on Stmfd-Gateway1/na/Hyperion(Release 5.0.5 |September 22, 2000) at 07/23/2001 10:55:24 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: 9Y on 07/21/2001 08:09:40 AM To: "'Dan Chang'" , "'Tolbert, Doug M'" cc: , "'Baisley, Donald E'" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references I agree with Dan's point about the need to have 2-way navigation of dependencies and also with the Doug's point about the need to facilitate federation. I believe both needs can be met with existing models and specifications and I describe this below. Obviously there remains an incompatibility between UML 1.3 and UML 1.4, but there was a reason for the change - as Doug described. To reprise, Dan's issue is the dropping of the supplierDependency reference from ModelElement to Dependency. Firstly I should say that the information will still be present in the XMI file - either through the Dependency element or through the Association/Link elements. Secondly when using APIs one does not have to use a reference to navigate an association: to get from a ModelElement to the Dependencies for which it is the supplier one can use the Association itself: For ModelElement, the IDL contains: DependencySet client_dependency () The equivalent for supplier can be gained by using DependencySet supplier_dependency (in ModelElement supplier) on interface: interface ASupplierSupplierDependency : Reflective::RefAssociation So for a ModelElement M, instead of calling: M.supplierDependency() one would call: A.supplier_dependency(M) Where A is obtained from the following attribute on the package extent: readonly attribute ASupplierSupplierDependency a_supplier_supplier_dependency_ref; It would thus be possible, for convenience, to define the equivalent of supplierDependency as a derived reference on ModelElement IF AND ONLY IF you knew which package extent(s) to use for querying the Association: it is precisely the lack of this knowledge in the general federated case that has led to dropping the reference from the standard UML metamodel. But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. Hope that helps, Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: 21 July 2001 00:18 > To: Tolbert, Doug M > Cc: cwm-rtf@omg.org; Baisley, Donald E; Jing Chu > Subject: RE: Two errors on ModelElement > > > > Doug, > > I do not agree with you on (1) for two reasons: > (a) This makes CWM 1.0 incompatible with the CWM Adapted > Specification for > no justifiable reason. > (b) ModelElement has a clientDependency reference to > Dependency. Dependency > has both client and server references to ModelElement. Why should one > (supplierDependency) out of the four references involved be > removed in CWM > 1.0? Please note that Dependency is always used with two > ModelElements; a > client and a supplier. > > (Embedded image moved to file: pic24993.pcx) > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > > > "Tolbert, Doug > > M" To: Dan > Chang/Santa Teresa/IBM@IBMUS > cwm-rtf@omg.org, Jing Chu/Santa Teresa/IBM@IBMUS, > nisys.com> "Baisley, Donald > E" > Subject: RE: > Two errors on ModelElement > 07/20/01 03:50 > > PM > > > > > > > > > Dan, > > You are right about (2), the taggedValue reference should be on > ModelElement. I think its absence is a hangover from some of the > repackaging efforts late in CWM 1.0. Why don't you start an > issue on the > OMG web page and we can add the fix in 1.1. (I can send you > an update cat > file as you requested for your use in the mean time). > > However, (1) is as designed. There are several places in CWM > where there > is > no reference on one side of an association. This is to > support distributed > metadata and is in compliance with MOF rules. The choice to > leave off the > reference on one end allows that end to be referenced from > other extents in > the same way, as for example, the type an attribute can occur in a > different > extent. In this case, it makes sense for a ModelElement to > see what it > depends on, but not for it to see what depends on it -- hence no > supplierDependency reference on ModelElement. > > Doug > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Friday, July 20, 2001 11:06 AM > To: Doug.Tolbert@unisys.com > Cc: cwm-rtf@omg.org; Jing Chu > Subject: Two errors on ModelElement > Importance: High > > > Doug, > > We just found two errors on ModelElement, which make CWM 1.0 > incompatible > with the CWM Adapted Specification. I hope you can make the > correction and > generate a new ObjectCore.cat asap, since this is affecting > our ability to > implement CWM 1.0. > (1) ModelElement is missing a "supplierDependency" reference > to Dependency. > (It has a clientDependency reference to Dependency, and > Dependency has both > client and supplier references to ModelElement.) > (2) ModelElement is missing a "taggedValue" reference to TaggedValue. > (ModelElement owns TaggedValue. StereoType also owns > TaggedValue and has a > requiredTag reference to TaggedValue.) > > Thanks in advance. > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. From: "Tolbert, Doug M" To: John_Poole@hyperion.com, Pete Rivett Cc: "'Dan Chang'" , "Tolbert, Doug M" , cwm-rtf@omg.org, "Baisley, Donald E" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references Date: Mon, 23 Jul 2001 11:34:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: D/De9^Bad9m_=e9*~W!! Gents, Well, I'd like to have all those convenient references there as well. However, such references change our statement that "CWM is MOF compliant" to "CWM is MOF compliant when it's convenient". If I understand things correctly (and deferring to DonB on the fine technical points), the culprit is a MOF rule that says if the classes on either end of an association both have references, then both classes and the linking association must reside in the same EXTENT (note that this does not say "Package"; an extent is equivalent to a repository instance). So, if the association crosses an extent boundry, it can't have references on both ends. (The fact that ModelElement, Dependency, and the DependencyClient assocation are in the same package is immaterial -- it's the extent boundry that matters.) We have always acknowledged that in these cases you had to query the association, the class' reference. To want to have it both ways, while understandable, is "speaking with forked tongue". -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Monday, July 23, 2001 7:55 AM To: Pete Rivett Cc: 'Dan Chang'; 'Tolbert, Doug M'; cwm-rtf@omg.org; 'Baisley, Donald E'; 'Jing Chu' Subject: RE: Two errors on ModelElement - navigating without references Pete, Regarding your final comment: But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. The fact that you leverage reflection to resolve the navigation still doesn't change the fact that a mapped interface for ModelElement is not going to contain method calls supporting a supplierDependency reference. So I'm a little confused about your comment that "it's transparent to the user .... whether there is a stored reference in the metamodel or not". I think Dan's point is that, regardless of how tractible (or intractible) the problem of implementing a supplierDependency reference might be, the reference simply doesn't exist in the CWM 1.0 standard, hence there is no user transparency in this regard. There are a number of other places in the CWM 1.0 metamodel, by the way, where I've found a number of "asymmetrical" usages of references, some I think are intentional, some not. I will forward my complete list for comment shortly. Regards, John "Pete Rivett" on 07/21/2001 08:09:40 AM To: "'Dan Chang'" , "'Tolbert, Doug M'" cc: , "'Baisley, Donald E'" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references I agree with Dan's point about the need to have 2-way navigation of dependencies and also with the Doug's point about the need to facilitate federation. I believe both needs can be met with existing models and specifications and I describe this below. Obviously there remains an incompatibility between UML 1.3 and UML 1.4, but there was a reason for the change - as Doug described. To reprise, Dan's issue is the dropping of the supplierDependency reference from ModelElement to Dependency. Firstly I should say that the information will still be present in the XMI file - either through the Dependency element or through the Association/Link elements. Secondly when using APIs one does not have to use a reference to navigate an association: to get from a ModelElement to the Dependencies for which it is the supplier one can use the Association itself: For ModelElement, the IDL contains: DependencySet client_dependency () The equivalent for supplier can be gained by using DependencySet supplier_dependency (in ModelElement supplier) on interface: interface ASupplierSupplierDependency : Reflective::RefAssociation So for a ModelElement M, instead of calling: M.supplierDependency() one would call: A.supplier_dependency(M) Where A is obtained from the following attribute on the package extent: readonly attribute ASupplierSupplierDependency a_supplier_supplier_dependency_ref; It would thus be possible, for convenience, to define the equivalent of supplierDependency as a derived reference on ModelElement IF AND ONLY IF you knew which package extent(s) to use for querying the Association: it is precisely the lack of this knowledge in the general federated case that has led to dropping the reference from the standard UML metamodel. But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. Hope that helps, Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: 21 July 2001 00:18 > To: Tolbert, Doug M > Cc: cwm-rtf@omg.org; Baisley, Donald E; Jing Chu > Subject: RE: Two errors on ModelElement > > > > Doug, > > I do not agree with you on (1) for two reasons: > (a) This makes CWM 1.0 incompatible with the CWM Adapted > Specification for > no justifiable reason. > (b) ModelElement has a clientDependency reference to > Dependency. Dependency > has both client and server references to ModelElement. Why should one > (supplierDependency) out of the four references involved be > removed in CWM > 1.0? Please note that Dependency is always used with two > ModelElements; a > client and a supplier. > > (Embedded image moved to file: pic24993.pcx) > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > > > "Tolbert, Doug > > M" To: Dan > Chang/Santa Teresa/IBM@IBMUS > cwm-rtf@omg.org, Jing Chu/Santa Teresa/IBM@IBMUS, > nisys.com> "Baisley, Donald > E" > Subject: RE: > Two errors on ModelElement > 07/20/01 03:50 > > PM > > > > > > > > > Dan, > > You are right about (2), the taggedValue reference should be on > ModelElement. I think its absence is a hangover from some of the > repackaging efforts late in CWM 1.0. Why don't you start an > issue on the > OMG web page and we can add the fix in 1.1. (I can send you > an update cat > file as you requested for your use in the mean time). > > However, (1) is as designed. There are several places in CWM > where there > is > no reference on one side of an association. This is to > support distributed > metadata and is in compliance with MOF rules. The choice to > leave off the > reference on one end allows that end to be referenced from > other extents in > the same way, as for example, the type an attribute can occur in a > different > extent. In this case, it makes sense for a ModelElement to > see what it > depends on, but not for it to see what depends on it -- hence no > supplierDependency reference on ModelElement. > > Doug > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Friday, July 20, 2001 11:06 AM > To: Doug.Tolbert@unisys.com > Cc: cwm-rtf@omg.org; Jing Chu > Subject: Two errors on ModelElement > Importance: High > > > Doug, > > We just found two errors on ModelElement, which make CWM 1.0 > incompatible > with the CWM Adapted Specification. I hope you can make the > correction and > generate a new ObjectCore.cat asap, since this is affecting > our ability to > implement CWM 1.0. > (1) ModelElement is missing a "supplierDependency" reference > to Dependency. > (It has a clientDependency reference to Dependency, and > Dependency has both > client and supplier references to ModelElement.) > (2) ModelElement is missing a "taggedValue" reference to TaggedValue. > (ModelElement owns TaggedValue. StereoType also owns > TaggedValue and has a > requiredTag reference to TaggedValue.) > > Thanks in advance. > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. From: "Tolbert, Doug M" To: "Tolbert, Doug M" , "'John_Poole@hyperion.com'" , "'Pete Rivett'" Cc: "'Dan Chang'" , "'cwm-rtf@omg.org'" , "Baisley, Donald E" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references Date: Mon, 23 Jul 2001 11:37:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 28-e94H9e9IU4!!LN"!! The penultimate sentence should read "We have always acknowledged that in these cases you had to query the association, NOT the class' reference." Sorry -----Original Message----- From: Tolbert, Doug M Sent: Monday, July 23, 2001 9:35 AM To: John_Poole@hyperion.com; Pete Rivett Cc: 'Dan Chang'; Tolbert, Doug M; cwm-rtf@omg.org; Baisley, Donald E; 'Jing Chu' Subject: RE: Two errors on ModelElement - navigating without references Gents, Well, I'd like to have all those convenient references there as well. However, such references change our statement that "CWM is MOF compliant" to "CWM is MOF compliant when it's convenient". If I understand things correctly (and deferring to DonB on the fine technical points), the culprit is a MOF rule that says if the classes on either end of an association both have references, then both classes and the linking association must reside in the same EXTENT (note that this does not say "Package"; an extent is equivalent to a repository instance). So, if the association crosses an extent boundry, it can't have references on both ends. (The fact that ModelElement, Dependency, and the DependencyClient assocation are in the same package is immaterial -- it's the extent boundry that matters.) We have always acknowledged that in these cases you had to query the association, the class' reference. To want to have it both ways, while understandable, is "speaking with forked tongue". -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Monday, July 23, 2001 7:55 AM To: Pete Rivett Cc: 'Dan Chang'; 'Tolbert, Doug M'; cwm-rtf@omg.org; 'Baisley, Donald E'; 'Jing Chu' Subject: RE: Two errors on ModelElement - navigating without references Pete, Regarding your final comment: But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. The fact that you leverage reflection to resolve the navigation still doesn't change the fact that a mapped interface for ModelElement is not going to contain method calls supporting a supplierDependency reference. So I'm a little confused about your comment that "it's transparent to the user .... whether there is a stored reference in the metamodel or not". I think Dan's point is that, regardless of how tractible (or intractible) the problem of implementing a supplierDependency reference might be, the reference simply doesn't exist in the CWM 1.0 standard, hence there is no user transparency in this regard. There are a number of other places in the CWM 1.0 metamodel, by the way, where I've found a number of "asymmetrical" usages of references, some I think are intentional, some not. I will forward my complete list for comment shortly. Regards, John "Pete Rivett" on 07/21/2001 08:09:40 AM To: "'Dan Chang'" , "'Tolbert, Doug M'" cc: , "'Baisley, Donald E'" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references I agree with Dan's point about the need to have 2-way navigation of dependencies and also with the Doug's point about the need to facilitate federation. I believe both needs can be met with existing models and specifications and I describe this below. Obviously there remains an incompatibility between UML 1.3 and UML 1.4, but there was a reason for the change - as Doug described. To reprise, Dan's issue is the dropping of the supplierDependency reference from ModelElement to Dependency. Firstly I should say that the information will still be present in the XMI file - either through the Dependency element or through the Association/Link elements. Secondly when using APIs one does not have to use a reference to navigate an association: to get from a ModelElement to the Dependencies for which it is the supplier one can use the Association itself: For ModelElement, the IDL contains: DependencySet client_dependency () The equivalent for supplier can be gained by using DependencySet supplier_dependency (in ModelElement supplier) on interface: interface ASupplierSupplierDependency : Reflective::RefAssociation So for a ModelElement M, instead of calling: M.supplierDependency() one would call: A.supplier_dependency(M) Where A is obtained from the following attribute on the package extent: readonly attribute ASupplierSupplierDependency a_supplier_supplier_dependency_ref; It would thus be possible, for convenience, to define the equivalent of supplierDependency as a derived reference on ModelElement IF AND ONLY IF you knew which package extent(s) to use for querying the Association: it is precisely the lack of this knowledge in the general federated case that has led to dropping the reference from the standard UML metamodel. But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. Hope that helps, Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: 21 July 2001 00:18 > To: Tolbert, Doug M > Cc: cwm-rtf@omg.org; Baisley, Donald E; Jing Chu > Subject: RE: Two errors on ModelElement > > > > Doug, > > I do not agree with you on (1) for two reasons: > (a) This makes CWM 1.0 incompatible with the CWM Adapted > Specification for > no justifiable reason. > (b) ModelElement has a clientDependency reference to > Dependency. Dependency > has both client and server references to ModelElement. Why should one > (supplierDependency) out of the four references involved be > removed in CWM > 1.0? Please note that Dependency is always used with two > ModelElements; a > client and a supplier. > > (Embedded image moved to file: pic24993.pcx) > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > > > "Tolbert, Doug > > M" To: Dan > Chang/Santa Teresa/IBM@IBMUS > cwm-rtf@omg.org, Jing Chu/Santa Teresa/IBM@IBMUS, > nisys.com> "Baisley, Donald > E" > Subject: RE: > Two errors on ModelElement > 07/20/01 03:50 > > PM > > > > > > > > > Dan, > > You are right about (2), the taggedValue reference should be on > ModelElement. I think its absence is a hangover from some of the > repackaging efforts late in CWM 1.0. Why don't you start an > issue on the > OMG web page and we can add the fix in 1.1. (I can send you > an update cat > file as you requested for your use in the mean time). > > However, (1) is as designed. There are several places in CWM > where there > is > no reference on one side of an association. This is to > support distributed > metadata and is in compliance with MOF rules. The choice to > leave off the > reference on one end allows that end to be referenced from > other extents in > the same way, as for example, the type an attribute can occur in a > different > extent. In this case, it makes sense for a ModelElement to > see what it > depends on, but not for it to see what depends on it -- hence no > supplierDependency reference on ModelElement. > > Doug > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Friday, July 20, 2001 11:06 AM > To: Doug.Tolbert@unisys.com > Cc: cwm-rtf@omg.org; Jing Chu > Subject: Two errors on ModelElement > Importance: High > > > Doug, > > We just found two errors on ModelElement, which make CWM 1.0 > incompatible > with the CWM Adapted Specification. I hope you can make the > correction and > generate a new ObjectCore.cat asap, since this is affecting > our ability to > implement CWM 1.0. > (1) ModelElement is missing a "supplierDependency" reference > to Dependency. > (It has a clientDependency reference to Dependency, and > Dependency has both > client and supplier references to ModelElement.) > (2) ModelElement is missing a "taggedValue" reference to TaggedValue. > (ModelElement owns TaggedValue. StereoType also owns > TaggedValue and has a > requiredTag reference to TaggedValue.) > > Thanks in advance. > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. From: John_Poole@hyperion.com Subject: RE: Two errors on ModelElement - navigating without references To: "Tolbert, Doug M" Cc: Pete Rivett , "'Dan Chang'" , "Tolbert, Doug M" , cwm-rtf@omg.org, "Baisley, Donald E" , "'Jing Chu'" Date: Mon, 23 Jul 2001 12:59:38 -0400 Message-ID: X-MIMETrack: Serialize by Router on Stmfd-Gateway1/na/Hyperion(Release 5.0.5 |September 22, 2000) at 07/23/2001 12:59:39 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: aaRd99%f!!VB5e9(,D!! Doug, OK. I remember now (i.e., discussing this MOF rule before). So I guess my question is: In the various places in the CWM 1.0 metamodel where we've made "model distribution" assumptions, in very general terms, what served as the basis for such assumptions? (I'm not challenging anything; this is just for my own understanding). In other words, as a metamodeler, how does one know in advance where extent boundaries are likely to exist? Regards, John "Tolbert, Doug M" on 07/23/2001 12:34:53 PM To: John Poole/na/Hyperion@Hyperion, Pete Rivett cc: "'Dan Chang'" , "Tolbert, Doug M" , cwm-rtf@omg.org, "Baisley, Donald E" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references Gents, Well, I'd like to have all those convenient references there as well. However, such references change our statement that "CWM is MOF compliant" to "CWM is MOF compliant when it's convenient". If I understand things correctly (and deferring to DonB on the fine technical points), the culprit is a MOF rule that says if the classes on either end of an association both have references, then both classes and the linking association must reside in the same EXTENT (note that this does not say "Package"; an extent is equivalent to a repository instance). So, if the association crosses an extent boundry, it can't have references on both ends. (The fact that ModelElement, Dependency, and the DependencyClient assocation are in the same package is immaterial -- it's the extent boundry that matters.) We have always acknowledged that in these cases you had to query the association, the class' reference. To want to have it both ways, while understandable, is "speaking with forked tongue". -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Monday, July 23, 2001 7:55 AM To: Pete Rivett Cc: 'Dan Chang'; 'Tolbert, Doug M'; cwm-rtf@omg.org; 'Baisley, Donald E'; 'Jing Chu' Subject: RE: Two errors on ModelElement - navigating without references Pete, Regarding your final comment: But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. The fact that you leverage reflection to resolve the navigation still doesn't change the fact that a mapped interface for ModelElement is not going to contain method calls supporting a supplierDependency reference. So I'm a little confused about your comment that "it's transparent to the user .... whether there is a stored reference in the metamodel or not". I think Dan's point is that, regardless of how tractible (or intractible) the problem of implementing a supplierDependency reference might be, the reference simply doesn't exist in the CWM 1.0 standard, hence there is no user transparency in this regard. There are a number of other places in the CWM 1.0 metamodel, by the way, where I've found a number of "asymmetrical" usages of references, some I think are intentional, some not. I will forward my complete list for comment shortly. Regards, John "Pete Rivett" on 07/21/2001 08:09:40 AM To: "'Dan Chang'" , "'Tolbert, Doug M'" cc: , "'Baisley, Donald E'" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references I agree with Dan's point about the need to have 2-way navigation of dependencies and also with the Doug's point about the need to facilitate federation. I believe both needs can be met with existing models and specifications and I describe this below. Obviously there remains an incompatibility between UML 1.3 and UML 1.4, but there was a reason for the change - as Doug described. To reprise, Dan's issue is the dropping of the supplierDependency reference from ModelElement to Dependency. Firstly I should say that the information will still be present in the XMI file - either through the Dependency element or through the Association/Link elements. Secondly when using APIs one does not have to use a reference to navigate an association: to get from a ModelElement to the Dependencies for which it is the supplier one can use the Association itself: For ModelElement, the IDL contains: DependencySet client_dependency () The equivalent for supplier can be gained by using DependencySet supplier_dependency (in ModelElement supplier) on interface: interface ASupplierSupplierDependency : Reflective::RefAssociation So for a ModelElement M, instead of calling: M.supplierDependency() one would call: A.supplier_dependency(M) Where A is obtained from the following attribute on the package extent: readonly attribute ASupplierSupplierDependency a_supplier_supplier_dependency_ref; It would thus be possible, for convenience, to define the equivalent of supplierDependency as a derived reference on ModelElement IF AND ONLY IF you knew which package extent(s) to use for querying the Association: it is precisely the lack of this knowledge in the general federated case that has led to dropping the reference from the standard UML metamodel. But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. Hope that helps, Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: 21 July 2001 00:18 > To: Tolbert, Doug M > Cc: cwm-rtf@omg.org; Baisley, Donald E; Jing Chu > Subject: RE: Two errors on ModelElement > > > > Doug, > > I do not agree with you on (1) for two reasons: > (a) This makes CWM 1.0 incompatible with the CWM Adapted > Specification for > no justifiable reason. > (b) ModelElement has a clientDependency reference to > Dependency. Dependency > has both client and server references to ModelElement. Why should one > (supplierDependency) out of the four references involved be > removed in CWM > 1.0? Please note that Dependency is always used with two > ModelElements; a > client and a supplier. > > (Embedded image moved to file: pic24993.pcx) > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > > > "Tolbert, Doug > > M" To: Dan > Chang/Santa Teresa/IBM@IBMUS > cwm-rtf@omg.org, Jing Chu/Santa Teresa/IBM@IBMUS, > nisys.com> "Baisley, Donald > E" > Subject: RE: > Two errors on ModelElement > 07/20/01 03:50 > > PM > > > > > > > > > Dan, > > You are right about (2), the taggedValue reference should be on > ModelElement. I think its absence is a hangover from some of the > repackaging efforts late in CWM 1.0. Why don't you start an > issue on the > OMG web page and we can add the fix in 1.1. (I can send you > an update cat > file as you requested for your use in the mean time). > > However, (1) is as designed. There are several places in CWM > where there > is > no reference on one side of an association. This is to > support distributed > metadata and is in compliance with MOF rules. The choice to > leave off the > reference on one end allows that end to be referenced from > other extents in > the same way, as for example, the type an attribute can occur in a > different > extent. In this case, it makes sense for a ModelElement to > see what it > depends on, but not for it to see what depends on it -- hence no > supplierDependency reference on ModelElement. > > Doug > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Friday, July 20, 2001 11:06 AM > To: Doug.Tolbert@unisys.com > Cc: cwm-rtf@omg.org; Jing Chu > Subject: Two errors on ModelElement > Importance: High > > > Doug, > > We just found two errors on ModelElement, which make CWM 1.0 > incompatible > with the CWM Adapted Specification. I hope you can make the > correction and > generate a new ObjectCore.cat asap, since this is affecting > our ability to > implement CWM 1.0. > (1) ModelElement is missing a "supplierDependency" reference > to Dependency. > (It has a clientDependency reference to Dependency, and > Dependency has both > client and supplier references to ModelElement.) > (2) ModelElement is missing a "taggedValue" reference to TaggedValue. > (ModelElement owns TaggedValue. StereoType also owns > TaggedValue and has a > requiredTag reference to TaggedValue.) > > Thanks in advance. > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. Subject: RE: Two errors on ModelElement - navigating without references To: "Tolbert, Doug M" Cc: cwm-rtf@omg.org, "Baisley, Donald E" , "Tolbert, Doug M" , "'Jing Chu'" , John_Poole@hyperion.com, Pete Rivett X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Dan Chang" Date: Mon, 23 Jul 2001 10:32:57 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/23/2001 11:32:58 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: !PIe9C/E!!`f>e9~:E!! Doug, I am glad that you pointed out the difference between the MOF Package and the MOF Extent. I took a quick look at the MOF spec: Sections 3.2.1 and 4.9. As I understand it, and believe it should be, the MOF Extent deals with the creation of links (M1) and not the definition of references (M2). That is, there is nothing illegal, per MOF Extent consideration, to have the supplierDependency reference. Regards, Dan e-business Data Technology and Standard IBM Silicon Valley Laboratory Notes: Dan Chang/Santa Teresa/IBM@IBMUS Internet: dtchang@us.ibm.com VM: IBMUSM50(DTCHANG) Phone: (408)-463-2319 "Tolbert, Doug M" To: John_Poole@hyperion.com, Pete Rivett nisys.com> cc: Dan Chang/Santa Teresa/IBM@IBMUS, "Tolbert, Doug M" , cwm-rtf@omg.org, "Baisley, Donald 07/23/01 09:34 E" , Jing Chu/Santa AM Teresa/IBM@IBMUS Subject: RE: Two errors on ModelElement - navigating without references Gents, Well, I'd like to have all those convenient references there as well. However, such references change our statement that "CWM is MOF compliant" to "CWM is MOF compliant when it's convenient". If I understand things correctly (and deferring to DonB on the fine technical points), the culprit is a MOF rule that says if the classes on either end of an association both have references, then both classes and the linking association must reside in the same EXTENT (note that this does not say "Package"; an extent is equivalent to a repository instance). So, if the association crosses an extent boundry, it can't have references on both ends. (The fact that ModelElement, Dependency, and the DependencyClient assocation are in the same package is immaterial -- it's the extent boundry that matters.) We have always acknowledged that in these cases you had to query the association, the class' reference. To want to have it both ways, while understandable, is "speaking with forked tongue". -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Monday, July 23, 2001 7:55 AM To: Pete Rivett Cc: 'Dan Chang'; 'Tolbert, Doug M'; cwm-rtf@omg.org; 'Baisley, Donald E'; 'Jing Chu' Subject: RE: Two errors on ModelElement - navigating without references Pete, Regarding your final comment: But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. The fact that you leverage reflection to resolve the navigation still doesn't change the fact that a mapped interface for ModelElement is not going to contain method calls supporting a supplierDependency reference. So I'm a little confused about your comment that "it's transparent to the user .... whether there is a stored reference in the metamodel or not". I think Dan's point is that, regardless of how tractible (or intractible) the problem of implementing a supplierDependency reference might be, the reference simply doesn't exist in the CWM 1.0 standard, hence there is no user transparency in this regard. There are a number of other places in the CWM 1.0 metamodel, by the way, where I've found a number of "asymmetrical" usages of references, some I think are intentional, some not. I will forward my complete list for comment shortly. Regards, John "Pete Rivett" on 07/21/2001 08:09:40 AM To: "'Dan Chang'" , "'Tolbert, Doug M'" cc: , "'Baisley, Donald E'" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references I agree with Dan's point about the need to have 2-way navigation of dependencies and also with the Doug's point about the need to facilitate federation. I believe both needs can be met with existing models and specifications and I describe this below. Obviously there remains an incompatibility between UML 1.3 and UML 1.4, but there was a reason for the change - as Doug described. To reprise, Dan's issue is the dropping of the supplierDependency reference from ModelElement to Dependency. Firstly I should say that the information will still be present in the XMI file - either through the Dependency element or through the Association/Link elements. Secondly when using APIs one does not have to use a reference to navigate an association: to get from a ModelElement to the Dependencies for which it is the supplier one can use the Association itself: For ModelElement, the IDL contains: DependencySet client_dependency () The equivalent for supplier can be gained by using DependencySet supplier_dependency (in ModelElement supplier) on interface: interface ASupplierSupplierDependency : Reflective::RefAssociation So for a ModelElement M, instead of calling: M.supplierDependency() one would call: A.supplier_dependency(M) Where A is obtained from the following attribute on the package extent: readonly attribute ASupplierSupplierDependency a_supplier_supplier_dependency_ref; It would thus be possible, for convenience, to define the equivalent of supplierDependency as a derived reference on ModelElement IF AND ONLY IF you knew which package extent(s) to use for querying the Association: it is precisely the lack of this knowledge in the general federated case that has led to dropping the reference from the standard UML metamodel. But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. Hope that helps, Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: 21 July 2001 00:18 > To: Tolbert, Doug M > Cc: cwm-rtf@omg.org; Baisley, Donald E; Jing Chu > Subject: RE: Two errors on ModelElement > > > > Doug, > > I do not agree with you on (1) for two reasons: > (a) This makes CWM 1.0 incompatible with the CWM Adapted > Specification for > no justifiable reason. > (b) ModelElement has a clientDependency reference to > Dependency. Dependency > has both client and server references to ModelElement. Why should one > (supplierDependency) out of the four references involved be > removed in CWM > 1.0? Please note that Dependency is always used with two > ModelElements; a > client and a supplier. > > (Embedded image moved to file: pic24993.pcx) > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > > > "Tolbert, Doug > > M" To: Dan > Chang/Santa Teresa/IBM@IBMUS > cwm-rtf@omg.org, Jing Chu/Santa Teresa/IBM@IBMUS, > nisys.com> "Baisley, Donald > E" > Subject: RE: > Two errors on ModelElement > 07/20/01 03:50 > > PM > > > > > > > > > Dan, > > You are right about (2), the taggedValue reference should be on > ModelElement. I think its absence is a hangover from some of the > repackaging efforts late in CWM 1.0. Why don't you start an > issue on the > OMG web page and we can add the fix in 1.1. (I can send you > an update cat > file as you requested for your use in the mean time). > > However, (1) is as designed. There are several places in CWM > where there > is > no reference on one side of an association. This is to > support distributed > metadata and is in compliance with MOF rules. The choice to > leave off the > reference on one end allows that end to be referenced from > other extents in > the same way, as for example, the type an attribute can occur in a > different > extent. In this case, it makes sense for a ModelElement to > see what it > depends on, but not for it to see what depends on it -- hence no > supplierDependency reference on ModelElement. > > Doug > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Friday, July 20, 2001 11:06 AM > To: Doug.Tolbert@unisys.com > Cc: cwm-rtf@omg.org; Jing Chu > Subject: Two errors on ModelElement > Importance: High > > > Doug, > > We just found two errors on ModelElement, which make CWM 1.0 > incompatible > with the CWM Adapted Specification. I hope you can make the > correction and > generate a new ObjectCore.cat asap, since this is affecting > our ability to > implement CWM 1.0. > (1) ModelElement is missing a "supplierDependency" reference > to Dependency. > (It has a clientDependency reference to Dependency, and > Dependency has both > client and supplier references to ModelElement.) > (2) ModelElement is missing a "taggedValue" reference to TaggedValue. > (ModelElement owns TaggedValue. StereoType also owns > TaggedValue and has a > requiredTag reference to TaggedValue.) > > Thanks in advance. > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. Subject: RE: Two errors on ModelElement - navigating without references To: John_Poole@hyperion.com Cc: cwm-rtf@omg.org, "Baisley, Donald E" , "Tolbert, Doug M" , "'Jing Chu'" , Pete Rivett X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Dan Chang" Date: Mon, 23 Jul 2001 10:45:20 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/23/2001 11:45:21 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: ZSU!!kH7!!i`cd9Yl5!! John, Per my earlier note, I don't believe the MOF Extent consideration has any bearing on metamodeling. The MOF Extent is a M!, implementation consideration. Therefore, as a metamodeler, we don't need to worry about the MOF Extent. Otherwise, the CWM spec would have to define all the "expected" MOF Extents. Regards, Dan e-business Data Technology and Standard IBM Silicon Valley Laboratory Notes: Dan Chang/Santa Teresa/IBM@IBMUS Internet: dtchang@us.ibm.com VM: IBMUSM50(DTCHANG) Phone: (408)-463-2319 John_Poole@hyp erion.com To: "Tolbert, Doug M" cc: Pete Rivett , Dan Chang/Santa 07/23/01 09:59 Teresa/IBM@IBMUS, "Tolbert, Doug M" , AM cwm-rtf@omg.org, "Baisley, Donald E" , Jing Chu/Santa Teresa/IBM@IBMUS Subject: RE: Two errors on ModelElement - navigating without references Doug, OK. I remember now (i.e., discussing this MOF rule before). So I guess my question is: In the various places in the CWM 1.0 metamodel where we've made "model distribution" assumptions, in very general terms, what served as the basis for such assumptions? (I'm not challenging anything; this is just for my own understanding). In other words, as a metamodeler, how does one know in advance where extent boundaries are likely to exist? Regards, John "Tolbert, Doug M" on 07/23/2001 12:34:53 PM To: John Poole/na/Hyperion@Hyperion, Pete Rivett cc: "'Dan Chang'" , "Tolbert, Doug M" , cwm-rtf@omg.org, "Baisley, Donald E" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references Gents, Well, I'd like to have all those convenient references there as well. However, such references change our statement that "CWM is MOF compliant" to "CWM is MOF compliant when it's convenient". If I understand things correctly (and deferring to DonB on the fine technical points), the culprit is a MOF rule that says if the classes on either end of an association both have references, then both classes and the linking association must reside in the same EXTENT (note that this does not say "Package"; an extent is equivalent to a repository instance). So, if the association crosses an extent boundry, it can't have references on both ends. (The fact that ModelElement, Dependency, and the DependencyClient assocation are in the same package is immaterial -- it's the extent boundry that matters.) We have always acknowledged that in these cases you had to query the association, the class' reference. To want to have it both ways, while understandable, is "speaking with forked tongue". -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Monday, July 23, 2001 7:55 AM To: Pete Rivett Cc: 'Dan Chang'; 'Tolbert, Doug M'; cwm-rtf@omg.org; 'Baisley, Donald E'; 'Jing Chu' Subject: RE: Two errors on ModelElement - navigating without references Pete, Regarding your final comment: But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. The fact that you leverage reflection to resolve the navigation still doesn't change the fact that a mapped interface for ModelElement is not going to contain method calls supporting a supplierDependency reference. So I'm a little confused about your comment that "it's transparent to the user .... whether there is a stored reference in the metamodel or not". I think Dan's point is that, regardless of how tractible (or intractible) the problem of implementing a supplierDependency reference might be, the reference simply doesn't exist in the CWM 1.0 standard, hence there is no user transparency in this regard. There are a number of other places in the CWM 1.0 metamodel, by the way, where I've found a number of "asymmetrical" usages of references, some I think are intentional, some not. I will forward my complete list for comment shortly. Regards, John "Pete Rivett" on 07/21/2001 08:09:40 AM To: "'Dan Chang'" , "'Tolbert, Doug M'" cc: , "'Baisley, Donald E'" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references I agree with Dan's point about the need to have 2-way navigation of dependencies and also with the Doug's point about the need to facilitate federation. I believe both needs can be met with existing models and specifications and I describe this below. Obviously there remains an incompatibility between UML 1.3 and UML 1.4, but there was a reason for the change - as Doug described. To reprise, Dan's issue is the dropping of the supplierDependency reference from ModelElement to Dependency. Firstly I should say that the information will still be present in the XMI file - either through the Dependency element or through the Association/Link elements. Secondly when using APIs one does not have to use a reference to navigate an association: to get from a ModelElement to the Dependencies for which it is the supplier one can use the Association itself: For ModelElement, the IDL contains: DependencySet client_dependency () The equivalent for supplier can be gained by using DependencySet supplier_dependency (in ModelElement supplier) on interface: interface ASupplierSupplierDependency : Reflective::RefAssociation So for a ModelElement M, instead of calling: M.supplierDependency() one would call: A.supplier_dependency(M) Where A is obtained from the following attribute on the package extent: readonly attribute ASupplierSupplierDependency a_supplier_supplier_dependency_ref; It would thus be possible, for convenience, to define the equivalent of supplierDependency as a derived reference on ModelElement IF AND ONLY IF you knew which package extent(s) to use for querying the Association: it is precisely the lack of this knowledge in the general federated case that has led to dropping the reference from the standard UML metamodel. But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. Hope that helps, Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: 21 July 2001 00:18 > To: Tolbert, Doug M > Cc: cwm-rtf@omg.org; Baisley, Donald E; Jing Chu > Subject: RE: Two errors on ModelElement > > > > Doug, > > I do not agree with you on (1) for two reasons: > (a) This makes CWM 1.0 incompatible with the CWM Adapted > Specification for > no justifiable reason. > (b) ModelElement has a clientDependency reference to > Dependency. Dependency > has both client and server references to ModelElement. Why should one > (supplierDependency) out of the four references involved be > removed in CWM > 1.0? Please note that Dependency is always used with two > ModelElements; a > client and a supplier. > > (Embedded image moved to file: pic24993.pcx) > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > > > "Tolbert, Doug > > M" To: Dan > Chang/Santa Teresa/IBM@IBMUS > cwm-rtf@omg.org, Jing Chu/Santa Teresa/IBM@IBMUS, > nisys.com> "Baisley, Donald > E" > Subject: RE: > Two errors on ModelElement > 07/20/01 03:50 > > PM > > > > > > > > > Dan, > > You are right about (2), the taggedValue reference should be on > ModelElement. I think its absence is a hangover from some of the > repackaging efforts late in CWM 1.0. Why don't you start an > issue on the > OMG web page and we can add the fix in 1.1. (I can send you > an update cat > file as you requested for your use in the mean time). > > However, (1) is as designed. There are several places in CWM > where there > is > no reference on one side of an association. This is to > support distributed > metadata and is in compliance with MOF rules. The choice to > leave off the > reference on one end allows that end to be referenced from > other extents in > the same way, as for example, the type an attribute can occur in a > different > extent. In this case, it makes sense for a ModelElement to > see what it > depends on, but not for it to see what depends on it -- hence no > supplierDependency reference on ModelElement. > > Doug > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Friday, July 20, 2001 11:06 AM > To: Doug.Tolbert@unisys.com > Cc: cwm-rtf@omg.org; Jing Chu > Subject: Two errors on ModelElement > Importance: High > > > Doug, > > We just found two errors on ModelElement, which make CWM 1.0 > incompatible > with the CWM Adapted Specification. I hope you can make the > correction and > generate a new ObjectCore.cat asap, since this is affecting > our ability to > implement CWM 1.0. > (1) ModelElement is missing a "supplierDependency" reference > to Dependency. > (It has a clientDependency reference to Dependency, and > Dependency has both > client and supplier references to ModelElement.) > (2) ModelElement is missing a "taggedValue" reference to TaggedValue. > (ModelElement owns TaggedValue. StereoType also owns > TaggedValue and has a > requiredTag reference to TaggedValue.) > > Thanks in advance. > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. From: "Pete Rivett" To: Cc: "'Dan Chang'" , "'Tolbert, Doug M'" , , "'Baisley, Donald E'" , "'Stephen Crawley'" Subject: RE: Two errors on ModelElement - navigating without references Date: Mon, 23 Jul 2001 18:36:55 +0100 Message-ID: <002301c1139e$12179360$114c04c8@CHIMAY> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Content-Type: text/plain; charset="us-ascii" X-UIDL: D(:e9j]c!!5R8!!R;!e9 John, Sorry for the confusion: the transparency I referred to is for users (programmers or interactive) of the Adaptive software layer I described, which supplements MOF. As a general point, maybe what's missing is a MOF Facility specification that uses the 'confederation' concept I described to provide the handle to the external Extents whose associations can be interrogated to find any inverse links. I can see the need for different implementation options including a simple tool that does no federation at all. Steve Crawley made a proposal for an improved MOF Facility to the MOF-RTF (see http://www.dstc.edu.au/Research/Projects/MOF/rtf1.4/MOFRepos.pdf) but the area has been deferred to MOF 2.0. Steve's proposal included various types of Facility but not the above support for references - but this is something I'm aiming to include in the MOF 2.0 RFP. Pete > -----Original Message----- > From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] > Sent: 23 July 2001 15:55 > To: Pete Rivett > Cc: 'Dan Chang'; 'Tolbert, Doug M'; cwm-rtf@omg.org; 'Baisley, Donald > E'; 'Jing Chu' > Subject: RE: Two errors on ModelElement - navigating without > references > > > > > Pete, > > Regarding your final comment: > > But if in the context of a specific application you can > reliably know the > package extents of interest you can implement this yourself. > This is in fact what Adaptive has done as part of its > Adaptive Repository > product: we will allow the definition of 'confederations' of package > extents for particular purposes and we use these to resolve such > navigations > (at the reflective level) so that it's transparent to the > user working in > the scope of a confederation whether there is a stored > reference in the > metamodel or not. > > The fact that you leverage reflection to resolve the navigation still > doesn't change the fact that a mapped interface for > ModelElement is not going to contain method calls supporting a > supplierDependency reference. So I'm a little confused > about your comment that "it's transparent to the user .... > whether there is > a stored reference in the metamodel or not". > > I think Dan's point is that, regardless of how tractible (or > intractible) > the problem of implementing a supplierDependency > reference might be, the reference simply doesn't exist in the CWM 1.0 > standard, hence there is no user transparency in > this regard. > > There are a number of other places in the CWM 1.0 metamodel, > by the way, > where I've found a number of "asymmetrical" usages of > references, some I think are intentional, some not. I will forward my > complete list for comment shortly. > > Regards, > John > > > > > > > "Pete Rivett" on 07/21/2001 08:09:40 AM > > To: "'Dan Chang'" , "'Tolbert, Doug M'" > > cc: , "'Baisley, Donald E'" > , > "'Jing Chu'" > Subject: RE: Two errors on ModelElement - navigating without > references > > > I agree with Dan's point about the need to have 2-way navigation of > dependencies and also with the Doug's point about the need to > facilitate > federation. I believe both needs can be met with existing models and > specifications and I describe this below. Obviously there remains an > incompatibility between UML 1.3 and UML 1.4, but there was a > reason for the > change - as Doug described. > > To reprise, Dan's issue is the dropping of the > supplierDependency reference > from ModelElement to Dependency. > > Firstly I should say that the information will still be > present in the XMI > file - either through the Dependency element or through the > Association/Link > elements. > > Secondly when using APIs one does not have to use a reference > to navigate > an > association: to get from a ModelElement to the Dependencies > for which it is > the supplier one can use the Association itself: > > For ModelElement, the IDL contains: > DependencySet client_dependency () > The equivalent for supplier can be gained by using > DependencySet supplier_dependency (in ModelElement supplier) > on interface: > interface ASupplierSupplierDependency : Reflective::RefAssociation > > So for a ModelElement M, instead of calling: > M.supplierDependency() > one would call: > A.supplier_dependency(M) > Where A is obtained from the following attribute on the > package extent: > readonly attribute ASupplierSupplierDependency > a_supplier_supplier_dependency_ref; > > It would thus be possible, for convenience, to define the > equivalent of > supplierDependency as a derived reference on ModelElement IF > AND ONLY IF > you > knew which package extent(s) to use for querying the > Association: it is > precisely the lack of this knowledge in the general federated > case that has > led to dropping the reference from the standard UML metamodel. > But if in the context of a specific application you can > reliably know the > package extents of interest you can implement this yourself. > This is in fact what Adaptive has done as part of its > Adaptive Repository > product: we will allow the definition of 'confederations' of package > extents for particular purposes and we use these to resolve such > navigations > (at the reflective level) so that it's transparent to the > user working in > the scope of a confederation whether there is a stored > reference in the > metamodel or not. > > Hope that helps, > Pete > > Pete Rivett (pete.rivett@adaptive.com) > Chief Technology Officer, Adaptive Ltd > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > -----Original Message----- > > From: Dan Chang [mailto:dtchang@us.ibm.com] > > Sent: 21 July 2001 00:18 > > To: Tolbert, Doug M > > Cc: cwm-rtf@omg.org; Baisley, Donald E; Jing Chu > > Subject: RE: Two errors on ModelElement > > > > > > > > Doug, > > > > I do not agree with you on (1) for two reasons: > > (a) This makes CWM 1.0 incompatible with the CWM Adapted > > Specification for > > no justifiable reason. > > (b) ModelElement has a clientDependency reference to > > Dependency. Dependency > > has both client and server references to ModelElement. Why > should one > > (supplierDependency) out of the four references involved be > > removed in CWM > > 1.0? Please note that Dependency is always used with two > > ModelElements; a > > client and a supplier. > > > > (Embedded image moved to file: pic24993.pcx) > > > > Regards, Dan > > > > e-business Data Technology and Standard > > IBM Silicon Valley Laboratory > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > Internet: dtchang@us.ibm.com > > VM: IBMUSM50(DTCHANG) > > Phone: (408)-463-2319 > > > > > > > > > > "Tolbert, Doug > > > > M" To: Dan > > Chang/Santa Teresa/IBM@IBMUS > > > cwm-rtf@omg.org, Jing Chu/Santa Teresa/IBM@IBMUS, > > nisys.com> "Baisley, Donald > > E" > > Subject: RE: > > Two errors on ModelElement > > 07/20/01 03:50 > > > > PM > > > > > > > > > > > > > > > > > > Dan, > > > > You are right about (2), the taggedValue reference should be on > > ModelElement. I think its absence is a hangover from some of the > > repackaging efforts late in CWM 1.0. Why don't you start an > > issue on the > > OMG web page and we can add the fix in 1.1. (I can send you > > an update cat > > file as you requested for your use in the mean time). > > > > However, (1) is as designed. There are several places in CWM > > where there > > is > > no reference on one side of an association. This is to > > support distributed > > metadata and is in compliance with MOF rules. The choice to > > leave off the > > reference on one end allows that end to be referenced from > > other extents in > > the same way, as for example, the type an attribute can occur in a > > different > > extent. In this case, it makes sense for a ModelElement to > > see what it > > depends on, but not for it to see what depends on it -- hence no > > supplierDependency reference on ModelElement. > > > > Doug > > > > -----Original Message----- > > From: Dan Chang [mailto:dtchang@us.ibm.com] > > Sent: Friday, July 20, 2001 11:06 AM > > To: Doug.Tolbert@unisys.com > > Cc: cwm-rtf@omg.org; Jing Chu > > Subject: Two errors on ModelElement > > Importance: High > > > > > > Doug, > > > > We just found two errors on ModelElement, which make CWM 1.0 > > incompatible > > with the CWM Adapted Specification. I hope you can make the > > correction and > > generate a new ObjectCore.cat asap, since this is affecting > > our ability to > > implement CWM 1.0. > > (1) ModelElement is missing a "supplierDependency" reference > > to Dependency. > > (It has a clientDependency reference to Dependency, and > > Dependency has both > > client and supplier references to ModelElement.) > > (2) ModelElement is missing a "taggedValue" reference to > TaggedValue. > > (ModelElement owns TaggedValue. StereoType also owns > > TaggedValue and has a > > requiredTag reference to TaggedValue.) > > > > Thanks in advance. > > > > Regards, Dan > > > > e-business Data Technology and Standard > > IBM Silicon Valley Laboratory > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > Internet: dtchang@us.ibm.com > > VM: IBMUSM50(DTCHANG) > > Phone: (408)-463-2319 > > > > > > > > > The information contained in this email and any attached files are > confidential and intended solely for the addressee(s). The > e-mail may be > legally privileged or prohibited from disclosure and unauthorised use. > If you are not the named addressee you may not use, copy or > disclose this > information to any other person. If you received this > message in error > please notify the sender immediately. > Any views or opinions presented here may be solely those of > the originator > and do not necessarily reflect those of the Company. > > > > > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. From: "Tolbert, Doug M" To: Dan Chang , "Tolbert, Doug M" Cc: cwm-rtf@omg.org, "Baisley, Donald E" , "Tolbert, Doug M" , "'Jing Chu'" , John_Poole@hyperion.com, Pete Rivett Subject: RE: Two errors on ModelElement - navigating without references Date: Mon, 23 Jul 2001 12:52:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: VSd!!`GC!!Qd8e9VSld9 But a declared reference at M2 needs to be populated for M1 objects. How would you do that? This way the MOF exists in the first place, I suspect. Based on my discussion with him, DonB seems to disagree with you conclusion as well, but I will let him offer his own reasons. Don? Doug -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Monday, July 23, 2001 10:33 AM To: Tolbert, Doug M Cc: cwm-rtf@omg.org; Baisley, Donald E; Tolbert, Doug M; 'Jing Chu'; John_Poole@hyperion.com; Pete Rivett Subject: RE: Two errors on ModelElement - navigating without references Doug, I am glad that you pointed out the difference between the MOF Package and the MOF Extent. I took a quick look at the MOF spec: Sections 3.2.1 and 4.9. As I understand it, and believe it should be, the MOF Extent deals with the creation of links (M1) and not the definition of references (M2). That is, there is nothing illegal, per MOF Extent consideration, to have the supplierDependency reference. Regards, Dan e-business Data Technology and Standard IBM Silicon Valley Laboratory Notes: Dan Chang/Santa Teresa/IBM@IBMUS Internet: dtchang@us.ibm.com VM: IBMUSM50(DTCHANG) Phone: (408)-463-2319 "Tolbert, Doug M" To: John_Poole@hyperion.com, Pete Rivett nisys.com> cc: Dan Chang/Santa Teresa/IBM@IBMUS, "Tolbert, Doug M" , cwm-rtf@omg.org, "Baisley, Donald 07/23/01 09:34 E" , Jing Chu/Santa AM Teresa/IBM@IBMUS Subject: RE: Two errors on ModelElement - navigating without references Gents, Well, I'd like to have all those convenient references there as well. However, such references change our statement that "CWM is MOF compliant" to "CWM is MOF compliant when it's convenient". If I understand things correctly (and deferring to DonB on the fine technical points), the culprit is a MOF rule that says if the classes on either end of an association both have references, then both classes and the linking association must reside in the same EXTENT (note that this does not say "Package"; an extent is equivalent to a repository instance). So, if the association crosses an extent boundry, it can't have references on both ends. (The fact that ModelElement, Dependency, and the DependencyClient assocation are in the same package is immaterial -- it's the extent boundry that matters.) We have always acknowledged that in these cases you had to query the association, the class' reference. To want to have it both ways, while understandable, is "speaking with forked tongue". -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Monday, July 23, 2001 7:55 AM To: Pete Rivett Cc: 'Dan Chang'; 'Tolbert, Doug M'; cwm-rtf@omg.org; 'Baisley, Donald E'; 'Jing Chu' Subject: RE: Two errors on ModelElement - navigating without references Pete, Regarding your final comment: But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. The fact that you leverage reflection to resolve the navigation still doesn't change the fact that a mapped interface for ModelElement is not going to contain method calls supporting a supplierDependency reference. So I'm a little confused about your comment that "it's transparent to the user .... whether there is a stored reference in the metamodel or not". I think Dan's point is that, regardless of how tractible (or intractible) the problem of implementing a supplierDependency reference might be, the reference simply doesn't exist in the CWM 1.0 standard, hence there is no user transparency in this regard. There are a number of other places in the CWM 1.0 metamodel, by the way, where I've found a number of "asymmetrical" usages of references, some I think are intentional, some not. I will forward my complete list for comment shortly. Regards, John "Pete Rivett" on 07/21/2001 08:09:40 AM To: "'Dan Chang'" , "'Tolbert, Doug M'" cc: , "'Baisley, Donald E'" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references I agree with Dan's point about the need to have 2-way navigation of dependencies and also with the Doug's point about the need to facilitate federation. I believe both needs can be met with existing models and specifications and I describe this below. Obviously there remains an incompatibility between UML 1.3 and UML 1.4, but there was a reason for the change - as Doug described. To reprise, Dan's issue is the dropping of the supplierDependency reference from ModelElement to Dependency. Firstly I should say that the information will still be present in the XMI file - either through the Dependency element or through the Association/Link elements. Secondly when using APIs one does not have to use a reference to navigate an association: to get from a ModelElement to the Dependencies for which it is the supplier one can use the Association itself: For ModelElement, the IDL contains: DependencySet client_dependency () The equivalent for supplier can be gained by using DependencySet supplier_dependency (in ModelElement supplier) on interface: interface ASupplierSupplierDependency : Reflective::RefAssociation So for a ModelElement M, instead of calling: M.supplierDependency() one would call: A.supplier_dependency(M) Where A is obtained from the following attribute on the package extent: readonly attribute ASupplierSupplierDependency a_supplier_supplier_dependency_ref; It would thus be possible, for convenience, to define the equivalent of supplierDependency as a derived reference on ModelElement IF AND ONLY IF you knew which package extent(s) to use for querying the Association: it is precisely the lack of this knowledge in the general federated case that has led to dropping the reference from the standard UML metamodel. But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. Hope that helps, Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: 21 July 2001 00:18 > To: Tolbert, Doug M > Cc: cwm-rtf@omg.org; Baisley, Donald E; Jing Chu > Subject: RE: Two errors on ModelElement > > > > Doug, > > I do not agree with you on (1) for two reasons: > (a) This makes CWM 1.0 incompatible with the CWM Adapted > Specification for > no justifiable reason. > (b) ModelElement has a clientDependency reference to > Dependency. Dependency > has both client and server references to ModelElement. Why should one > (supplierDependency) out of the four references involved be > removed in CWM > 1.0? Please note that Dependency is always used with two > ModelElements; a > client and a supplier. > > (Embedded image moved to file: pic24993.pcx) > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > > > "Tolbert, Doug > > M" To: Dan > Chang/Santa Teresa/IBM@IBMUS > cwm-rtf@omg.org, Jing Chu/Santa Teresa/IBM@IBMUS, > nisys.com> "Baisley, Donald > E" > Subject: RE: > Two errors on ModelElement > 07/20/01 03:50 > > PM > > > > > > > > > Dan, > > You are right about (2), the taggedValue reference should be on > ModelElement. I think its absence is a hangover from some of the > repackaging efforts late in CWM 1.0. Why don't you start an > issue on the > OMG web page and we can add the fix in 1.1. (I can send you > an update cat > file as you requested for your use in the mean time). > > However, (1) is as designed. There are several places in CWM > where there > is > no reference on one side of an association. This is to > support distributed > metadata and is in compliance with MOF rules. The choice to > leave off the > reference on one end allows that end to be referenced from > other extents in > the same way, as for example, the type an attribute can occur in a > different > extent. In this case, it makes sense for a ModelElement to > see what it > depends on, but not for it to see what depends on it -- hence no > supplierDependency reference on ModelElement. > > Doug > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Friday, July 20, 2001 11:06 AM > To: Doug.Tolbert@unisys.com > Cc: cwm-rtf@omg.org; Jing Chu > Subject: Two errors on ModelElement > Importance: High > > > Doug, > > We just found two errors on ModelElement, which make CWM 1.0 > incompatible > with the CWM Adapted Specification. I hope you can make the > correction and > generate a new ObjectCore.cat asap, since this is affecting > our ability to > implement CWM 1.0. > (1) ModelElement is missing a "supplierDependency" reference > to Dependency. > (It has a clientDependency reference to Dependency, and > Dependency has both > client and supplier references to ModelElement.) > (2) ModelElement is missing a "taggedValue" reference to TaggedValue. > (ModelElement owns TaggedValue. StereoType also owns > TaggedValue and has a > requiredTag reference to TaggedValue.) > > Thanks in advance. > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. From: "Tolbert, Doug M" To: John_Poole@hyperion.com, "Tolbert, Doug M" Cc: Pete Rivett , "'Dan Chang'" , "Tolbert, Doug M" , cwm-rtf@omg.org, "Baisley, Donald E" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references Date: Mon, 23 Jul 2001 12:56:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: U5h!!i[Pd9Z]9!!a,ld9 There may be a specific set of criteria but I don't think it's been universally applied (btw, I suspect this lack of universality exists in UML as well). But the rule seems to have been applied at least in the instances where the cross-extent problem is glaringly obvious (like the StructuralFeatureType association) and someone has cared enough to complain about the dueling references. Doug -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Monday, July 23, 2001 10:00 AM To: Tolbert, Doug M Cc: Pete Rivett; 'Dan Chang'; Tolbert, Doug M; cwm-rtf@omg.org; Baisley, Donald E; 'Jing Chu' Subject: RE: Two errors on ModelElement - navigating without references Doug, OK. I remember now (i.e., discussing this MOF rule before). So I guess my question is: In the various places in the CWM 1.0 metamodel where we've made "model distribution" assumptions, in very general terms, what served as the basis for such assumptions? (I'm not challenging anything; this is just for my own understanding). In other words, as a metamodeler, how does one know in advance where extent boundaries are likely to exist? Regards, John "Tolbert, Doug M" on 07/23/2001 12:34:53 PM To: John Poole/na/Hyperion@Hyperion, Pete Rivett cc: "'Dan Chang'" , "Tolbert, Doug M" , cwm-rtf@omg.org, "Baisley, Donald E" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references Gents, Well, I'd like to have all those convenient references there as well. However, such references change our statement that "CWM is MOF compliant" to "CWM is MOF compliant when it's convenient". If I understand things correctly (and deferring to DonB on the fine technical points), the culprit is a MOF rule that says if the classes on either end of an association both have references, then both classes and the linking association must reside in the same EXTENT (note that this does not say "Package"; an extent is equivalent to a repository instance). So, if the association crosses an extent boundry, it can't have references on both ends. (The fact that ModelElement, Dependency, and the DependencyClient assocation are in the same package is immaterial -- it's the extent boundry that matters.) We have always acknowledged that in these cases you had to query the association, the class' reference. To want to have it both ways, while understandable, is "speaking with forked tongue". -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Monday, July 23, 2001 7:55 AM To: Pete Rivett Cc: 'Dan Chang'; 'Tolbert, Doug M'; cwm-rtf@omg.org; 'Baisley, Donald E'; 'Jing Chu' Subject: RE: Two errors on ModelElement - navigating without references Pete, Regarding your final comment: But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. The fact that you leverage reflection to resolve the navigation still doesn't change the fact that a mapped interface for ModelElement is not going to contain method calls supporting a supplierDependency reference. So I'm a little confused about your comment that "it's transparent to the user .... whether there is a stored reference in the metamodel or not". I think Dan's point is that, regardless of how tractible (or intractible) the problem of implementing a supplierDependency reference might be, the reference simply doesn't exist in the CWM 1.0 standard, hence there is no user transparency in this regard. There are a number of other places in the CWM 1.0 metamodel, by the way, where I've found a number of "asymmetrical" usages of references, some I think are intentional, some not. I will forward my complete list for comment shortly. Regards, John "Pete Rivett" on 07/21/2001 08:09:40 AM To: "'Dan Chang'" , "'Tolbert, Doug M'" cc: , "'Baisley, Donald E'" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references I agree with Dan's point about the need to have 2-way navigation of dependencies and also with the Doug's point about the need to facilitate federation. I believe both needs can be met with existing models and specifications and I describe this below. Obviously there remains an incompatibility between UML 1.3 and UML 1.4, but there was a reason for the change - as Doug described. To reprise, Dan's issue is the dropping of the supplierDependency reference from ModelElement to Dependency. Firstly I should say that the information will still be present in the XMI file - either through the Dependency element or through the Association/Link elements. Secondly when using APIs one does not have to use a reference to navigate an association: to get from a ModelElement to the Dependencies for which it is the supplier one can use the Association itself: For ModelElement, the IDL contains: DependencySet client_dependency () The equivalent for supplier can be gained by using DependencySet supplier_dependency (in ModelElement supplier) on interface: interface ASupplierSupplierDependency : Reflective::RefAssociation So for a ModelElement M, instead of calling: M.supplierDependency() one would call: A.supplier_dependency(M) Where A is obtained from the following attribute on the package extent: readonly attribute ASupplierSupplierDependency a_supplier_supplier_dependency_ref; It would thus be possible, for convenience, to define the equivalent of supplierDependency as a derived reference on ModelElement IF AND ONLY IF you knew which package extent(s) to use for querying the Association: it is precisely the lack of this knowledge in the general federated case that has led to dropping the reference from the standard UML metamodel. But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. Hope that helps, Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: 21 July 2001 00:18 > To: Tolbert, Doug M > Cc: cwm-rtf@omg.org; Baisley, Donald E; Jing Chu > Subject: RE: Two errors on ModelElement > > > > Doug, > > I do not agree with you on (1) for two reasons: > (a) This makes CWM 1.0 incompatible with the CWM Adapted > Specification for > no justifiable reason. > (b) ModelElement has a clientDependency reference to > Dependency. Dependency > has both client and server references to ModelElement. Why should one > (supplierDependency) out of the four references involved be > removed in CWM > 1.0? Please note that Dependency is always used with two > ModelElements; a > client and a supplier. > > (Embedded image moved to file: pic24993.pcx) > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > > > "Tolbert, Doug > > M" To: Dan > Chang/Santa Teresa/IBM@IBMUS > cwm-rtf@omg.org, Jing Chu/Santa Teresa/IBM@IBMUS, > nisys.com> "Baisley, Donald > E" > Subject: RE: > Two errors on ModelElement > 07/20/01 03:50 > > PM > > > > > > > > > Dan, > > You are right about (2), the taggedValue reference should be on > ModelElement. I think its absence is a hangover from some of the > repackaging efforts late in CWM 1.0. Why don't you start an > issue on the > OMG web page and we can add the fix in 1.1. (I can send you > an update cat > file as you requested for your use in the mean time). > > However, (1) is as designed. There are several places in CWM > where there > is > no reference on one side of an association. This is to > support distributed > metadata and is in compliance with MOF rules. The choice to > leave off the > reference on one end allows that end to be referenced from > other extents in > the same way, as for example, the type an attribute can occur in a > different > extent. In this case, it makes sense for a ModelElement to > see what it > depends on, but not for it to see what depends on it -- hence no > supplierDependency reference on ModelElement. > > Doug > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Friday, July 20, 2001 11:06 AM > To: Doug.Tolbert@unisys.com > Cc: cwm-rtf@omg.org; Jing Chu > Subject: Two errors on ModelElement > Importance: High > > > Doug, > > We just found two errors on ModelElement, which make CWM 1.0 > incompatible > with the CWM Adapted Specification. I hope you can make the > correction and > generate a new ObjectCore.cat asap, since this is affecting > our ability to > implement CWM 1.0. > (1) ModelElement is missing a "supplierDependency" reference > to Dependency. > (It has a clientDependency reference to Dependency, and > Dependency has both > client and supplier references to ModelElement.) > (2) ModelElement is missing a "taggedValue" reference to TaggedValue. > (ModelElement owns TaggedValue. StereoType also owns > TaggedValue and has a > requiredTag reference to TaggedValue.) > > Thanks in advance. > > Regards, Dan > > e-business Data Technology and Standard > IBM Silicon Valley Laboratory > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > Internet: dtchang@us.ibm.com > VM: IBMUSM50(DTCHANG) > Phone: (408)-463-2319 > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. Subject: RE: Two errors on ModelElement - navigating without references To: "Tolbert, Doug M" Cc: cwm-rtf@omg.org, "Baisley, Donald E" , "Tolbert, Doug M" , "Jing Chu" , John_Poole@hyperion.com, Pete Rivett X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Dan Chang" Date: Mon, 23 Jul 2001 12:19:29 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/23/2001 01:19:31 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: 95hd9ed9e9jT8e9'nZd9 Doug, I don't think the fact that there is no reference from Classifer to StructuralFeature has to do with cross-extent consideration, since there is a reference (type) from StructuralFeature to Classifier. Regards, Dan e-business Data Technology and Standard IBM Silicon Valley Laboratory Notes: Dan Chang/Santa Teresa/IBM@IBMUS Internet: dtchang@us.ibm.com VM: IBMUSM50(DTCHANG) Phone: (408)-463-2319 "Tolbert, Doug M" To: John_Poole@hyperion.com, "Tolbert, Doug M" nisys.com> cc: Pete Rivett , Dan Chang/Santa Teresa/IBM@IBMUS, "Tolbert, Doug M" , 07/23/01 10:56 cwm-rtf@omg.org, "Baisley, Donald E" AM , Jing Chu/Santa Teresa/IBM@IBMUS Subject: RE: Two errors on ModelElement - navigating without references There may be a specific set of criteria but I don't think it's been universally applied (btw, I suspect this lack of universality exists in UML as well). But the rule seems to have been applied at least in the instances where the cross-extent problem is glaringly obvious (like the StructuralFeatureType association) and someone has cared enough to complain about the dueling references. Doug -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Monday, July 23, 2001 10:00 AM To: Tolbert, Doug M Cc: Pete Rivett; 'Dan Chang'; Tolbert, Doug M; cwm-rtf@omg.org; Baisley, Donald E; 'Jing Chu' Subject: RE: Two errors on ModelElement - navigating without references Doug, OK. I remember now (i.e., discussing this MOF rule before). So I guess my question is: In the various places in the CWM 1.0 metamodel where we've made "model distribution" assumptions, in very general terms, what served as the basis for such assumptions? (I'm not challenging anything; this is just for my own understanding). In other words, as a metamodeler, how does one know in advance where extent boundaries are likely to exist? Regards, John "Tolbert, Doug M" on 07/23/2001 12:34:53 PM To: John Poole/na/Hyperion@Hyperion, Pete Rivett cc: "'Dan Chang'" , "Tolbert, Doug M" , cwm-rtf@omg.org, "Baisley, Donald E" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references Gents, Well, I'd like to have all those convenient references there as well. However, such references change our statement that "CWM is MOF compliant" to "CWM is MOF compliant when it's convenient". If I understand things correctly (and deferring to DonB on the fine technical points), the culprit is a MOF rule that says if the classes on either end of an association both have references, then both classes and the linking association must reside in the same EXTENT (note that this does not say "Package"; an extent is equivalent to a repository instance). So, if the association crosses an extent boundry, it can't have references on both ends. (The fact that ModelElement, Dependency, and the DependencyClient assocation are in the same package is immaterial -- it's the extent boundry that matters.) We have always acknowledged that in these cases you had to query the association, the class' reference. To want to have it both ways, while understandable, is "speaking with forked tongue". -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Monday, July 23, 2001 7:55 AM To: Pete Rivett Cc: 'Dan Chang'; 'Tolbert, Doug M'; cwm-rtf@omg.org; 'Baisley, Donald E'; 'Jing Chu' Subject: RE: Two errors on ModelElement - navigating without references Pete, Regarding your final comment: But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. The fact that you leverage reflection to resolve the navigation still doesn't change the fact that a mapped interface for ModelElement is not going to contain method calls supporting a supplierDependency reference. So I'm a little confused about your comment that "it's transparent to the user .... whether there is a stored reference in the metamodel or not". I think Dan's point is that, regardless of how tractible (or intractible) the problem of implementing a supplierDependency reference might be, the reference simply doesn't exist in the CWM 1.0 standard, hence there is no user transparency in this regard. There are a number of other places in the CWM 1.0 metamodel, by the way, where I've found a number of "asymmetrical" usages of references, some I think are intentional, some not. I will forward my complete list for comment shortly. Regards, John "Pete Rivett" on 07/21/2001 08:09:40 AM To: "'Dan Chang'" , "'Tolbert, Doug M'" cc: , "'Baisley, Donald E'" , "'Jing Chu'" Subject: RE: Two errors on ModelElement - navigating without references I agree with Dan's point about the need to have 2-way navigation of dependencies and also with the Doug's point about the need to facilitate federation. I believe both needs can be met with existing models and specifications and I describe this below. Obviously there remains an incompatibility between UML 1.3 and UML 1.4, but there was a reason for the change - as Doug described. To reprise, Dan's issue is the dropping of the supplierDependency reference from ModelElement to Dependency. Firstly I should say that the information will still be present in the XMI file - either through the Dependency element or through the Association/Link elements. Secondly when using APIs one does not have to use a reference to navigate an association: to get from a ModelElement to the Dependencies for which it is the supplier one can use the Association itself: For ModelElement, the IDL contains: DependencySet client_dependency () The equivalent for supplier can be gained by using DependencySet supplier_dependency (in ModelElement supplier) on interface: interface ASupplierSupplierDependency : Reflective::RefAssociation So for a ModelElement M, instead of calling: M.supplierDependency() one would call: A.supplier_dependency(M) Where A is obtained from the following attribute on the package extent: readonly attribute ASupplierSupplierDependency a_supplier_supplier_dependency_ref; It would thus be possible, for convenience, to define the equivalent of supplierDependency as a derived reference on ModelElement IF AND ONLY IF you knew which package extent(s) to use for querying the Association: it is precisely the lack of this knowledge in the general federated case that has led to dropping the reference from the standard UML metamodel. But if in the context of a specific application you can reliably know the package extents of interest you can implement this yourself. This is in fact what Adaptive has done as part of its Adaptive Repository product: we will allow the definition of 'confederations' of package extents for particular purposes and we use these to resolve such navigations (at the reflective level) so that it's transparent to the user working in the scope of a confederation whether there is a stored reference in the metamodel or not. Hope that helps, Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: 21 July 2001 00:18 > To: Tolbert, Doug M > Cc: cwm-rtf@omg.org; Baisley, Donald E; Jing Chu