Issue 4408: taggedValue reference is missing from ModelElement (cwm-rtf) Source: International Business Machines (Dr. Daniel T. Chang, dtchang@us.ibm.com) Nature: Revision Severity: Critical Summary: The taggedValue reference is missing from ModelElement, which existed in the CWM Adapted Specification. This is an error and must be corrected immediately. TaggedValue is a critical, light-weight extension mechanism and is used extensively in our implementation of CWM. Without the taggedValue reference on ModelElement, we will not be able to support CWM 1.0. (This is a revised write-up for issue #4408.) Resolution: see below Revised Text: In the CWM Rose model (document ad/01-02-07), add the attribute ModelElement::taggedValue with of type "TaggedValue" and stereotype "reference". Set the rose2mof.multiplicity property to "0..n" on the MOF tab of the specification sheet, and check the "derived" box on the Detail tab. In the CWM XML file (document ad/01-02-03), insert the following text following the definition of the ModelElement.namespace reference on line 74 and preceding the end tag for Model:Namespace.contents on line 75 (note that values '<<id>>' are created by the generation software will be added during generation of the file): <Model:Reference xmi.id='<<id>>' name='clientDependency' annotation='' scope='instance_level' visibility='public_vis' isChangeable='true' type='<<id>>' referencedEnd='<<id>>'> <Model:StructuralFeature.multiplicity> <XMI.field>0</XMI.field> <!-- lower --> <XMI.field>-1</XMI.field> <!-- upper --> <XMI.field>false</XMI.field> <!-- is_ordered --> <XMI.field>true</XMI.field> <!-- is_unique --> </Model:StructuralFeature.multiplicity> </Model:Reference> In the CWM IDL file (document ad/01-02-06), insert the following in the definition of Interface ModelElement before line 159 (which contains the text "}; // end of interface ModelElement") in the file core.idl: TaggedValueSet tagged_value () raises (Reflective::MofError); void set_tagged_value (in TaggedValueSet new_value) raises (Reflective::MofError); void unset_tagged_value () raises (Reflective::MofError); void add_tagged_value (in TaggedValue new_element) raises (Reflective::MofError); void modify_tagged_value ( in TaggedValue old_element, in TaggedValue new_element) raises (Reflective::NotFound, Reflective::MofError); void remove_tagged_value (in TaggedValue old_element) raises (Reflective::NotFound, Reflective::MofError); In the formal specification (document formal/2001-10-01, page 4-16), following the definition of the "namespace" reference and before the "Constraints" subheading, add description of the taggedValue, with the text taggedValue References the set of taggedValue instances that extend the ModelElement. class: TaggedValue defined by: TaggedElement::taggedValue multiplicity: zero or more inverse: TaggedValue::modelElement In the formal specification (document formal/2001-10-01) remove the last sentence of the second paragraph on page 4-3. The removed text is "Figure 4-4 on page 4-4 contains classes and associations that provide generic extension mechanisms to existing metamodels." In the formal specification (document formal/2001-10-01), remove Figure 4-4 on page 4-4 in its entirety, including the figure caption. The figure removed is Actions taken: July 24, 2001: received issue July 24, 2001: closed issue July 25, 2001: re-opened issue, part 2 of issue 4398 May 13, 2002: closed issue Discussion: The default resolution will be to apply the following changes to the CWM 1.0 specification, 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.] End of Annotations:===== From: webmaster@omg.org Message-Id: <200107241813.f6OIDst12523@emerald.omg.org> Date: 24 Jul 2001 14:15:34 -0400 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: Z48!!#'He9=#Ee98T~e9 Name: Dan Chang Company: IBM mailFrom: dtchang@us.ibm.com Notification: No Specification: Common Warehouse Metamodel (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: Critical HTTP User Agent: Mozilla/4.61 [en] (WinNT; U) Description Two references, supplierDependency and taggedValue, are missing from ModelElement, which existed in the CWM Adapted Specification. There was no issue raised to the CWM FTF to request such removal. This removal is not justified and makes it extremely difficult, if not impossible, to migrate existing CWM implementation based on the CWM Adapted Specification to CWM 1.0. They should be put back immediately. From: webmaster@omg.org Message-Id: <200107252052.f6PKqIt19531@emerald.omg.org> Date: 25 Jul 2001 16:53:53 -0400 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: -Y"e9]i!e9MI]d9*$~!! 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: Critical HTTP User Agent: Mozilla/4.61 [en] (WinNT; U) Description The taggedValue reference is missing from ModelElement, which existed in the CWM Adapted Specification. This is an error and must be corrected immediately. TaggedValue is a critical, light-weight extension mechanism and is used extensively in our implementation of CWM. Without the taggedValue reference on ModelElement, we will not be able to support CWM 1.0. (This is a revised write-up for issue #4408.) X-Sender: andrew@192.67.184.65 Message-Id: In-Reply-To: Mime-Version: 1.0 Date: Thu, 26 Jul 2001 17:25:09 +0100 To: "Dan Chang" From: Andrew Watson Subject: RE: issue 4398 -- URGENT CWM RTF issue Cc: "Pete Rivett" , cwm-rtf@omg.org, "'Juergen Boldt'" Content-Type: text/plain; charset="us-ascii" X-UIDL: `;E!!F'pd9QbLe99\""! 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 Subject: issue 4408 -- URGENT CWM RTF issue To: Andrew Watson Cc: cwm-rtf@omg.org, "'Juergen Boldt'" , "Pete Rivett" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Dan Chang" Date: Thu, 26 Jul 2001 10:13:25 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/26/2001 11:13:29 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: _&*!!hm>e9)A6!!lJ*e9 Andrew, The text of Issue 4408 should read as follows (copied verbatim from the CWM RTF issues page): The taggedValue reference is missing from ModelElement, which existed in the CWM Adapted Specification. This is an error and must be corrected immediately. TaggedValue is a critical, light-weight extension mechanism and is used extensively in our implementation of CWM. Without the taggedValue reference on ModelElement, we will not be able to support CWM 1.0. (This is a revised write-up for issue #4408.) So, to your litmus test: "Are there any implementers that need to know the answer immediately in order to complete their products?",my answer is "yes". We are upgrading the CWM implementation in our DB2 DWC (first released in V 7.1 last January) from the CWM Adapted Specification to CWM 1.0. Right now, our code cannot compile without this fix. (BTW, we have managed to resolve all compilation errors caused by the migration except for this). Also, for clarification, all "discussion about whether this happened deliberately (as the result of an issue resolution in the CWM FTF) or accidentally" had to do with issue #4398. I believe everyone in the CWM RTF agree that: "this change was an editing error". Theretofore, I would appreciate if you can "declare the fix editorial, and just make it so." If anyone does not agree with this, please speak up. Thanks, Andrew. 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 Andrew Watson cc: "Pete Rivett" , cwm-rtf@omg.org, "'Juergen Boldt'" 07/26/01 09:25 Subject: RE: issue 4398 -- URGENT CWM RTF issue AM 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 From: "Tolbert, Doug M" To: Andrew Watson , Dan Chang Cc: Pete Rivett , cwm-rtf@omg.org, "'Juergen Boldt'" Subject: RE: issue 4398 -- URGENT CWM RTF issue Date: Thu, 26 Jul 2001 12:23:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: _DCe9(-nd9F=Ce9#C/e9 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 Subject: RE: issue 4398 -- URGENT CWM RTF issue To: "Tolbert, Doug M" Cc: Andrew Watson , cwm-rtf@omg.org, "'Juergen Boldt'" , Pete Rivett X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Dan Chang" Date: Thu, 26 Jul 2001 10:38:17 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/26/2001 11:38:19 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: ~QQd9[$Od9W_/!!:Y9e9 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 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 From: John_Poole@hyperion.com Subject: RE: issue 4398 -- URGENT CWM RTF issue To: Andrew Watson Cc: "Dan Chang" , "Pete Rivett" , cwm-rtf@omg.org, "'Juergen Boldt'" Date: Thu, 26 Jul 2001 13:44:53 -0400 Message-ID: X-MIMETrack: Serialize by Router on Stmfd-Gateway1/na/Hyperion(Release 5.0.5 |September 22, 2000) at 07/26/2001 01:45:13 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: 3#'!!*9&!!GW\d9oTNe9 Andrew, I fully appreciate the fact that it is "bad form" to reverse any issue resolution, which is precisely why I was opposed to treating this as an urgent issue (i.e., not that it isn't important to fix an editorial error, but with greater opportunity for due-process, there's less chance of making an irreversible mistake, as well as less chance of exhibiting "bad form" and other socially-unacceptable behaviors). Given your offer below, Hyperion's vote is: Declare the fix editorial and non-urgent. Regards, John Andrew Watson on 07/26/2001 12:25:09 PM 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 From: "Tolbert, Doug M" To: David Mellor , Dan Chang Cc: Andrew Watson , cwm-rtf@omg.org, "'Juergen Boldt'" , Pete Rivett Subject: RE: issue 4398 -- URGENT CWM RTF issue Date: Thu, 26 Jul 2001 13:15:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: C/Qd99:+e9bmid9`~3e9 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 From: "Pete Rivett" To: "'Dan Chang'" , "'Andrew Watson'" Cc: , "'Juergen Boldt'" , "'Jeffrey Mischkinsky'" , Subject: RE: issue 4408 -- URGENT CWM RTF issue Date: Thu, 26 Jul 2001 19:32:23 +0100 Message-ID: <004701c11601$50f42340$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: kj*!!,((e9`V1e9V?6e9 With significant reservations (see below) I'm in agreement for this *very specific* case that the issue does not need to proceed to a formal RTF vote for resolution, and am happy with Doug's proposed changes. I have a reservation and a caveat though: A) The reservation I'm concerned about the definition and associated process of 'editorial' changes. I searched the OMG P&P and the word did not appear at all. My general understanding (through involvement in MOF and XMI RTFs) had been that an editorial change affected only the explanatory documentation and not the substance of the specification: this is obviously not the case here. And though the problem could be said to be the result of an 'editorial' mistake (something was accidentally left out by the editor), it does not necessarily follow that the *fix* can be classed as 'editorial'. 'Editorial' is being used in 2 quite different ways IMHO. My main concern is about precedent: that other, less-desirable changes, could sneak through this route. It might be that something was accidentally omitted in a version of a submission but that the voters were happy with the omission (and would have objected/voted against had the omission not happened). And implementors could have proceeded on the basis of this spec. It is then not acceptable to sneak it in via this 'editorial' route simply because it was caused by a mistake. The only reason I'm going along with this now is that in effect a pseudo-RTF vote has taken place via the email discussion with sufficient (what's the quorum?) RTF members saying they're happy with the change. And I'm not one to insist on procedure for the sake of it. So, Andrew could you reassure me on this or point me to some definition and process around 'editorial' fixes. And explain how this applies to RTF business as a whole (do editorial fixes not need to be voted on individually - except as part of a new draft of the whole spec)? B) The caveat (which affects the implementation not the change itself) I'd like to repeat an earlier point I made: --> 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. <-- And this from my separate email covering it in more detail: --> A separate point is dealing with very minor changes/fixes. For example, those following CWM RTF will be aware that IBM needs an urgent fix due to an important reference (from ModelElement to Tag) having been accidentally left out of the metamodel. Assuming formal RTF agreement to the change this will result in immediate reissue of the DTD/XMI files. The question is - should this then be given a new name/URI and held in a separate directory CWM1.0.1? >From a configuration management point of view I'd say 'yes'; and in order to allow someone looking at a file to check which version it corresponds to. However this could potentially have an unwarranted impact on existing code/interchange files - especially because the change is additive so should not break anything. Maybe we can issue guidance that a change in 'minor minor' version should always be additive/never break any existing implementation - and so should be ignored in any compatibility checks unless of course you're specifically relying on the new addition. <-- 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: 26 July 2001 18:13 > To: Andrew Watson > Cc: cwm-rtf@omg.org; 'Juergen Boldt'; Pete Rivett > Subject: issue 4408 -- URGENT CWM RTF issue > > > > Andrew, > > The text of Issue 4408 should read as follows (copied > verbatim from the > CWM RTF issues page): > > The taggedValue reference is missing from ModelElement, > which existed > in the CWM Adapted Specification. This is > an error and must be corrected immediately. TaggedValue > is a critical, > light-weight extension mechanism and is used extensively in > our implementation of CWM. Without the taggedValue reference on > ModelElement, we will not be able to support CWM 1.0. > (This is a revised write-up for issue #4408.) > > So, to your litmus test: "Are there any implementers that > need to know the > answer immediately in order to complete their products?",my answer is > "yes". We are upgrading the CWM implementation in our DB2 DWC (first > released in V 7.1 last January) from the CWM Adapted > Specification to CWM > 1.0. Right now, our code cannot compile without this fix. > (BTW, we have > managed to resolve all compilation errors caused by the > migration except > for this). > > Also, for clarification, all "discussion about whether this happened > deliberately (as the result of an issue resolution in the CWM FTF) or > accidentally" had to do with issue #4398. I believe everyone > in the CWM RTF > agree that: > "this change was an editing error". > > Theretofore, I would appreciate if you can "declare the fix > editorial, and > just make it so." > > If anyone does not agree with this, please speak up. > > Thanks, Andrew. > > 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 > > > > > Andrew Watson > > Chang/Santa Teresa/IBM@IBMUS > g> cc: "Pete > Rivett" , > cwm-rtf@omg.org, > "'Juergen Boldt'" > 07/26/01 09:25 Subject: RE: > issue 4398 -- URGENT CWM RTF issue > AM > > > > > > > > > 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 > > > > > > > > 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 From: "Tolbert, Doug M" To: John_Poole@hyperion.com, "Tolbert, Doug M" Cc: David Mellor , Dan Chang , Andrew Watson , cwm-rtf@omg.org, "'Juergen Boldt'" , Pete Rivett Subject: RE: issue 4398 -- URGENT CWM RTF issue Date: Thu, 26 Jul 2001 18:24:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ]c@!!"/"!!DB$!!L2/e9 John, While I admit to having lots of reservations about tagged values and stereotypes because they are used as a light-weight subtyping mechanism, and while I recall thinking about this when deciding whether to include them in the model in the first place, I'm pretty sure that I decided at the time to suppress my own dislike of them and to put them into the model (you, I think, were urging me to do so). I really think I just forgot to add them back in when we re-merged the Extension and Core packages at the January editors meeting at Unisys. Too bad, though, the other makes a better story! Doug -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Thursday, July 26, 2001 2:44 PM To: Tolbert, Doug M Cc: David Mellor; Dan Chang; Andrew Watson; cwm-rtf@omg.org; 'Juergen Boldt'; Pete Rivett Subject: RE: issue 4398 -- URGENT CWM RTF issue 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 From: "Pete Rivett" To: , "'Tolbert, Doug M'" Cc: "'David Mellor'" , "'Dan Chang'" , "'Andrew Watson'" , , "'Juergen Boldt'" , "'Pete Rivett'" Subject: RE: issue 4398 -- URGENT CWM RTF issue Date: Fri, 27 Jul 2001 01:16:59 +0100 Message-ID: <005401c11631$74a05e00$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: I1&!!f!%"![RIe99jH!! John makes a valid point: indeed the MOF Model does not have such a reference for this reason. The following comes from the MOF spec (section 3.4.23): --> Note - In defining new Tag categories, the meta-modeler should take account of the fact that the MOF Model has no reference for navigating from a ModelElement to its attached Tags. This allows one to attach Tags to elements of a "frozen" meta-model. On the other hand, makes it harder for a "client" of the meta-model objects to find the Tags for an element. One option is to require relevant Tags to be Contained by the elements they AttachTo, or their parents. <-- The need for separate tags in MOF has been reinforced very recently in discussions with Steve Brodsky about how to apply XMI 2.0. I challenged Steve about the fact that XMI 2.0 customization works by adding tags to the metamodel elements (instances of the MOF model) - for example whether an Attribute value should be exported as an XML Element or XML Attribute. I felt that this 'polluted' the metamodel and made it hard to apply different parameters to the same metamodel in different contexts. He rightly pointed out that, because there is no inverse reference from MOF ModelElement to its tags, that the customization tags could live in a totally separate MOF Package Extent (repository) and be applied without actually changing the original metamodel. So one could create a number of different customization sets in different packages all referencing the same metamodel, and nominate which to use by clustering the metamodel with one of the tag packages in a different top level package. [Note - I suggested in the XMI 2.0 evaluation report that the above be documented as a guideline in the spec]. The question is, do the same considerations apply to CWM (at the M2 level)? UML *does* have the reference from Model Element to tags - but it's arguable that UML models are more self-contained and narrower in scope than CWM Models? In particular a 'complete' CWM model for a whole datawarehouse is likely to involve many different tools (unlike UML) - and if those tools need hints/tags as to how to process elements created by other tools then this would be an argument in favor of *not* having the link from ModelElement to Tag. I've no experience with actually applying tags in CWM - what do they tend to be used for? Is it likely there's a need to attach them to physically separate objects or ones not 'owned' by the person/tool applying the tag? Presumably Dan at least has some examples. Pete > -----Original Message----- > From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] > Sent: 26 July 2001 22:44 > To: Tolbert, Doug M > Cc: David Mellor; Dan Chang; Andrew Watson; cwm-rtf@omg.org; 'Juergen > Boldt'; Pete Rivett > Subject: RE: issue 4398 -- URGENT CWM RTF issue > > > > > 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 > > > > > > 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. X-Sender: andrew@192.67.184.65 Message-Id: In-Reply-To: Mime-Version: 1.0 Date: Fri, 27 Jul 2001 15:06:03 +0100 To: "Dan Chang" From: Andrew Watson Subject: Issue 4408 declared Urgent Cc: "Pete Rivett" , cwm-rtf@omg.org, "'Jeffrey Mischkinsky'" , "'Juergen Boldt'" , sridhar.iyengar2@unisys.com Content-Type: text/plain; charset="us-ascii" X-UIDL: Tc+!!7~#e9=[S!!YNRd9 Dan & members of the CWM RTF, Thanks to everyone who's voiced an opinion on the status of issue 4408 (and especially to Doug, whose default resolution I've lifted verbatim). The active discussion of whether the fix is editorial or not means, for my point of view, that it is not. It therefore remains as an issue, so that the RTF can vote on how to resolve it. Since I am being told that there's at least one implementer who needs a resolution quickly in order to compile their code, I'm going to declare it as urgent, in accordance with the procedure laid out in section 4.4.1.5 of the P&P (pp/99-11-02). The summary of this issue, and also the thread of discussion since it was received, can be found here: http://cgi.omg.org/issues/issue4408.txt The issue will be voted on by the CWM RTF. The default resolution will be to apply the follwing changes to the CWM 1.0 speciication, 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.] This default resolution will be applied to the CWM 1.0 spec (ad/01-02-01) if and only if the CWM RTF fails to generate an alternative resolution within 14 days (i.e. by Fri 10th August 2001). It is not necessarily the most desirable resolution. Even if the RTF decides to apply the default resolution, I recommed that they make this decision by a recorded vote. I strongly recommend that any proposed resolutions aired on the RTF mailing list include the *EXACT* wording of the proposed amendment, so that everyone is clear what they're voting on. Thanks, Andrew From: John_Poole@hyperion.com Subject: RE: issue 4398 -- URGENT CWM RTF issue To: "Pete Rivett" Cc: "'Tolbert, Doug M'" , "'David Mellor'" , "'Dan Chang'" , "'Andrew Watson'" , , "'Juergen Boldt'" , "'Pete Rivett'" Date: Fri, 27 Jul 2001 13:07:55 -0400 Message-ID: X-MIMETrack: Serialize by Router on Stmfd-Gateway1/na/Hyperion(Release 5.0.5 |September 22, 2000) at 07/27/2001 01:08:01 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: 6=Le9mY>e9THZ!!\db!! Pete, Thanks for the additional information. Apparently, I wasn't as off-base in my reasoning as I'd thought. And you've raised some very good points. In using CWM for metadata interchange within the Hyperion product environment, we use tagged values and stereotypes to attach product-specific semantics to certain CWM metaobjects. For example, Hyperion Essbase needs to be able to discriminate semantically between certain instances of Attribute attached to an OLAP Dimension. These semantics have meaning for the Essbase product only, and the stereotype instances used to label these attributes are not expected to be understood by any products other than certain Hyperion products that are Essbase-aware (i.e., they should be ingnored by any other vendors' products that might consume the OLAP metadata). So, from an interchange perspective, having ModelElement::TaggedValue and ModelElement::Stereotype references present in instances of ModelElement (more precisely, instances of the various subclasses of ModelElement) is very convenient, because it means that, once I've hydrated my imported model, I can efficiently peruse a given ModelElement for its Stereotypes and TaggedValues; i.e., for certain subclasses of ModelElement, my import logic is specifically searching for very specific Stereotypes and TaggedValues that make sense/have meaning only for my particular import logic. So from an interchange perpective, I don't see much controversy in ModelElements having knowledge of any Stereotypes and TaggedValues that might be attached to them. If a given implementation does not understand a particular Stereotype or TaggedValue, it simply ignores it. I think the controversy arises when one looks at a model from the perspective of repositoried metadata, rather than interchange. As you mentioned (and quoted from the MOF spec), a model stored in some given repository extent A should have no knowledge of any Stereotypes or TaggedValues defined within some other extent B. Those Stereotypes/TaggedValues have meaning within the local context of extent B only. When exporting the combined model from extent B (extent A model + extent B extensions), the extensions need to be included as part of the interchange, and must be available to the receiving party, whether or not they have meaning for the receiving the party. So there are two separate and distinct perspectives (neither one any more or less correct than the other) on the presence of these references in ModelElement, one from the viewpoint of a federated repository environment (which has its own particular requirements) and the other from the viewpoint of interchange in a collaborative computing environment, which has a somewhat different set of requirements. I am not going to argue the merits of one viewpoint versus the other; both are right, both have their own unique needs. I am of the opinion that if we are going to re-instate ModelElement::TaggedValue to ModelElement, we should be consistent and also include ModelElement::Stereotype, all other philosophical debates notwithstanding. Regards, John "Pete Rivett" on 07/26/2001 08:16:59 PM To: John Poole/na/Hyperion@Hyperion, "'Tolbert, Doug M'" cc: "'David Mellor'" , "'Dan Chang'" , "'Andrew Watson'" , , "'Juergen Boldt'" , "'Pete Rivett'" Subject: RE: issue 4398 -- URGENT CWM RTF issue John makes a valid point: indeed the MOF Model does not have such a reference for this reason. The following comes from the MOF spec (section 3.4.23): --> Note - In defining new Tag categories, the meta-modeler should take account of the fact that the MOF Model has no reference for navigating from a ModelElement to its attached Tags. This allows one to attach Tags to elements of a "frozen" meta-model. On the other hand, makes it harder for a "client" of the meta-model objects to find the Tags for an element. One option is to require relevant Tags to be Contained by the elements they AttachTo, or their parents. <-- The need for separate tags in MOF has been reinforced very recently in discussions with Steve Brodsky about how to apply XMI 2.0. I challenged Steve about the fact that XMI 2.0 customization works by adding tags to the metamodel elements (instances of the MOF model) - for example whether an Attribute value should be exported as an XML Element or XML Attribute. I felt that this 'polluted' the metamodel and made it hard to apply different parameters to the same metamodel in different contexts. He rightly pointed out that, because there is no inverse reference from MOF ModelElement to its tags, that the customization tags could live in a totally separate MOF Package Extent (repository) and be applied without actually changing the original metamodel. So one could create a number of different customization sets in different packages all referencing the same metamodel, and nominate which to use by clustering the metamodel with one of the tag packages in a different top level package. [Note - I suggested in the XMI 2.0 evaluation report that the above be documented as a guideline in the spec]. The question is, do the same considerations apply to CWM (at the M2 level)? UML *does* have the reference from Model Element to tags - but it's arguable that UML models are more self-contained and narrower in scope than CWM Models? In particular a 'complete' CWM model for a whole datawarehouse is likely to involve many different tools (unlike UML) - and if those tools need hints/tags as to how to process elements created by other tools then this would be an argument in favor of *not* having the link from ModelElement to Tag. I've no experience with actually applying tags in CWM - what do they tend to be used for? Is it likely there's a need to attach them to physically separate objects or ones not 'owned' by the person/tool applying the tag? Presumably Dan at least has some examples. Pete > -----Original Message----- > From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] > Sent: 26 July 2001 22:44 > To: Tolbert, Doug M > Cc: David Mellor; Dan Chang; Andrew Watson; cwm-rtf@omg.org; 'Juergen > Boldt'; Pete Rivett > Subject: RE: issue 4398 -- URGENT CWM RTF issue > > > > > 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 > > > > > > 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: Default Resolution for Issue 4408 To: "Dan Chang" Cc: Andrew Watson , cwm-rtf@omg.org, "'Jeffrey Mischkinsky'" , "'Juergen Boldt'" , "Pete Rivett" , sridhar.iyengar2@unisys.com Date: Fri, 27 Jul 2001 13:21:51 -0400 Message-ID: X-MIMETrack: Serialize by Router on Stmfd-Gateway1/na/Hyperion(Release 5.0.5 |September 22, 2000) at 07/27/2001 01:21:55 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: mPVd9n9#!!$N`d9N1 on 07/27/2001 12:50:56 PM To: Andrew Watson cc: cwm-rtf@omg.org, "'Jeffrey Mischkinsky'" , "'Juergen Boldt'" , "Pete Rivett" , sridhar.iyengar2@unisys.com Subject: Re: Issue 4408 declared Urgent Andrew, Thank you for the default resolution, as drafted by Doug. I agree with your suggestion and will propose to the CWM RTF to vote on it. Thank you for your prompt action. 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 Andrew Watson cc: "Pete Rivett" , cwm-rtf@omg.org, "'Jeffrey Mischkinsky'" 07/27/01 07:06 , "'Juergen Boldt'" AM , sridhar.iyengar2@unisys.com Subject: Issue 4408 declared Urgent Dan & members of the CWM RTF, Thanks to everyone who's voiced an opinion on the status of issue 4408 (and especially to Doug, whose default resolution I've lifted verbatim). The active discussion of whether the fix is editorial or not means, for my point of view, that it is not. It therefore remains as an issue, so that the RTF can vote on how to resolve it. Since I am being told that there's at least one implementer who needs a resolution quickly in order to compile their code, I'm going to declare it as urgent, in accordance with the procedure laid out in section 4.4.1.5 of the P&P (pp/99-11-02). The summary of this issue, and also the thread of discussion since it was received, can be found here: http://cgi.omg.org/issues/issue4408.txt The issue will be voted on by the CWM RTF. The default resolution will be to apply the follwing changes to the CWM 1.0 speciication, 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.] This default resolution will be applied to the CWM 1.0 spec (ad/01-02-01) if and only if the CWM RTF fails to generate an alternative resolution within 14 days (i.e. by Fri 10th August 2001). It is not necessarily the most desirable resolution. Even if the RTF decides to apply the default resolution, I recommed that they make this decision by a recorded vote. I strongly recommend that any proposed resolutions aired on the RTF mailing list include the *EXACT* wording of the proposed amendment, so that everyone is clear what they're voting on. Thanks, Andrew From: "Tolbert, Doug M" To: Dan Chang , cwm-rtf@omg.org Cc: Andrew Watson , "'Jeffrey Mischkinsky'" , "'Juergen Boldt'" , Pete Rivett , "Iyengar, Sridhar" Subject: RE: Issue 4408 declared Urgent Date: Fri, 27 Jul 2001 12:28:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: oPPd91GHe9UfEe9hdJ!! Dan, before we vote, I think you should consider the proposal amend the resolution to include ModelElement::stereotype as well. If you need to, you can consider this a motion to amend accordingly. You might poll JohnP for a second. Text of spec change for this follows shortly. Doug -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Friday, July 27, 2001 10:23 AM To: cwm-rtf@omg.org Cc: Andrew Watson; 'Jeffrey Mischkinsky'; 'Juergen Boldt'; Pete Rivett; sridhar.iyengar2@unisys.com Subject: Re: Issue 4408 declared Urgent Team, I hereby motion that we vote on Andrew's default resolution. The motion is seconded by Doug. For those of you who are a voting member, please cast your vote by next Wednesday, August 1. Thanks. 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 Dan Chang To: Andrew Watson 07/27/01 09:50 cc: cwm-rtf@omg.org, "'Jeffrey Mischkinsky'" AM , "'Juergen Boldt'" , "Pete Rivett" , sridhar.iyengar2@unisys.com From: Dan Chang/Santa Teresa/IBM@IBMUS Subject: Re: Issue 4408 declared Urgent(Document link: Dan Chang) Andrew, Thank you for the default resolution, as drafted by Doug. I agree with your suggestion and will propose to the CWM RTF to vote on it. Thank you for your prompt action. 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 Andrew Watson cc: "Pete Rivett" , cwm-rtf@omg.org, "'Jeffrey Mischkinsky'" 07/27/01 07:06 , "'Juergen Boldt'" AM , sridhar.iyengar2@unisys.com Subject: Issue 4408 declared Urgent Dan & members of the CWM RTF, Thanks to everyone who's voiced an opinion on the status of issue 4408 (and especially to Doug, whose default resolution I've lifted verbatim). The active discussion of whether the fix is editorial or not means, for my point of view, that it is not. It therefore remains as an issue, so that the RTF can vote on how to resolve it. Since I am being told that there's at least one implementer who needs a resolution quickly in order to compile their code, I'm going to declare it as urgent, in accordance with the procedure laid out in section 4.4.1.5 of the P&P (pp/99-11-02). The summary of this issue, and also the thread of discussion since it was received, can be found here: http://cgi.omg.org/issues/issue4408.txt The issue will be voted on by the CWM RTF. The default resolution will be to apply the follwing changes to the CWM 1.0 speciication, 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.] This default resolution will be applied to the CWM 1.0 spec (ad/01-02-01) if and only if the CWM RTF fails to generate an alternative resolution within 14 days (i.e. by Fri 10th August 2001). It is not necessarily the most desirable resolution. Even if the RTF decides to apply the default resolution, I recommed that they make this decision by a recorded vote. I strongly recommend that any proposed resolutions aired on the RTF mailing list include the *EXACT* wording of the proposed amendment, so that everyone is clear what they're voting on. Thanks, Andrew From: "Tolbert, Doug M" To: "Tolbert, Doug M" , Dan Chang , cwm-rtf@omg.org Cc: Andrew Watson , "'Jeffrey Mischkinsky'" , "'Juergen Boldt'" , Pete Rivett , "Iyengar, Sridhar" Subject: RE: Issue 4408 declared Urgent Date: Fri, 27 Jul 2001 12:38: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: _?U!!:(n!!O<*!!&m^d9 Proposed spec changes to add ModelElement::stereotype to the resolution. Number follows in sequence with Andrew's draft resolution below. (4) On page 7-80, following the definition of the 'namespace' reference and preceeding the 'taggedValue' reference added in (1), add: stereotype References the set of Stereotype instances that extend the ModelElement. class: Stereotype defined by: StereotypedElement::extendedElement multiplicity: zero or more inverse: Stereotype::extendedElement Note that point (2) already implicitly addresses the figure representation for Stereotype as well as TaggedValue and does not need to be altered. Doug -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Friday, July 27, 2001 10:28 AM To: Dan Chang; cwm-rtf@omg.org Cc: Andrew Watson; 'Jeffrey Mischkinsky'; 'Juergen Boldt'; Pete Rivett; Iyengar, Sridhar Subject: RE: Issue 4408 declared Urgent Dan, before we vote, I think you should consider the proposal amend the resolution to include ModelElement::stereotype as well. If you need to, you can consider this a motion to amend accordingly. You might poll JohnP for a second. Text of spec change for this follows shortly. Doug -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Friday, July 27, 2001 10:23 AM To: cwm-rtf@omg.org Cc: Andrew Watson; 'Jeffrey Mischkinsky'; 'Juergen Boldt'; Pete Rivett; sridhar.iyengar2@unisys.com Subject: Re: Issue 4408 declared Urgent Team, I hereby motion that we vote on Andrew's default resolution. The motion is seconded by Doug. For those of you who are a voting member, please cast your vote by next Wednesday, August 1. Thanks. 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 Dan Chang To: Andrew Watson 07/27/01 09:50 cc: cwm-rtf@omg.org, "'Jeffrey Mischkinsky'" AM , "'Juergen Boldt'" , "Pete Rivett" , sridhar.iyengar2@unisys.com From: Dan Chang/Santa Teresa/IBM@IBMUS Subject: Re: Issue 4408 declared Urgent(Document link: Dan Chang) Andrew, Thank you for the default resolution, as drafted by Doug. I agree with your suggestion and will propose to the CWM RTF to vote on it. Thank you for your prompt action. 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 Andrew Watson cc: "Pete Rivett" , cwm-rtf@omg.org, "'Jeffrey Mischkinsky'" 07/27/01 07:06 , "'Juergen Boldt'" AM , sridhar.iyengar2@unisys.com Subject: Issue 4408 declared Urgent Dan & members of the CWM RTF, Thanks to everyone who's voiced an opinion on the status of issue 4408 (and especially to Doug, whose default resolution I've lifted verbatim). The active discussion of whether the fix is editorial or not means, for my point of view, that it is not. It therefore remains as an issue, so that the RTF can vote on how to resolve it. Since I am being told that there's at least one implementer who needs a resolution quickly in order to compile their code, I'm going to declare it as urgent, in accordance with the procedure laid out in section 4.4.1.5 of the P&P (pp/99-11-02). The summary of this issue, and also the thread of discussion since it was received, can be found here: http://cgi.omg.org/issues/issue4408.txt The issue will be voted on by the CWM RTF. The default resolution will be to apply the follwing changes to the CWM 1.0 speciication, 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.] This default resolution will be applied to the CWM 1.0 spec (ad/01-02-01) if and only if the CWM RTF fails to generate an alternative resolution within 14 days (i.e. by Fri 10th August 2001). It is not necessarily the most desirable resolution. Even if the RTF decides to apply the default resolution, I recommed that they make this decision by a recorded vote. I strongly recommend that any proposed resolutions aired on the RTF mailing list include the *EXACT* wording of the proposed amendment, so that everyone is clear what they're voting on. Thanks, Andrew From: "Tolbert, Doug M" To: John_Poole@hyperion.com, Dan Chang Cc: Andrew Watson , cwm-rtf@omg.org, "'Jeffrey Mischkinsky'" , "'Juergen Boldt'" , Pete Rivett , "Iyengar, Sridhar" Subject: RE: Default Resolution for Issue 4408 Date: Fri, 27 Jul 2001 12:25:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: >j!!9!Pe9 I've already suggested to Dan separately that the CWM RTF ought to consider adding this reference as well as an extension to the default resolution and have already volunteered to draft the needed text (it will be very similar to the taggedValue text) when the time comes. Doug -----Original Message----- From: John_Poole@hyperion.com [mailto:John_Poole@hyperion.com] Sent: Friday, July 27, 2001 10:22 AM To: Dan Chang Cc: Andrew Watson; cwm-rtf@omg.org; 'Jeffrey Mischkinsky'; 'Juergen Boldt'; Pete Rivett; sridhar.iyengar2@unisys.com Subject: Re: Default Resolution for Issue 4408 As Doug had pointed out earlier, the default resolution should also include the restoration of the ModelElement::Stereotype reference to ModelElement, for the sake of consistency. But I don't believe any verbiage to this effect is included in the wording of Andrew's default resolution. Does this require raising yet another issue, or can we simply amend the default resolution, assuming everyone agrees on this point? Regards, John "Dan Chang" on 07/27/2001 12:50:56 PM To: Andrew Watson cc: cwm-rtf@omg.org, "'Jeffrey Mischkinsky'" , "'Juergen Boldt'" , "Pete Rivett" , sridhar.iyengar2@unisys.com Subject: Re: Issue 4408 declared Urgent Andrew, Thank you for the default resolution, as drafted by Doug. I agree with your suggestion and will propose to the CWM RTF to vote on it. Thank you for your prompt action. 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 Andrew Watson cc: "Pete Rivett" , cwm-rtf@omg.org, "'Jeffrey Mischkinsky'" 07/27/01 07:06 , "'Juergen Boldt'" AM , sridhar.iyengar2@unisys.com Subject: Issue 4408 declared Urgent Dan & members of the CWM RTF, Thanks to everyone who's voiced an opinion on the status of issue 4408 (and especially to Doug, whose default resolution I've lifted verbatim). The active discussion of whether the fix is editorial or not means, for my point of view, that it is not. It therefore remains as an issue, so that the RTF can vote on how to resolve it. Since I am being told that there's at least one implementer who needs a resolution quickly in order to compile their code, I'm going to declare it as urgent, in accordance with the procedure laid out in section 4.4.1.5 of the P&P (pp/99-11-02). The summary of this issue, and also the thread of discussion since it was received, can be found here: http://cgi.omg.org/issues/issue4408.txt The issue will be voted on by the CWM RTF. The default resolution will be to apply the follwing changes to the CWM 1.0 speciication, 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.] This default resolution will be applied to the CWM 1.0 spec (ad/01-02-01) if and only if the CWM RTF fails to generate an alternative resolution within 14 days (i.e. by Fri 10th August 2001). It is not necessarily the most desirable resolution. Even if the RTF decides to apply the default resolution, I recommed that they make this decision by a recorded vote. I strongly recommend that any proposed resolutions aired on the RTF mailing list include the *EXACT* wording of the proposed amendment, so that everyone is clear what they're voting on. Thanks, Andrew Subject: RE: issue 4398 -- URGENT CWM RTF issue To: John_Poole@hyperion.com Cc: "'Andrew Watson'" , cwm-rtf@omg.org, "'David Mellor'" , "'Tolbert, Doug M'" , "'Juergen Boldt'" , "Pete Rivett" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Dan Chang" Date: Fri, 27 Jul 2001 10:37:14 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 07/27/2001 11:37:15 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: TIHe9;8kd9"/>!!]~Le9 John, Please note that the Tag model in MOF and the TagValue model in UML/CWM are somewhat different. In MOF, Tags are "attached" to a ModelElement through an ordinary association. In UML/CWM a ModelElement "owns" its TaggedValues. 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: "Pete Rivett" cc: "'Tolbert, Doug M'" , "'David 07/27/01 10:07 Mellor'" , Dan Chang/Santa AM Teresa/IBM@IBMUS, "'Andrew Watson'" , , "'Juergen Boldt'" , "'Pete Rivett'" Subject: RE: issue 4398 -- URGENT CWM RTF issue Pete, Thanks for the additional information. Apparently, I wasn't as off-base in my reasoning as I'd thought. And you've raised some very good points. In using CWM for metadata interchange within the Hyperion product environment, we use tagged values and stereotypes to attach product-specific semantics to certain CWM metaobjects. For example, Hyperion Essbase needs to be able to discriminate semantically between certain instances of Attribute attached to an OLAP Dimension. These semantics have meaning for the Essbase product only, and the stereotype instances used to label these attributes are not expected to be understood by any products other than certain Hyperion products that are Essbase-aware (i.e., they should be ingnored by any other vendors' products that might consume the OLAP metadata). So, from an interchange perspective, having ModelElement::TaggedValue and ModelElement::Stereotype references present in instances of ModelElement (more precisely, instances of the various subclasses of ModelElement) is very convenient, because it means that, once I've hydrated my imported model, I can efficiently peruse a given ModelElement for its Stereotypes and TaggedValues; i.e., for certain subclasses of ModelElement, my import logic is specifically searching for very specific Stereotypes and TaggedValues that make sense/have meaning only for my particular import logic. So from an interchange perpective, I don't see much controversy in ModelElements having knowledge of any Stereotypes and TaggedValues that might be attached to them. If a given implementation does not understand a particular Stereotype or TaggedValue, it simply ignores it. I think the controversy arise