Issue 4398: supplierDependency reference is missing from ModelElement (cwm-rtf) Source: International Business Machines (Dr. Daniel T. Chang, dtchang(at)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 > 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: 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 14:30:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 3k5!!AZ`d9d";e99Sh!! To my understanding the situation is fully analogus. -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Monday, July 23, 2001 12:19 PM 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 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 > 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:38:49 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/23/2001 01:38:51 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: KmPe9F9=!!%H4!!XLf!! Doug, The "type" reference (M2) between StructuralFeature and Classifier is defined between two ModelElements whose instances (M1) potentially can exist in two different MOF Extents. This is no different from defining the "supplierDependency" reference (M2) between ModelElement and Dependency, two ModelElements whose instances (M1) potentially can exist in two different 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 "Tolbert, Doug M" To: Dan Chang/Santa Teresa/IBM@IBMUS, "Tolbert, Doug M" nisys.com> cc: cwm-rtf@omg.org, "Baisley, Donald E" , "Tolbert, Doug M" 07/23/01 10:52 , Jing Chu/Santa Teresa/IBM@IBMUS, AM John_Poole@hyperion.com, Pete Rivett Subject: RE: Two errors on ModelElement - navigating without references 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: 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 15:39:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: k'Pe9hX#e9]B[!!/TJe9 Gee, I thought that's what I said. I'm out of time to worry about this right now. If you still think the model is wrong, I repeat my earlier suggestion that you should file an issue on the web page and we can vote on it at the next meeting. Doug -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Monday, July 23, 2001 12:39 PM 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, The "type" reference (M2) between StructuralFeature and Classifier is defined between two ModelElements whose instances (M1) potentially can exist in two different MOF Extents. This is no different from defining the "supplierDependency" reference (M2) between ModelElement and Dependency, two ModelElements whose instances (M1) potentially can exist in two different 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 "Tolbert, Doug M" To: Dan Chang/Santa Teresa/IBM@IBMUS, "Tolbert, Doug M" nisys.com> cc: cwm-rtf@omg.org, "Baisley, Donald E" , "Tolbert, Doug M" 07/23/01 10:52 , Jing Chu/Santa Teresa/IBM@IBMUS, AM John_Poole@hyperion.com, Pete Rivett Subject: RE: Two errors on ModelElement - navigating without references 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. 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 14:54:19 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/23/2001 03:54:20 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: kPU!!d]0!!ZBP!!=BAe9 Doug, If so, then I think there is no reason not to have the "supplierDependency" reference. I would appreciate if you can make the two changes ("supplierDependency" and "taggedValue" references on ModelElement) and send me the revised ObjectCore.bat. I would not mind to raise an issue to the OMG on this, if only for documentation purpose. Regarding voting, however, please note that these are corrections to omissions in the CWM 1.0 spec. That is, these features were in the CWM Adapted Specification. They were omitted in CWM 1.0 not by explicit issue resolution or agreement by the CWM FTF. Sorry to take up your time, but we need them to move on with our CWM implementation upgrading from the CWM Adapted Spec to CWM 1.0. 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, "Tolbert, Doug M" nisys.com> cc: cwm-rtf@omg.org, "Baisley, Donald E" , "Tolbert, Doug M" 07/23/01 01:39 , Jing Chu/Santa Teresa/IBM@IBMUS, PM John_Poole@hyperion.com, Pete Rivett Subject: RE: Two errors on ModelElement - navigating without references Gee, I thought that's what I said. I'm out of time to worry about this right now. If you still think the model is wrong, I repeat my earlier suggestion that you should file an issue on the web page and we can vote on it at the next meeting. Doug -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Monday, July 23, 2001 12:39 PM 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, The "type" reference (M2) between StructuralFeature and Classifier is defined between two ModelElements whose instances (M1) potentially can exist in two different MOF Extents. This is no different from defining the "supplierDependency" reference (M2) between ModelElement and Dependency, two ModelElements whose instances (M1) potentially can exist in two different 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 "Tolbert, Doug M" To: Dan Chang/Santa Teresa/IBM@IBMUS, "Tolbert, Doug M" nisys.com> cc: cwm-rtf@omg.org, "Baisley, Donald E" , "Tolbert, Doug M" 07/23/01 10:52 , Jing Chu/Santa Teresa/IBM@IBMUS, AM John_Poole@hyperion.com, Pete Rivett Subject: RE: Two errors on ModelElement - navigating without references 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: "Baisley, Donald E" To: "Tolbert, Doug M" , "'Dan Chang'" Cc: "'cwm-rtf@omg.org'" , "'Jing Chu'" , "'John_Poole@hyperion.com'" , "'Pete Rivett'" Subject: RE: Two errors on ModelElement - navigating without references Date: Mon, 23 Jul 2001 17:36:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 9AGe9iQh!!3f;e93ijd9 Hi CWM folks, I think Pete has explained things very clearly. If you want to support federation of extents, and if you want an element in one extent to be able to have a dependency on an element in a different extent, then leave the model as it is. If you think the whole universe must be in one extent, then you can put references everywhere. Enjoy, Don -----Original Message----- From: Tolbert, Doug M Sent: Monday, July 23, 2001 10:53 AM 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 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. Subject: RE: Two errors on ModelElement - navigating without references To: "Baisley, Donald E" Cc: "'cwm-rtf@omg.org'" , "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 17:22:23 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/23/2001 06:22:24 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: jk3e9Y?pd9(/9e9MZ4e9 Don, Your sweeping statement: "If you think the whole universe must be in one extent, then you can put references everywhere." is not very helpful when it comes to detailed design and specification. John and I are not advocating putting references everywhere in CWM. We are "still" searching for an explicit and clear guideline from MOF. I have looked up the MOF spec again. The following is copied from Section 2.3.4 References, verbatim: There are some of important restrictions on References: - When the "is_navigable" property of an Association End is false, it is not legal to define a Reference that "references" that Association End. - An M1 instance of a Class that "references" an Association cannot be used to make a link in an instance of the Association in a different extent. This restriction is described in "The Reference Closure Rule" on page 4-17. The MOF spec clearly differentiates between the definition of Reference (M2) from the creation of link (M1). Therefore, I do not see any MOF restriction preventing us from having the "supplierDependency" reference on ModelElement. This was in the CWM Adapted Specification and should have been in CWM 1.0, since there was no CWM FTF issue/resolution to remove it. 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 "Baisley, Donald E" To: "Tolbert, Doug M" , Dan cc: "'cwm-rtf@omg.org'" , Jing Chu/Santa Teresa/IBM@IBMUS, "'John_Poole@hyperion.com'" 07/23/01 03:36 PM , "'Pete Rivett'" Subject: RE: Two errors on ModelElement - navigating without references Hi CWM folks, I think Pete has explained things very clearly. If you want to support federation of extents, and if you want an element in one extent to be able to have a dependency on an element in a different extent, then leave the model as it is. If you think the whole universe must be in one extent, then you can put references everywhere. Enjoy, Don -----Original Message----- From: Tolbert, Doug M Sent: Monday, July 23, 2001 10:53 AM 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 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: "Baisley, Donald E" To: Dan Chang Cc: "'cwm-rtf@omg.org'" , "Tolbert, Doug M" , "'Jing Chu'" , "'John_Poole@hyperion.com'" , "'Pete Rivett'" Subject: RE: Two errors on ModelElement - navigating without references Date: Tue, 24 Jul 2001 01:57:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: mE$e9MbNe9Qcl!!Q~1!! Hi Dan, My sweeping statement about fitting the whole universe into one extent is exactly the guideline you are looking for. It's a general statement that is easily specialized. For example, "If you think the whole universe of objects that can be linked together by a dependency must be in one single extent, then put references everywhere for dependencies." MOF does not prevent you from coming to such a conclusion. MOF will let you stick references everywhere. I'm not telling you how to model it. I'm just talking about that clear guideline from MOF that you are "still searching for" but have obviously found already: The Reference Closure Rule. It tells you that having a reference implies a constraint on links. If you don't want the constraint, then don't use a reference. It's that simple. Best wishes to the maximum extent (or extents if your model permits), Don -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Monday, July 23, 2001 5:22 PM To: Baisley, Donald E Cc: 'cwm-rtf@omg.org'; Tolbert, Doug M; 'Jing Chu'; 'John_Poole@hyperion.com'; 'Pete Rivett' Subject: RE: Two errors on ModelElement - navigating without references Importance: High Don, Your sweeping statement: "If you think the whole universe must be in one extent, then you can put references everywhere." is not very helpful when it comes to detailed design and specification. John and I are not advocating putting references everywhere in CWM. We are "still" searching for an explicit and clear guideline from MOF. I have looked up the MOF spec again. The following is copied from Section 2.3.4 References, verbatim: There are some of important restrictions on References: - When the "is_navigable" property of an Association End is false, it is not legal to define a Reference that "references" that Association End. - An M1 instance of a Class that "references" an Association cannot be used to make a link in an instance of the Association in a different extent. This restriction is described in "The Reference Closure Rule" on page 4-17. The MOF spec clearly differentiates between the definition of Reference (M2) from the creation of link (M1). Therefore, I do not see any MOF restriction preventing us from having the "supplierDependency" reference on ModelElement. This was in the CWM Adapted Specification and should have been in CWM 1.0, since there was no CWM FTF issue/resolution to remove it. 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 "Baisley, Donald E" To: "Tolbert, Doug M" , Dan cc: "'cwm-rtf@omg.org'" , Jing Chu/Santa Teresa/IBM@IBMUS, "'John_Poole@hyperion.com'" 07/23/01 03:36 PM , "'Pete Rivett'" Subject: RE: Two errors on ModelElement - navigating without references Hi CWM folks, I think Pete has explained things very clearly. If you want to support federation of extents, and if you want an element in one extent to be able to have a dependency on an element in a different extent, then leave the model as it is. If you think the whole universe must be in one extent, then you can put references everywhere. Enjoy, Don -----Original Message----- From: Tolbert, Doug M Sent: Monday, July 23, 2001 10:53 AM 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 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: "Pete Rivett" To: "'Dan Chang'" Cc: , "'Baisley, Donald E'" , "'Jing Chu'" , , "'Tolbert, Doug M'" Subject: RE: Two errors on ModelElement - navigating without references Date: Tue, 24 Jul 2001 11:26:05 +0100 Message-ID: <000d01c1142b$0c050790$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: <97F39596DEEECF11BC020000C09361E502AF410F@mv_exchange_2.mv.unisys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: k;:e9@R#"!k)dd9~H_!! Dan, (As Doug times out I'll step into the breach!) The reason the ModelElement-SupplierDependency situation is analogous to Classifier-StructuralFeature is that there is *only* a reference from StructuralFeature to Classifier and *not* from Classifier to StructuralFeature. This is to allow a modeler to define Attributes based on Datatypes defined by someone else (and hence possibly stored in another Extent) - which I hope you can see is important for both UML and CWM as well as MOF itself (which is developing a PrimitiveTypes package). Similarly with Dependency and ModelElement: there is only a supplier reference from Dependency to ModelElement and *not* from ModelElement to its supplierDependencies. This is to allow a modeler to define dependencies on model elements defined by someone else (and hence possibly stored in another Extent) - which I hope you can see is important for both UML and CWM. It seems to me vital for the application of MDA where one would expect to use a Dependency object (or a subclass) to record trace information from a PSM to a PIM without both being stored together. Hope that clears the analogy at least. I really don't think we can change the *model* in this area: what I've been trying to do is move the discussion onto ways we might make the lack of a stored reference more liveable (in which case I might recommend opening it up to the MOF RTF). 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: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: 23 July 2001 21:40 > 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 > > > Gee, I thought that's what I said. > > I'm out of time to worry about this right now. If you still > think the model > is wrong, I repeat my earlier suggestion that you should file > an issue on > the web page and we can vote on it at the next meeting. > > Doug > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Monday, July 23, 2001 12:39 PM > 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, > > The "type" reference (M2) between StructuralFeature and Classifier is > defined between two ModelElements whose instances (M1) potentially can > exist in two different MOF Extents. This is no different from > defining the > "supplierDependency" reference (M2) between ModelElement and > Dependency, > two ModelElements whose instances (M1) potentially can exist in two > different 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 > > > > > "Tolbert, Doug > > M" To: Dan Chang/Santa > Teresa/IBM@IBMUS, "Tolbert, Doug M" > > > nisys.com> cc: > cwm-rtf@omg.org, "Baisley, > Donald E" > > , > "Tolbert, Doug M" > 07/23/01 10:52 > , Jing > Chu/Santa Teresa/IBM@IBMUS, > AM > John_Poole@hyperion.com, Pete > Rivett > Subject: RE: > Two errors on > ModelElement - navigating without > references > > > > > > > > > > > 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. > > > > > > > > > > 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: "Baisley, Donald E" To: Dan Chang Cc: "'cwm-rtf@omg.org'" , "Tolbert, Doug M" , "'Jing Chu'" , "'John_Poole@hyperion.com'" , "'Pete Rivett'" Subject: RE: Two errors on ModelElement - navigating without references Date: Tue, 24 Jul 2001 14:11:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: lM5!!G+&e9=^@e91fDe9 Hi Dan, You are saying I agree with something I never said or wrote. I plainly said the rule you are looking for is the "The Reference Closure Rule", which has nothing to do with navigability. You quoted a reference to the rule in your earlier email, so I assumed you had found the rule and had read it (4.9.1 in the MOF Specification). The navigability requirement you mention is one of many constraints concerning Reference. I thought you were looking for a rule to help you decide where a reference is appropriate (which is presumably a subset of where it is legal). If you are only interested in what's legal, regardless of sensibility, then you will probably find yourself at odds with other people trying to use CWM. Have a nice day, Don -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Tuesday, July 24, 2001 9:07 AM To: Baisley, Donald E Cc: 'cwm-rtf@omg.org'; Tolbert, Doug M; 'Jing Chu'; 'John_Poole@hyperion.com'; 'Pete Rivett' Subject: RE: Two errors on ModelElement - navigating without references Importance: High Don, I am glad you agree that the only rule in MOF forbidding the definition of Reference is the following: When the "is_navigable" property of an Association End is false, it is not legal to define a Reference that "references" that Association End. This is the only rule we must follow when defining 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 "Baisley, Donald E" To: Dan Chang/Santa Teresa/IBM@IBMUS , "Tolbert, Doug M" nisys.com> , Jing Chu/Santa Teresa/IBM@IBMUS, "'John_Poole@hyperion.com'" , "'Pete 07/23/01 11:57 PM Rivett'" Subject: RE: Two errors on ModelElement - navigating without references Hi Dan, My sweeping statement about fitting the whole universe into one extent is exactly the guideline you are looking for. It's a general statement that is easily specialized. For example, "If you think the whole universe of objects that can be linked together by a dependency must be in one single extent, then put references everywhere for dependencies." MOF does not prevent you from coming to such a conclusion. MOF will let you stick references everywhere. I'm not telling you how to model it. I'm just talking about that clear guideline from MOF that you are "still searching for" but have obviously found already: The Reference Closure Rule. It tells you that having a reference implies a constraint on links. If you don't want the constraint, then don't use a reference. It's that simple. Best wishes to the maximum extent (or extents if your model permits), Don -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Monday, July 23, 2001 5:22 PM To: Baisley, Donald E Cc: 'cwm-rtf@omg.org'; Tolbert, Doug M; 'Jing Chu'; 'John_Poole@hyperion.com'; 'Pete Rivett' Subject: RE: Two errors on ModelElement - navigating without references Importance: High Don, Your sweeping statement: "If you think the whole universe must be in one extent, then you can put references everywhere." is not very helpful when it comes to detailed design and specification. John and I are not advocating putting references everywhere in CWM. We are "still" searching for an explicit and clear guideline from MOF. I have looked up the MOF spec again. The following is copied from Section 2.3.4 References, verbatim: There are some of important restrictions on References: - When the "is_navigable" property of an Association End is false, it is not legal to define a Reference that "references" that Association End. - An M1 instance of a Class that "references" an Association cannot be used to make a link in an instance of the Association in a different extent. This restriction is described in "The Reference Closure Rule" on page 4-17. The MOF spec clearly differentiates between the definition of Reference (M2) from the creation of link (M1). Therefore, I do not see any MOF restriction preventing us from having the "supplierDependency" reference on ModelElement. This was in the CWM Adapted Specification and should have been in CWM 1.0, since there was no CWM FTF issue/resolution to remove it. 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 "Baisley, Donald E" To: "Tolbert, Doug M" , Dan cc: "'cwm-rtf@omg.org'" , Jing Chu/Santa Teresa/IBM@IBMUS, "'John_Poole@hyperion.com'" 07/23/01 03:36 PM , "'Pete Rivett'" Subject: RE: Two errors on ModelElement - navigating without references Hi CWM folks, I think Pete has explained things very clearly. If you want to support federation of extents, and if you want an element in one extent to be able to have a dependency on an element in a different extent, then leave the model as it is. If you think the whole universe must be in one extent, then you can put references everywhere. Enjoy, Don -----Original Message----- From: Tolbert, Doug M Sent: Monday, July 23, 2001 10:53 AM 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 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. Subject: RE: Two errors on ModelElement - navigating without references To: "Baisley, Donald E" Cc: "'cwm-rtf@omg.org'" , "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: Tue, 24 Jul 2001 12:33:11 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/24/2001 01:33:12 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: _gP!![?, "Tolbert, Doug M" nisys.com> , Jing Chu/Santa Teresa/IBM@IBMUS, "'John_Poole@hyperion.com'" , "'Pete 07/24/01 12:11 PM Rivett'" Subject: RE: Two errors on ModelElement - navigating without references Hi Dan, You are saying I agree with something I never said or wrote. I plainly said the rule you are looking for is the "The Reference Closure Rule", which has nothing to do with navigability. You quoted a reference to the rule in your earlier email, so I assumed you had found the rule and had read it (4.9.1 in the MOF Specification). The navigability requirement you mention is one of many constraints concerning Reference. I thought you were looking for a rule to help you decide where a reference is appropriate (which is presumably a subset of where it is legal). If you are only interested in what's legal, regardless of sensibility, then you will probably find yourself at odds with other people trying to use CWM. Have a nice day, Don -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Tuesday, July 24, 2001 9:07 AM To: Baisley, Donald E Cc: 'cwm-rtf@omg.org'; Tolbert, Doug M; 'Jing Chu'; 'John_Poole@hyperion.com'; 'Pete Rivett' Subject: RE: Two errors on ModelElement - navigating without references Importance: High Don, I am glad you agree that the only rule in MOF forbidding the definition of Reference is the following: When the "is_navigable" property of an Association End is false, it is not legal to define a Reference that "references" that Association End. This is the only rule we must follow when defining 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 "Baisley, Donald E" To: Dan Chang/Santa Teresa/IBM@IBMUS , "Tolbert, Doug M" nisys.com> , Jing Chu/Santa Teresa/IBM@IBMUS, "'John_Poole@hyperion.com'" , "'Pete 07/23/01 11:57 PM Rivett'" Subject: RE: Two errors on ModelElement - navigating without references Hi Dan, My sweeping statement about fitting the whole universe into one extent is exactly the guideline you are looking for. It's a general statement that is easily specialized. For example, "If you think the whole universe of objects that can be linked together by a dependency must be in one single extent, then put references everywhere for dependencies." MOF does not prevent you from coming to such a conclusion. MOF will let you stick references everywhere. I'm not telling you how to model it. I'm just talking about that clear guideline from MOF that you are "still searching for" but have obviously found already: The Reference Closure Rule. It tells you that having a reference implies a constraint on links. If you don't want the constraint, then don't use a reference. It's that simple. Best wishes to the maximum extent (or extents if your model permits), Don -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Monday, July 23, 2001 5:22 PM To: Baisley, Donald E Cc: 'cwm-rtf@omg.org'; Tolbert, Doug M; 'Jing Chu'; 'John_Poole@hyperion.com'; 'Pete Rivett' Subject: RE: Two errors on ModelElement - navigating without references Importance: High Don, Your sweeping statement: "If you think the whole universe must be in one extent, then you can put references everywhere." is not very helpful when it comes to detailed design and specification. John and I are not advocating putting references everywhere in CWM. We are "still" searching for an explicit and clear guideline from MOF. I have looked up the MOF spec again. The following is copied from Section 2.3.4 References, verbatim: There are some of important restrictions on References: - When the "is_navigable" property of an Association End is false, it is not legal to define a Reference that "references" that Association End. - An M1 instance of a Class that "references" an Association cannot be used to make a link in an instance of the Association in a different extent. This restriction is described in "The Reference Closure Rule" on page 4-17. The MOF spec clearly differentiates between the definition of Reference (M2) from the creation of link (M1). Therefore, I do not see any MOF restriction preventing us from having the "supplierDependency" reference on ModelElement. This was in the CWM Adapted Specification and should have been in CWM 1.0, since there was no CWM FTF issue/resolution to remove it. 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 "Baisley, Donald E" To: "Tolbert, Doug M" , Dan cc: "'cwm-rtf@omg.org'" , Jing Chu/Santa Teresa/IBM@IBMUS, "'John_Poole@hyperion.com'" 07/23/01 03:36 PM , "'Pete Rivett'" Subject: RE: Two errors on ModelElement - navigating without references Hi CWM folks, I think Pete has explained things very clearly. If you want to support federation of extents, and if you want an element in one extent to be able to have a dependency on an element in a different extent, then leave the model as it is. If you think the whole universe must be in one extent, then you can put references everywhere. Enjoy, Don -----Original Message----- From: Tolbert, Doug M Sent: Monday, July 23, 2001 10:53 AM 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 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. Date: Tue, 24 Jul 2001 16:04:49 -0400 From: David Mellor Organization: Oracle Corporation X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Chang CC: "Baisley, Donald E" , "'cwm-rtf@omg.org'" , "Tolbert, Doug M" , "'Jing Chu'" , "'John_Poole@hyperion.com'" , "'Pete Rivett'" Subject: Re: Two errors on ModelElement - navigating without references References: Content-Type: multipart/mixed; boundary="------------02AB44182A76E862A09E27A0" X-UIDL: *L`d9*dKe9kGod91\1e9 Dan, Could you tell me what the process is to work on and resolve an urgent issue raised to the CWM RTF. Thanks, Dave M. Dan Chang wrote: > Don, > > The issue raised by Doug on the "supplierDependency" reference had >to do > with MOF compliance, thus legality. Regarding sensibility, the CWM >RTF will > have a chance to discuss and resolve it on these two references when >the > team works on the urgent issue that I just raised. > > 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 > > > "Baisley, Donald > E" To: Dan Chang/Santa >Teresa/IBM@IBMUS > "'cwm-rtf@omg.org'" , "Tolbert, Doug M" > nisys.com> >, Jing Chu/Santa Teresa/IBM@IBMUS, > "'John_Poole@hyperion.com'" , "'Pete > 07/24/01 12:11 PM Rivett'" > > Subject: RE: Two >errors on ModelElement - navigating without > references > > > > > Hi Dan, > > You are saying I agree with something I never said or wrote. I >plainly > said > the rule you are looking for is the "The Reference Closure Rule", >which has > nothing to do with navigability. You quoted a reference to the rule >in > your > earlier email, so I assumed you had found the rule and had read it >(4.9.1 > in > the MOF Specification). > > The navigability requirement you mention is one of many constraints > concerning Reference. I thought you were looking for a rule to help >you > decide where a reference is appropriate (which is presumably a >subset of > where it is legal). If you are only interested in what's legal, >regardless > of sensibility, then you will probably find yourself at odds with >other > people trying to use CWM. > > Have a nice day, > Don > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Tuesday, July 24, 2001 9:07 AM > To: Baisley, Donald E > Cc: 'cwm-rtf@omg.org'; Tolbert, Doug M; 'Jing Chu'; > 'John_Poole@hyperion.com'; 'Pete Rivett' > Subject: RE: Two errors on ModelElement - navigating without >references > Importance: High > > Don, > > I am glad you agree that the only rule in MOF forbidding the >definition of > Reference is the following: > When the "is_navigable" property of an Association End is false, >it is > not legal to define a Reference that "references" that Association >End. > > This is the only rule we must follow when defining 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 > > "Baisley, Donald > > E" To: Dan Chang/Santa > Teresa/IBM@IBMUS > "'cwm-rtf@omg.org'" > , "Tolbert, Doug M" > nisys.com> >, > Jing > Chu/Santa Teresa/IBM@IBMUS, > "'John_Poole@hyperion.com'" > , "'Pete > 07/23/01 11:57 PM Rivett'" > > Subject: RE: Two >errors on > ModelElement - navigating without > references > > Hi Dan, > > My sweeping statement about fitting the whole universe into one >extent is > exactly the guideline you are looking for. It's a general statement >that > is > easily specialized. For example, "If you think the whole universe >of > objects that can be linked together by a dependency must be in one >single > extent, then put references everywhere for dependencies." MOF does >not > prevent you from coming to such a conclusion. MOF will let you >stick > references everywhere. > > I'm not telling you how to model it. I'm just talking about that >clear > guideline from MOF that you are "still searching for" but have >obviously > found already: The Reference Closure Rule. It tells you that having >a > reference implies a constraint on links. If you don't want the >constraint, > then don't use a reference. It's that simple. > > Best wishes to the maximum extent (or extents if your model >permits), > Don > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Monday, July 23, 2001 5:22 PM > To: Baisley, Donald E > Cc: 'cwm-rtf@omg.org'; Tolbert, Doug M; 'Jing Chu'; > 'John_Poole@hyperion.com'; 'Pete Rivett' > Subject: RE: Two errors on ModelElement - navigating without >references > Importance: High > > Don, > > Your sweeping statement: "If you think the whole universe must be in >one > extent, then you can put references everywhere." is not very helpful >when > it comes to detailed design and specification. John and I are not > advocating putting references everywhere in CWM. We are "still" >searching > for an explicit and clear guideline from MOF. > > I have looked up the MOF spec again. The following is copied from >Section > 2.3.4 References, verbatim: > There are some of important restrictions on References: > - When the "is_navigable" property of an Association End is false, >it is > not legal to define a Reference that "references" that Association >End. > - An M1 instance of a Class that "references" an Association >cannot be > used to make a link in an instance of the Association in a different > extent. This restriction is described in "The Reference Closure >Rule" > on page 4-17. > > The MOF spec clearly differentiates between the definition of >Reference > (M2) from the creation of link (M1). Therefore, I do not see any MOF > restriction preventing us from having the "supplierDependency" >reference on > ModelElement. This was in the CWM Adapted Specification and should >have > been in CWM 1.0, since there was no CWM FTF issue/resolution to >remove it. > > 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 > > "Baisley, Donald > > E" To: "Tolbert, Doug >M" > , Dan > Teresa/IBM@IBMUS > > nisys.com> cc: >"'cwm-rtf@omg.org'" > , Jing Chu/Santa > Teresa/IBM@IBMUS, > "'John_Poole@hyperion.com'" > 07/23/01 03:36 PM >, > "'Pete Rivett'" > > > Subject: RE: Two >errors on > ModelElement - navigating without > references > > Hi CWM folks, > > I think Pete has explained things very clearly. If you want to >support > federation of extents, and if you want an element in one extent to >be able > to have a dependency on an element in a different extent, then leave >the > model as it is. If you think the whole universe must be in one >extent, > then > you can put references everywhere. > > Enjoy, > Don > > -----Original Message----- > From: Tolbert, Doug M > Sent: Monday, July 23, 2001 10:53 AM > 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 > > 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. [] David.Mellor2.vcf From: "Pete Rivett" To: , Cc: "'Juergen Boldt'" Subject: RE: issue 4398 -- URGENT CWM RTF issue Date: Wed, 25 Jul 2001 03:16:46 +0100 Message-ID: <004e01c114af$db6d72e0$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: <4.3.2.7.2.20010724165724.04af7be0@emerald.omg.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Content-Type: text/plain; charset="us-ascii" X-UIDL: 8Shd96]1!!D/?!!p6"!! Sorry to be a pain but I really think this should cataloged as 2 distinct issues: though a similar category of 'error' they are otherwise unrelated. Below is an email from Doug very early in this thread that explains their distinct nature. If it's too late to change the issue number allocation (could we even re-open the duplicate 4408?) I think we should at least process/vote on them separately (Dan's even already provided us with reference numbers 4398(1) and 4398(2)). My feeling is that we may be able to agree 4398(2) very quickly. Though open to persuasion I'm at the moment expecting (this is not my formal vote) to vote YES to adding the reference for (2) but NO for (1) - for reasons spelled out in the long email thread that preceded the issue being formally raised, and also for consistency with UML 1.4. 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: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: 20 July 2001 23:50 To: Dan Chang Cc: cwm-rtf@omg.org; Jing Chu; Baisley, Donald E Subject: RE: Two errors on ModelElement 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 > -----Original Message----- > From: Juergen Boldt [mailto:juergen@omg.org] > Sent: 24 July 2001 21:58 > To: issues@emerald.omg.org; cwm-rtf@emerald.omg.org > Subject: issue 4398 -- CWM RTF issue > > > This is issue # 4398 "Dan Chang" > > Two errors on ModelElement > > 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.) > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 > ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > URL: www.omg.org > > > > ================================================================ > > 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. Date: Wed, 25 Jul 2001 08:58:43 -0400 From: David Mellor Organization: Oracle Corporation X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete Rivett CC: cwm-rtf@emerald.omg.org, andrew@omg.org, "'Juergen Boldt'" Subject: Re: issue 4398 -- URGENT CWM RTF issue References: <004e01c114af$db6d72e0$114c04c8@CHIMAY> Content-Type: multipart/mixed; boundary="------------62B6E13181113F1A4CD9219F" X-UIDL: C4ad9eF:!!~9~e9jJM!! All, I agree with Pete, there are two distinct issues here and we should vote on the references in question separately. Dave M. Pete Rivett wrote: > Sorry to be a pain but I really think this should cataloged as 2 distinct > issues: though a similar category of 'error' they are otherwise unrelated. > Below is an email from Doug very early in this thread that explains their > distinct nature. > > If it's too late to change the issue number allocation (could we even > re-open the duplicate 4408?) I think we should at least process/vote on them > separately (Dan's even already provided us with reference numbers 4398(1) > and 4398(2)). My feeling is that we may be able to agree 4398(2) very > quickly. > > Though open to persuasion I'm at the moment expecting (this is not my formal > vote) to vote YES to adding the reference for (2) but NO for (1) - for > reasons spelled out in the long email thread that preceded the issue being > formally raised, and also for consistency with UML 1.4. > > 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: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: 20 July 2001 23:50 > To: Dan Chang > Cc: cwm-rtf@omg.org; Jing Chu; Baisley, Donald E > Subject: RE: Two errors on ModelElement > > 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 > > > -----Original Message----- > > From: Juergen Boldt [mailto:juergen@omg.org] > > Sent: 24 July 2001 21:58 > > To: issues@emerald.omg.org; cwm-rtf@emerald.omg.org > > Subject: issue 4398 -- CWM RTF issue > > > > > > This is issue # 4398 "Dan Chang" > > > > Two errors on ModelElement > > > > 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.) > > ================================================================ > > > > Juergen Boldt > > Senior Member of Technical Staff > > > > Object Management Group Tel. +1-781 444 0404 > > ext. 132 > > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > > Needham, MA 02494, USA Email: juergen@omg.org > > URL: www.omg.org > > > > > > > > ================================================================ > > > > > > 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. [] David.Mellor3.vcf From: John_Poole@hyperion.com Subject: RE: issue 4398 -- URGENT CWM RTF issue To: "Pete Rivett" Cc: , , "'Juergen Boldt'" Date: Wed, 25 Jul 2001 10:18:51 -0400 Message-ID: X-MIMETrack: Serialize by Router on Stmfd-Gateway1/na/Hyperion(Release 5.0.5 |September 22, 2000) at 07/25/2001 10:18:53 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: h6 on 07/24/2001 10:16:46 PM To: , cc: "'Juergen Boldt'" Subject: RE: issue 4398 -- URGENT CWM RTF issue Sorry to be a pain but I really think this should cataloged as 2 distinct issues: though a similar category of 'error' they are otherwise unrelated. Below is an email from Doug very early in this thread that explains their distinct nature. If it's too late to change the issue number allocation (could we even re-open the duplicate 4408?) I think we should at least process/vote on them separately (Dan's even already provided us with reference numbers 4398(1) and 4398(2)). My feeling is that we may be able to agree 4398(2) very quickly. Though open to persuasion I'm at the moment expecting (this is not my formal vote) to vote YES to adding the reference for (2) but NO for (1) - for reasons spelled out in the long email thread that preceded the issue being formally raised, and also for consistency with UML 1.4. 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: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: 20 July 2001 23:50 To: Dan Chang Cc: cwm-rtf@omg.org; Jing Chu; Baisley, Donald E Subject: RE: Two errors on ModelElement 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. From: "Tolbert, Doug M" To: John_Poole@hyperion.com, Pete Rivett Cc: cwm-rtf@emerald.omg.org, andrew@omg.org, "'Juergen Boldt'" Subject: RE: issue 4398 -- URGENT CWM RTF issue Date: Wed, 25 Jul 2001 12:22:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: X6W!!\eAe9d8,e9QgLd9 Count me in as also concerned about the "urgent" nature of the complaint -- the irreversability characteristic of any solution makes me very unlike to support the "urgent" label. I fully support John/Pete's characterization of #4398 -- (2) is simply an error, (1) was done on purpose and with apparent concurrence of all in attendence. Regards, Doug -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Wednesday, July 25, 2001 7:19 AM To: Pete Rivett Cc: cwm-rtf@emerald.omg.org; andrew@omg.org; 'Juergen Boldt' Subject: RE: issue 4398 -- URGENT CWM RTF issue I agree with Pete. Issue 4398(2) is admittedly an error. I think no one disputes this. Whether or not its resolution can be deemed urgent in nature, of course, is another matter. Issue 4398(1), on the other hand, was not an oversight, but was done quite deliberately and with some rational thought behind it. I am very concerned about this "irreversability" of an urgent change request. As I had stated in my earlier email, I've observed a number of "unbalanced" or "asymmetrical" (for lack of better terminology) reference usages in other places in CWM, although I haven't made any comment on these yet. Are all of these occurrences "urgent" in nature? By logical implication (given issue 4398 as the premise), all of them should be made urgent issues, shouldn't they? But somehow, that just doesn't seem all that reasonable to me.... Regards, John "Pete Rivett" on 07/24/2001 10:16:46 PM To: , cc: "'Juergen Boldt'" Subject: RE: issue 4398 -- URGENT CWM RTF issue Sorry to be a pain but I really think this should cataloged as 2 distinct issues: though a similar category of 'error' they are otherwise unrelated. Below is an email from Doug very early in this thread that explains their distinct nature. If it's too late to change the issue number allocation (could we even re-open the duplicate 4408?) I think we should at least process/vote on them separately (Dan's even already provided us with reference numbers 4398(1) and 4398(2)). My feeling is that we may be able to agree 4398(2) very quickly. Though open to persuasion I'm at the moment expecting (this is not my formal vote) to vote YES to adding the reference for (2) but NO for (1) - for reasons spelled out in the long email thread that preceded the issue being formally raised, and also for consistency with UML 1.4. 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: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: 20 July 2001 23:50 To: Dan Chang Cc: cwm-rtf@omg.org; Jing Chu; Baisley, Donald E Subject: RE: Two errors on ModelElement 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 > -----Original Message----- > From: Juergen Boldt [mailto:juergen@omg.org] > Sent: 24 July 2001 21:58 > To: issues@emerald.omg.org; cwm-rtf@emerald.omg.org > Subject: issue 4398 -- CWM RTF issue > > > This is issue # 4398 "Dan Chang" > > Two errors on ModelElement > > 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.) > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 > ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > URL: www.omg.org > > > > ================================================================ > > 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: "Baisley, Donald E" Cc: "'cwm-rtf@omg.org'" , "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: Tue, 24 Jul 2001 09:07:28 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/24/2001 10:07:30 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: 8Vl!!WSQd9#Fp!!c0dd9 Don, I am glad you agree that the only rule in MOF forbidding the definition of Reference is the following: When the "is_navigable" property of an Association End is false, it is not legal to define a Reference that "references" that Association End. This is the only rule we must follow when defining 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 "Baisley, Donald E" To: Dan Chang/Santa Teresa/IBM@IBMUS , "Tolbert, Doug M" nisys.com> , Jing Chu/Santa Teresa/IBM@IBMUS, "'John_Poole@hyperion.com'" , "'Pete 07/23/01 11:57 PM Rivett'" Subject: RE: Two errors on ModelElement - navigating without references Hi Dan, My sweeping statement about fitting the whole universe into one extent is From: webmaster@omg.org Message-Id: <200107252100.f6PL0Pt19764@emerald.omg.org> Date: 25 Jul 2001 17:02:00 -0400 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: EZYd9$0D!!)$m!!N:"!! Name: Dan Chang Company: IBM mailFrom: dtchang@us.ibm.com Notification: No Specification: CWM Specification Section: 7.3.2.12 FormalNumber: ad/01-02-01 Version: 1.0 RevisionDate: 2 Feb 2001 Page: 7-78 Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.61 [en] (WinNT; U) Description 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.) From: "Pete Rivett" To: "'Dan Chang'" Cc: , , , "'Jeffrey Mischkinsky'" Subject: RE: issue 4398 -- URGENT CWM RTF issue Date: Thu, 26 Jul 2001 13:24:50 +0100 Message-ID: <003901c115cd$f88095a0$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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: Content-Type: text/plain; charset="us-ascii" X-UIDL: ;'Ce9C#)e9(L!e9N-m!! Dan, In terms of getting this resolved ASAP I think it would help if you (as raiser) amended the Urgent issue 4398 to remove the supplierDependency stuff (and put that into a separate issue). Based on the consensus I've seen in the emails I don't see any need to delay going straight to a vote on the remainder (ModelElement to Tag). So you could draft a proposed resolution for the Tag issue (which is simply to add the reference from ModelElement) and put it straight out to RTF email vote (need to check who the voters are and quorum; and decide how much time to allow for the vote - I'd suggest by end next Monday 6th August (or maybe that's too long depending on the quorum)). I don't see that we need to wait for a default resolution from Andrew to *start* sorting it ourselves - Andrew's default would only apply if we can't sort it in 2 weeks. Also I *don't* want Andrew to create a default binding resolution on part (1) which is not urgent anyway. (Copied to process experts for shooting down if I've misunderstood how things should work). Pete PS There's a separate issue of how we name/manage the regenerated files - I've raised this for discussion with mof-rtf which is looking at the general issue of naming, and cc'd cwm-rtf. It needn't hold up the resolution but I'm keen we allow discussion on this before *publicly* publishing new files. 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: 25 July 2001 19:52 > To: Pete Rivett > Cc: andrew@omg.org; cwm-rtf@emerald.omg.org; 'Juergen Boldt' > Subject: RE: issue 4398 -- URGENT CWM RTF issue > > > > Pete, > > I have no objection to separating the two missing references > as two issues. > > If so, the missing tagValue reference on ModelElement is > urgent and needs > to be fixed immediately. If not, it will inhibit our ability > to support CWM > 1.0. > > The missing supplierDependency reference can be treated as a > normal issue. > We either already have the equivalence where we need it or > can do without > it. elsewhere. The CWM RTF can discuss and agree on whether > it should be > put back or the client reference on Dependency should also be > removed to > make the model logically balanced and sensible. > > 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 > > > > > "Pete Rivett" > > , > ptive.com> cc: "'Juergen > Boldt'" > Subject: RE: > issue 4398 -- URGENT CWM RTF issue > 07/24/01 07:16 > > PM > > > > > > > > > Sorry to be a pain but I really think this should cataloged > as 2 distinct > issues: though a similar category of 'error' they are > otherwise unrelated. > Below is an email from Doug very early in this thread that > explains their > distinct nature. > > If it's too late to change the issue number allocation (could we even > re-open the duplicate 4408?) I think we should at least > process/vote on > them > separately (Dan's even already provided us with reference > numbers 4398(1) > and 4398(2)). My feeling is that we may be able to agree 4398(2) very > quickly. > > Though open to persuasion I'm at the moment expecting (this is not my > formal > vote) to vote YES to adding the reference for (2) but NO for (1) - for > reasons spelled out in the long email thread that preceded > the issue being > formally raised, and also for consistency with UML 1.4. > > 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: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: 20 July 2001 23:50 > To: Dan Chang > Cc: cwm-rtf@omg.org; Jing Chu; Baisley, Donald E > Subject: RE: Two errors on ModelElement > > > 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 > > > > -----Original Message----- > > From: Juergen Boldt [mailto:juergen@omg.org] > > Sent: 24 July 2001 21:58 > > To: issues@emerald.omg.org; cwm-rtf@emerald.omg.org > > Subject: issue 4398 -- CWM RTF issue > > > > > > This is issue # 4398 "Dan Chang" > > > > Two errors on ModelElement > > > > 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.) > > ================================================================ > > > > Juergen Boldt > > Senior Member of Technical Staff > > > > Object Management Group Tel. > +1-781 444 > 0404 > > ext. 132 > > 250 First Avenue, Suite 201 Fax: > +1-781 444 > 0320 > > Needham, MA 02494, USA Email: > juergen@omg.org > > URL: > www.omg.org > > > > > > > > ================================================================ > > > > > > > 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: John_Poole@hyperion.com Subject: RE: issue 4398 -- URGENT CWM RTF issue To: "Tolbert, Doug M" Cc: David Mellor , Dan Chang , Andrew Watson , cwm-rtf@omg.org, "'Juergen Boldt'" , Pete Rivett Date: Thu, 26 Jul 2001 17:43:59 -0400 Message-ID: X-MIMETrack: Serialize by Router on Stmfd-Gateway1/na/Hyperion(Release 5.0.5 |September 22, 2000) at 07/26/2001 05:44:03 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: ,lIe9>Jdd9(2Yd9MF=!! Doug, No, you're not hallucinating. There is currently no ModelElement::Stereotype reference in CWM 1.0. I wonder if maybe there is some sublimal reasoning going on here. For example, Stereotypes and TaggedValues are both essentially "labels" that are attached to model elements to extend their semantics in some way. As "light-weight" extension mechanisms, is it fair to say that a model element should not be "burdened" with having to possess knowledge about any labels that have been attached to it? Perhaps this was why these references both ended up getting dropped from model element(?) Of course, I'm just speculating here, and from a query/model navigation perspective, having the references there makes things easier, regardless of the epistemological arguments. So I would say that both ModelElement::TaggedValue and ModelElement::Stereotype be added back to ModelElement together. Regards, John "Tolbert, Doug M" on 07/26/2001 02:15:24 PM To: David Mellor , Dan Chang cc: Andrew Watson , cwm-rtf@omg.org, "'Juergen Boldt'" , Pete Rivett Subject: RE: issue 4398 -- URGENT CWM RTF issue While investigating the taggedValue thingy, I noticed the a similar situation exists for the missing ModelElement::stereotype reference. Most likely for all the same package reloctaion reasons as taggedValue (Stereotype and TaggedValue moved around together during this time). Like taggedValue, the StereoType::extendedElement reference also shows an inverse called "ModelElement::stereotype". Would someone (JohnP? -- stereotypes were included for you!) please verify this to ensure that I am not hallucinating? If everyone (including Andrew) agrees, I could easily add this in with the change that Dan needs for taggedValue. Oh-man-I-hate-this-stuff, Doug -----Original Message----- From: David Mellor [mailto:David.Mellor@oracle.com] Sent: Thursday, July 26, 2001 10:52 AM To: Dan Chang Cc: Andrew Watson; cwm-rtf@omg.org; 'Juergen Boldt'; Pete Rivett Subject: Re: issue 4398 -- URGENT CWM RTF issue Dan, Could you tell me what the process for this is? Doug has identified where he thinks the spec could be altered which is a good start (thanks Doug). What do we do from here? Dave M. Dan Chang wrote: > Doug, > > Thank you for promptly identifying the changes needed. To get our > implementation going, I need a revised ObjectCore.bat as soon as >possible > (with due process of course). The changes to the specification can >be done > at your earliest convenience. > > 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: Andrew Watson , Dan Chang/Santa > nisys.com> cc: Pete Rivett , cwm-rtf@omg.org, > "'Juergen Boldt'" > 07/26/01 10:23 Subject: RE: issue >4398 -- URGENT CWM RTF issue > AM > > > > Andrew, > > If you decide to declare #4408 urgent, the following changes will be needed > to the spec to re-install the taggedValue reference. > > In document ad/01-02-01: > > (1) On page 7-80, following the definition of the 'namespace' >reference and > before the "Constraints" subheading, add: > > taggedValue > > References the set of TaggedValue instances that extend >the > ModelElement. > > class: TaggedValue > defined by: TaggedElement::taggedValue > multiplicity: zero or more > inverse: TaggedValue::modelElement > > (2) On pages 7-67 and 7-68, merge Figure 7-3-1 and Figure 7-3-3 into >a new > Figure 7-3-1 that contains all the elements from both original >figures > (there will no longer be a Figure 7-3-3). [Note: the absence of the > taggedValue reference on ModelElement allowed these figures to be >drawn > separately. With its return, the figure must be merged.] > > (3) On page 7-67, remove the last sentence of the second paragraph >on the > page. [Note: This sentence references "Figure 7-4" and should have > referenced "Figure 7-3-3", making this a typographically convenient > deletion.] > > Also, Andrew, to support that claim that the departure of >taggedValue from > ModelElement was an editorial error, notice that the description of >the > inverse reference, TaggedValue::modelElement on page 7-88, shows an inverse > named "ModelElement::taggedValue". I'm the apparent source of this >faux > pas, > and I believe the absence of ModelElement::taggedValue was simply an > editorial error, probably resulting from the fact the TaggedValue >was at > one > point located in another package, in which case, the taggedValue reference > was correctly removed for the reasons associated with Issue #4398. >It > simply failed to get put back in correctly when TaggedValue >subsequently > returned to the same package (at the last minute!) as ModelElement. > > My vote: It's a typo, not an urgent issue. > > Hope this helps, > Doug Tolbert > > -----Original Message----- > From: Andrew Watson [mailto:andrew@omg.org] > Sent: Thursday, July 26, 2001 9:25 AM > To: Dan Chang > Cc: Pete Rivett; cwm-rtf@omg.org; 'Juergen Boldt' > Subject: RE: issue 4398 -- URGENT CWM RTF issue > > Dan, > > You wrote (to Pete Rivett): > > > I have no objection to separating the two missing references as >two > > issues. > > > > If so, the missing tagValue reference on ModelElement is urgent >and needs > > to be fixed immediately. If not, it will inhibit our ability to >support > > CWM 1.0. > > Sorry to be late to the party - I was out of email contact on >Tuesday > afternoon and Wednesday. I've spent some of this morning catching up >with > this issue. As I understand it, we now have two issues: > > Issue 4398 > > 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.) > > Issue 4408 > > ModelElement is missing a "taggedValue" reference to TaggedValue. > (ModelElement owns TaggedValue. StereoType also owns TaggedValue >and has > a > requiredTag reference to TaggedValue.) > > I don't believe anyone is advocating declaring 4398 as Urgent, so >I'm not > going to worry about it. > > As to issue 4408: I haven't checked the source documents, but I understand > that the "taggedValue" reference was present in the adopted >submission, but > had been dropped by the time this was turned into the CWM 1.0 > specification. There has been some discussion about whether this >happened > deliberately (as the result of an issue resolution in the CWM FTF) >or > accidentally. If it were abolutely clear that this change was an >editing > error, I could declare the fix editorial, and just make it >so. However, > since there's been discussion on this point, I cannot unilaterally >make > this decision. It will have to be resolved by the RTF as an issue, >via a > vote. > > Next question - is it urgent? My litmus test for this is "Are there >any > implementers that need to know the answer immediately in order to complete > their products?". If there's someone who can put their hand on their heart > and answer "Yes", then I'll make it urgent. If not, it'll just stay >as a > Plain Old Issue, to be resolved (or not) sometime before the expiry >of the > RTF. > > Any takers? > > Earlier, John Poole wrote: > > > I am very concerned about this "irreversability" of an urgent >change > > request. > > Fair enough - but do bear in mind that it's considered Bad Form to reverse > the outcome of *any* issue resolution. The special note about not reversing > Urgent Resolutions is just to reinforce this general principle, >bearing in > mind that the outcome is likely to have been immediately bound into >code. > > BTW, if I am going to declare this as Urgent, I'll need to identify >the > exact wording changes necessary for my default resolution - if this becomes > necessary, I'd appreciate help here. > > Thanks, > > Andrew