Issue 4133: Model::Contains::container return type wrong (mof-rtf) Source: DSTC (Dr. Stephen Crawley, nobody) Nature: Uncategorized Issue Severity: Summary: The "Contains" Association is defined with the "container" end having type "Namespace" and multiplicity [0..1]. According to the MOF to IDL mapping (see 5.8.10 <association_end1_name>) this means that the Model::Contains::container() operation should return a "NamespaceBag". However, the IDL in both Chapter 3 and Appendix C incorrectly declares Model::Contains::container() as returning a "Namespace". Resolution: see above Revised Text: Make the following changes to the description for the <association_end1_name> operation in 5.8.10. In the third paragraph, change "If it has bouonds of [1..1] ... " to read "If it has bounds [0..1] or [1..1] ..." Add a new paragraph after paragraph 3 that reads as follows: "The result of the operation gives the object or collection of objects related to the parameter object by a Link or Links in this Association. If the multiplicity is [1..1], the result will be a non-nill object reference. If the multiplicity is [0..1], the operation will return a non-nil object reference if there is a related object, and a nil object reference otherwise. In other cases, the operation will return a (possibly zero length) sequence of non-nil object references. If the association end being queried is ordered, the order of the contents of the returned collection is significant." Actions taken: Actions taken: January 12, 2001: received issue December 3, 2001: closed issue Discussion: The proposed resolution to this issue is to change the IDL templates to match the Model IDL. End of Annotations:===== X-Mailer: exmh version 2.1.0 09/18/1999 To: mof-rtf@omg.org, issues@omg.org Subject: Model::Contains::container return type wrong Mime-Version: 1.0 Date: Fri, 12 Jan 2001 12:49:50 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: D*Ne9m?md9&VCe9N$#e9 The "Contains" Association is defined with the "container" end having type "Namespace" and multiplicity [0..1]. According to the MOF to IDL mapping (see 5.8.10 ) this means that the Model::Contains::container() operation should return a "NamespaceBag". However, the IDL in both Chapter 3 and Appendix C incorrectly declares Model::Contains::container() as returning a "Namespace". From: "Baisley, Donald E" To: Stephen Crawley Cc: mof-rtf@omg.org Subject: RE: Model::Contains::container return type wrong Date: Fri, 12 Jan 2001 13:25:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Z&H!!A0Ne9\0,e90;Wd9 Hi Steve, I would like to propose a resolution to this "Bag" problem for MOF 1.4, and I would like to get agreement as soon as possible because I am now generating IDL for UML 1.4 which is supposed to be based on MOF 1.4. There is a real problem having the accessor for an association end return a different type than the semantically identical accessor for a corresponding reference. It is senseless to have Model::Contains::container return a different type than Model::ModelElement::container when the two operations are semantically identical. Similarly, there is a real problem having an attribute's mutator take a different type than the parameter for setting the attribute when creating an object. We have an ugly inconsistency and we need to fix it. The fix is simple. When generating types of association end accessors and create parameters we must treat 0..1 the same as 1..1. We should only append a if upper is greater than 1. There is another reason to adopt the resolution I am proposing. Not only has the MOF 1.3 IDL been generated "incorrectly" by leaving off the "Bag". The IDL for UML 1.3, CWM, and other standardized metamodels have been generated "incorrectly" in the same way. The IDL generators have so far failed to implement the ugly inconsistency. The IDL has been getting generated all along in the way I am proposing to generate it. So fixing MOF 1.4 in the way I am proposing will save a lot of trouble. Rather than change all of the IDL, let's fix the specification to match the sensible way the IDL has been getting generated. A standard specification should state what is standard practice rather than contradict standard practice with some unused and senseless practice. Let's make MOF 1.4 match the IDL generation rules that are being used for the other standards like UML and CWM. The impact of this approach is small for the MOF IDL -- there is no nonderived optional attribute and only one optional association end. But the impact is much greater for UML and CWM. The UML metamodel has many optional attributes. For example, ModelElement::name is optional. A name parameter appears in hundreds of create operations for the hundreds of subclasses of ModelElement. These name parameters have been using the Name type. Based on the MOF 1.3 specification they should all have the type NameBag. This would be laughable. It's absurd. The name attribute returns a Name. The setName operation takes a Name. But all of the create operations should take a NameBag that can contain at most one Name? It's ridiculous. Why should creation of every named ModelElement require putting the name in a NameBag to pass it to the create operation? The UML metamodel also has many optional association ends. We cannot expect people to take MOF-based IDL seriously if it needlessly imposes these Bag types all over the place. Here is my specific proposal: In the description of create_ change "When an attribute has multiplicity bounds other than [1..1]" to "When an attribute has multiplicity upper bound greater than one". In the description of change "If it has bounds of [1..1]" to "If it has an upper bound of one". These simple changes allow our IDL interfaces for MOF, UML, and CWM to be correct without change. Best regards, Don Baisley Unisys -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Thursday, January 11, 2001 6:50 PM To: mof-rtf@omg.org; issues@omg.org Subject: Model::Contains::container return type wrong The "Contains" Association is defined with the "container" end having type "Namespace" and multiplicity [0..1]. According to the MOF to IDL mapping (see 5.8.10 ) this means that the Model::Contains::container() operation should return a "NamespaceBag". However, the IDL in both Chapter 3 and Appendix C incorrectly declares Model::Contains::container() as returning a "Namespace". From: "Stephen Brodsky" Importance: Normal Subject: RE: Model::Contains::container return type wrong To: "Baisley, Donald E" Cc: Stephen Crawley , mof-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: Sender: "Stephen Brodsky" Date: Fri, 12 Jan 2001 12:57:38 -0800 X-MIMETrack: Serialize by Router on D03NM039/03/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 01/12/2001 02:16:57 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: *"Oe9bGhd9@_5e9Wo"e9 Don, I agree with your suggestion. MOF APIs should use only the upper bound multiplicity in all cases. Trying to represent lower bound multiplicites in language mappings causes considerable problems. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Baisley, Donald E" on 01/12/2001 11:25:37 AM To: Stephen Crawley cc: mof-rtf@omg.org Subject: RE: Model::Contains::container return type wrong Hi Steve, I would like to propose a resolution to this "Bag" problem for MOF 1.4, and I would like to get agreement as soon as possible because I am now generating IDL for UML 1.4 which is supposed to be based on MOF 1.4. There is a real problem having the accessor for an association end return a different type than the semantically identical accessor for a corresponding reference. It is senseless to have Model::Contains::container return a different type than Model::ModelElement::container when the two operations are semantically identical. Similarly, there is a real problem having an attribute's mutator take a different type than the parameter for setting the attribute when creating an object. We have an ugly inconsistency and we need to fix it. The fix is simple. When generating types of association end accessors and create parameters we must treat 0..1 the same as 1..1. We should only append a if upper is greater than 1. There is another reason to adopt the resolution I am proposing. Not only has the MOF 1.3 IDL been generated "incorrectly" by leaving off the "Bag". The IDL for UML 1.3, CWM, and other standardized metamodels have been generated "incorrectly" in the same way. The IDL generators have so far failed to implement the ugly inconsistency. The IDL has been getting generated all along in the way I am proposing to generate it. So fixing MOF 1.4 in the way I am proposing will save a lot of trouble. Rather than change all of the IDL, let's fix the specification to match the sensible way the IDL has been getting generated. A standard specification should state what is standard practice rather than contradict standard practice with some unused and senseless practice. Let's make MOF 1.4 match the IDL generation rules that are being used for the other standards like UML and CWM. The impact of this approach is small for the MOF IDL -- there is no nonderived optional attribute and only one optional association end. But the impact is much greater for UML and CWM. The UML metamodel has many optional attributes. For example, ModelElement::name is optional. A name parameter appears in hundreds of create operations for the hundreds of subclasses of ModelElement. These name parameters have been using the Name type. Based on the MOF 1.3 specification they should all have the type NameBag. This would be laughable. It's absurd. The name attribute returns a Name. The setName operation takes a Name. But all of the create operations should take a NameBag that can contain at most one Name? It's ridiculous. Why should creation of every named ModelElement require putting the name in a NameBag to pass it to the create operation? The UML metamodel also has many optional association ends. We cannot expect people to take MOF-based IDL seriously if it needlessly imposes these Bag types all over the place. Here is my specific proposal: In the description of create_ change "When an attribute has multiplicity bounds other than [1..1]" to "When an attribute has multiplicity upper bound greater than one". In the description of change "If it has bounds of [1..1]" to "If it has an upper bound of one". These simple changes allow our IDL interfaces for MOF, UML, and CWM to be correct without change. Best regards, Don Baisley Unisys -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Thursday, January 11, 2001 6:50 PM To: mof-rtf@omg.org; issues@omg.org Subject: Model::Contains::container return type wrong The "Contains" Association is defined with the "container" end having type "Namespace" and multiplicity [0..1]. According to the MOF to IDL mapping (see 5.8.10 ) this means that the Model::Contains::container() operation should return a "NamespaceBag". However, the IDL in both Chapter 3 and Appendix C incorrectly declares Model::Contains::container() as returning a "Namespace". X-Mailer: exmh version 2.1.0 09/18/1999 To: "Stephen Brodsky" , "Baisley, Donald E" Cc: crawley@dstc.edu.au, mof-rtf@omg.org Subject: Re: Model::Contains::container return type wrong In-Reply-To: Message from "Stephen Brodsky" of "Fri, 12 Jan 2001 12:57:38 PST." Mime-Version: 1.0 Date: Mon, 15 Jan 2001 12:45:37 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: Z<'!!Da(e9+Gk!!)$Xd9 Don, Steve, I'm inclined to agree with the proposal. But we also need to specify what is returned by an operation in the [0..1] case when there is no link; e.g. when a Model::ModelElement has no container. -- Steve From: "Baisley, Donald E" To: Stephen Crawley Cc: mof-rtf@omg.org, Stephen Brodsky Subject: RE: Model::Contains::container return type wrong Date: Mon, 15 Jan 2001 12:49:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ("&e98?`!!1a+!!#Qgd9 Hi Steve, The result should be the same as for Model::ModelElement::container. If there is no container then null is returned. We can make this behavior explicit by adding a sentence to the last paragraph about : When has bounds [0..1] and there is no related object then null is returned. Thanks for the quick and cooperative response. Regards, Don Baisley Unisys -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Sunday, January 14, 2001 6:46 PM To: Stephen Brodsky; Baisley, Donald E Cc: crawley@dstc.edu.au; mof-rtf@omg.org Subject: Re: Model::Contains::container return type wrong Don, Steve, I'm inclined to agree with the proposal. But we also need to specify what is returned by an operation in the [0..1] case when there is no link; e.g. when a Model::ModelElement has no container. -- Steve X-Mailer: exmh version 2.1.0 09/18/1999 To: "Baisley, Donald E" cc: Stephen Crawley , mof-rtf@omg.org, Stephen Brodsky Subject: Re: Model::Contains::container return type wrong In-Reply-To: Message from "Baisley, Donald E" of "Mon, 15 Jan 2001 12:49:33 CST." Mime-Version: 1.0 Date: Tue, 16 Jan 2001 13:01:40 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: %(f!!4An!!5%C!!iLn!! > Hi Steve, > > The result should be the same as for Model::ModelElement::container. > If there is no container then null is returned. Wrong. ModelElement::container throws NotSet if there is no container. The question is: do we want Contains::container to throw NotSet (which is not in its signature at the moment) ... or do we want it to return null? I think we want to do the latter, even though this is inconsistent with the Reference operation. [For your reasons, and because we don't want to change the MOF IDL if we can avoid it ... ] > We can make this behavior explicit by adding a sentence to the last > paragraph about : > > When has bounds [0..1] and there is no related > object then null is returned. -- Steve From: "Baisley, Donald E" To: Stephen Crawley Cc: mof-rtf@omg.org, Stephen Brodsky Subject: RE: Model::Contains::container return type wrong Date: Tue, 16 Jan 2001 12:42:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: RiOe99-3!!H$Fe9]A:!! Steve, you are right. I had forgotten about the NotSet stuff. I agree with you. Let's not use NotSet for a [0..1] association end. Perhaps we should also consider getting rid of NotSet altogether for all [0..1] cases, except for cases where it would be impossible to return null, such as for an attribute whose type won't allow returning null. However, I am happy to defer any such changes that would affect the MOF interfaces until 2.0. Regards, Don -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Monday, January 15, 2001 7:02 PM To: Baisley, Donald E Cc: Stephen Crawley; mof-rtf@omg.org; Stephen Brodsky Subject: Re: Model::Contains::container return type wrong > Hi Steve, > > The result should be the same as for Model::ModelElement::container. > If there is no container then null is returned. Wrong. ModelElement::container throws NotSet if there is no container. The question is: do we want Contains::container to throw NotSet (which is not in its signature at the moment) ... or do we want it to return null? I think we want to do the latter, even though this is inconsistent with the Reference operation. [For your reasons, and because we don't want to change the MOF IDL if we can avoid it ... ] > We can make this behavior explicit by adding a sentence to the last > paragraph about : > > When has bounds [0..1] and there is no related > object then null is returned. -- Steve X-Mailer: exmh version 2.1.0 09/18/1999 To: "Baisley, Donald E" cc: Stephen Crawley , mof-rtf@omg.org, Stephen Brodsky Subject: Re: Model::Contains::container return type wrong In-Reply-To: Message from "Baisley, Donald E" of "Tue, 16 Jan 2001 12:42:35 CST." Mime-Version: 1.0 Date: Wed, 17 Jan 2001 11:29:17 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: M2E!!9)K!!\+Wd9l8md9 > I had forgotten about the NotSet stuff. > I agree with you. Let's not use NotSet for > a [0..1] association end. OK. I'm still slightly unsure that we are doing the right thing ... considering things like consistency with RefAssociation::ref_query for example. > Perhaps we should also consider getting rid > of NotSet altogether for all [0..1] cases, > except for cases where it would be impossible > to return null, such as for an attribute whose > type won't allow returning null. I don't think this would be the right thing to do. NotSet is there because in the Attribute case a nil object reference cannot be used to indicate an empty set: nil is a valid Attribute value. The Reference accessor throws NotSet to make the IDL for References and Attributes consistent. I think we should leave this area alone for now. Lets wait until we overhaul the MOF meta-model(s) to separate the concerns of information modelling and API specification. Then we can provide the meta-modeller with the means of making these design decisions. -- Steve Date: Wed, 17 Jan 2001 17:48:05 -0800 From: Cris Kobryn Subject: RE: Model::Contains::container return type wrong In-reply-to: To: Stephen Brodsky , "Baisley, Donald E" Cc: Stephen Crawley , mof-rtf@omg.org Reply-to: ckobryn@acm.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Priority: 3 (Normal) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: i(6!!Q!#"!C/gd9Qo]d9 > I agree with your suggestion. MOF APIs should use only the upper bound > multiplicity in all cases. Trying to represent lower bound multiplicites > in language mappings causes considerable problems. I also concur with your recommended solution. Please clarify the ramifications on generating the final IDL for UML 1.4. -- Cris > "Baisley, Donald E" on 01/12/2001 11:25:37 AM > > To: Stephen Crawley > cc: mof-rtf@omg.org > Subject: RE: Model::Contains::container return type wrong > > > > Hi Steve, > > I would like to propose a resolution to this "Bag" problem for > MOF 1.4, and > I would like to get agreement as soon as possible because I am now > generating IDL for UML 1.4 which is supposed to be based on MOF 1.4. > > There is a real problem having the accessor for an association > end return a > different type than the semantically identical accessor for a > corresponding > reference. It is senseless to have Model::Contains::container return a > different type than Model::ModelElement::container when the two operations > are semantically identical. Similarly, there is a real problem having an > attribute's mutator take a different type than the parameter for setting > the > attribute when creating an object. > > We have an ugly inconsistency and we need to fix it. The fix is simple. > When generating types of association end accessors and create > parameters we > must treat 0..1 the same as 1..1. We should only append a > > if upper is greater than 1. > > There is another reason to adopt the resolution I am proposing. Not only > has the MOF 1.3 IDL been generated "incorrectly" by leaving off the "Bag". > The IDL for UML 1.3, CWM, and other standardized metamodels have been > generated "incorrectly" in the same way. The IDL generators have so far > failed to implement the ugly inconsistency. The IDL has been getting > generated all along in the way I am proposing to generate it. So fixing > MOF > 1.4 in the way I am proposing will save a lot of trouble. > > Rather than change all of the IDL, let's fix the specification to > match the > sensible way the IDL has been getting generated. A standard specification > should state what is standard practice rather than contradict standard > practice with some unused and senseless practice. Let's make MOF > 1.4 match > the IDL generation rules that are being used for the other standards like > UML and CWM. > > The impact of this approach is small for the MOF IDL -- there is no > nonderived optional attribute and only one optional association end. But > the impact is much greater for UML and CWM. The UML metamodel has many > optional attributes. For example, ModelElement::name is optional. A name > parameter appears in hundreds of create operations for the hundreds of > subclasses of ModelElement. These name parameters have been > using the Name > type. Based on the MOF 1.3 specification they should all have the type > NameBag. This would be laughable. It's absurd. The name attribute > returns > a Name. The setName operation takes a Name. But all of the create > operations should take a NameBag that can contain at most one Name? It's > ridiculous. Why should creation of every named ModelElement require > putting > the name in a NameBag to pass it to the create operation? The UML > metamodel > also has many optional association ends. > > We cannot expect people to take MOF-based IDL seriously if it needlessly > imposes these Bag types all over the place. > > Here is my specific proposal: > > In the description of create_ change "When an attribute has > multiplicity bounds other than [1..1]" to "When an attribute has > multiplicity upper bound greater than one". > > In the description of change "If it has bounds of > [1..1]" to "If it has an upper bound of one". > > These simple changes allow our IDL interfaces for MOF, UML, and CWM to be > correct without change. > > Best regards, > Don Baisley > Unisys > > -----Original Message----- > From: Stephen Crawley [mailto:crawley@dstc.edu.au] > Sent: Thursday, January 11, 2001 6:50 PM > To: mof-rtf@omg.org; issues@omg.org > Subject: Model::Contains::container return type wrong > > > The "Contains" Association is defined with the "container" end having > type "Namespace" and multiplicity [0..1]. According to the MOF to IDL > mapping (see 5.8.10 ) this means that the > Model::Contains::container() operation should return a "NamespaceBag". > > However, the IDL in both Chapter 3 and Appendix C incorrectly declares > Model::Contains::container() as returning a "Namespace". > > > > > X-Mailer: exmh version 2.1.0 09/18/1999 To: ckobryn@acm.org cc: Stephen Brodsky , "Baisley, Donald E" , Stephen Crawley , mof-rtf@omg.org Subject: Re: Model::Contains::container return type wrong In-Reply-To: Message from Cris Kobryn of "Wed, 17 Jan 2001 17:48:05 PST." Mime-Version: 1.0 Date: Thu, 18 Jan 2001 12:37:28 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: e`>!!_FO!!PhYd9~k=!! Steve Brodsky wrote: > > I agree with your [Don's] suggestion. > > MOF APIs should use only the upper bound > > multiplicity in all cases. Trying to represent lower bound multiplicites > > in language mappings causes considerable problems. I let this pass earlier, but I don't understand Steve Brodsky's comment. Don is not suggesting that we ignore the lower bound of multiplicities across the board in the IDL mapping. Indeed, it would be a very BAD THING to do this, because it would introduce gratuitous inconsistencies with IDL generated by MOF 1.3 compliant tools. Besides, you cannot treat [0..1] and [1..1] as identical in all cases because: 1) Some set base-types do not have a 'null' value, and 2) For some sets, the 'null' value is a meaningful value. Don's suggestion is that we change the treatment of [0..1] to be like [1..1] in ONE CASE ONLY; i.e. the return type of an () operation in the interfaces. My view (as I stated elsewhere) is that this is not harmful (in terms of generality, consistency and ease of use). Furthermore, it fixes the inconsistency problem for the published MOF IDL. Incidentally this helps DSTC's customers, since their generated IDL doesn't change when we go to MOF 1.4. [This mess arose because DSTC implemented the MOF 1.3 spec IDL mapping incorrectly in this case ... and supplied the resulting generated code for the MOF 1.3 spec.] To answer Chris Kobryn's question about the impact on the UML 1.4 IDL ... I'm not sure. Unisys generated the UML 1.3 and UML 1.4 IDL, and I don't know if their IDL generators have the same "bug" as DSTC's do / did. It >>looks<< like the bug was present for the UML 1.3 IDL ... Incidentally, there will be differences in the IDL from UML 1.3 to 1.4 ... because there have been changes to the UML meta-model. Besides, the UML 1.3 IDL looks like it was generated with a pre-MOF 1.3 IDL generator ... judging from the fact that it raises Reflective exceptions that no longer exist in MOF 1.3. -- Steve From: "Stephen Brodsky" Importance: Normal Subject: Re: Model::Contains::container return type wrong To: Stephen Crawley Cc: ckobryn@acm.org, "Baisley, Donald E" , mof-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: Sender: "Stephen Brodsky" Date: Wed, 17 Jan 2001 18:57:56 -0800 X-MIMETrack: Serialize by Router on D03NM039/03/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 01/17/2001 08:37:20 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: Un/e9&0Ie9WF]!!,J/!! Steve, My comment is directed at MOF APIs in general. There is a difference between enabling and constraining multiplicities in language mappings. The APIs should enable invocation by having a signature that allows for the potential (upper bound) multiplicity. The operation invoked (MOF) is responsible for enforcement of constraints on the input parameters. Attempting to provide constraint enforcement at the language (IDL) level rather than the semantic (MOF) level will result in problems, such as inconsistency across languages and incomplete and inflexible enforcement. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 Stephen Crawley on 01/17/2001 06:37:28 PM To: ckobryn@acm.org cc: Stephen Brodsky/Santa Teresa/IBM@IBMUS, "Baisley, Donald E" , Stephen Crawley , mof-rtf@omg.org Subject: Re: Model::Contains::container return type wrong Steve Brodsky wrote: > > I agree with your [Don's] suggestion. > > MOF APIs should use only the upper bound > > multiplicity in all cases. Trying to represent lower bound multiplicites > > in language mappings causes considerable problems. I let this pass earlier, but I don't understand Steve Brodsky's comment. Don is not suggesting that we ignore the lower bound of multiplicities across the board in the IDL mapping. Indeed, it would be a very BAD THING to do this, because it would introduce gratuitous inconsistencies with IDL generated by MOF 1.3 compliant tools. Besides, you cannot treat [0..1] and [1..1] as identical in all cases because: 1) Some set base-types do not have a 'null' value, and 2) For some sets, the 'null' value is a meaningful value. Don's suggestion is that we change the treatment of [0..1] to be like [1..1] in ONE CASE ONLY; i.e. the return type of an () operation in the interfaces. My view (as I stated elsewhere) is that this is not harmful (in terms of generality, consistency and ease of use). Furthermore, it fixes the inconsistency problem for the published MOF IDL. Incidentally this helps DSTC's customers, since their generated IDL doesn't change when we go to MOF 1.4. [This mess arose because DSTC implemented the MOF 1.3 spec IDL mapping incorrectly in this case ... and supplied the resulting generated code for the MOF 1.3 spec.] To answer Chris Kobryn's question about the impact on the UML 1.4 IDL ... I'm not sure. Unisys generated the UML 1.3 and UML 1.4 IDL, and I don't know if their IDL generators have the same "bug" as DSTC's do / did. It >>looks<< like the bug was present for the UML 1.3 IDL ... Incidentally, there will be differences in the IDL from UML 1.3 to 1.4 ... because there have been changes to the UML meta-model. Besides, the UML 1.3 IDL looks like it was generated with a pre-MOF 1.3 IDL generator ... judging from the fact that it raises Reflective exceptions that no longer exist in MOF 1.3. -- Steve From: "Baisley, Donald E" To: Stephen Crawley Cc: Stephen Brodsky , mof-rtf@omg.org, ckobryn@acm.org Subject: RE: Model::Contains::container return type wrong Date: Wed, 17 Jan 2001 21:15:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: g#l!!6gVd9&WOd91G(e9 Hi MOF folks, I had recommended two changes to the MOF specification. The first is related to Association ends. I believe we have agreement on that one. The accessor for an association end with [0..1] will use the end's type as the return type rather than a bag type. This leaves the IDl for MOF and other standard metamodels the same as it has been. The second recommendation has a problem. I recommended we make the same type change for the create operation parameters of attributes with [0..1]. As Steve has pointed out, this will not work for all attribute types. It will not work for types for which null cannot be passed (like int), nor for CORBA pointer types. It does work very nicely for string and object types (which are the types of the many optional attributes in UML 1.4). I would like to change my second recommendation to apply only to attribute types that support passing null. The wording will be changed to exclude CORBA pointer types and types for which null cannot be passed. The affect of the first recommendation will be to cause no change in the UML IDL because the code that generated the 1.3 IDL incorrectly assumed what is only now being proposed. The Unisys IDL generator had the same "problem" as DSTC's. The affect of the second recommendation will be to minimize changes to the UML IDL caused by many attributes in the UML metamodel being made optional. And it will minimize the inconvenience of using bags needlessly when creating objects. For example, there are hundreds of create operations in the UML IDL that take a name parameter. If we make the recommended change then the type of these name parameters will be Name. If we don't, the type will be NameBag, and everyone creating model elements (with or without a name) will need to pass a NameBag. I submit to the will of the group. If we can quickly agree then I can make sure the UML 1.4 IDL matches the coming MOF 1.4 rules. If we cannot agree or if the general agreement is to not accept the second recommendation, then I will regenerate the UML 1.4 IDL with all the necessary bag types. Thanks for your prompt responses on this subject. Best regards, Don Baisley Unisys -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Wednesday, January 17, 2001 6:37 PM To: ckobryn@acm.org Cc: Stephen Brodsky; Baisley, Donald E; Stephen Crawley; mof-rtf@omg.org Subject: Re: Model::Contains::container return type wrong Steve Brodsky wrote: > > I agree with your [Don's] suggestion. > > MOF APIs should use only the upper bound > > multiplicity in all cases. Trying to represent lower bound multiplicites > > in language mappings causes considerable problems. I let this pass earlier, but I don't understand Steve Brodsky's comment. Don is not suggesting that we ignore the lower bound of multiplicities across the board in the IDL mapping. Indeed, it would be a very BAD THING to do this, because it would introduce gratuitous inconsistencies with IDL generated by MOF 1.3 compliant tools. Besides, you cannot treat [0..1] and [1..1] as identical in all cases because: 1) Some set base-types do not have a 'null' value, and 2) For some sets, the 'null' value is a meaningful value. Don's suggestion is that we change the treatment of [0..1] to be like [1..1] in ONE CASE ONLY; i.e. the return type of an () operation in the interfaces. My view (as I stated elsewhere) is that this is not harmful (in terms of generality, consistency and ease of use). Furthermore, it fixes the inconsistency problem for the published MOF IDL. Incidentally this helps DSTC's customers, since their generated IDL doesn't change when we go to MOF 1.4. [This mess arose because DSTC implemented the MOF 1.3 spec IDL mapping incorrectly in this case ... and supplied the resulting generated code for the MOF 1.3 spec.] To answer Chris Kobryn's question about the impact on the UML 1.4 IDL ... I'm not sure. Unisys generated the UML 1.3 and UML 1.4 IDL, and I don't know if their IDL generators have the same "bug" as DSTC's do / did. It >>looks<< like the bug was present for the UML 1.3 IDL ... Incidentally, there will be differences in the IDL from UML 1.3 to 1.4 ... because there have been changes to the UML meta-model. Besides, the UML 1.3 IDL looks like it was generated with a pre-MOF 1.3 IDL generator ... judging from the fact that it raises Reflective exceptions that no longer exist in MOF 1.3. -- Steve From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: RE: Model::Contains::container return type wrong Date: Thu, 18 Jan 2001 13:25:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: M-*e9^GTd9h1Je9c#md9 Hello again, After some discussion with Steve Crawley I have learned that my second recommendation will not work out, so I withdraw it. The conclusion: We have agreement that the accessor for an association end with [0..1] will use the end's type as the return type rather than a bag type. This leaves the IDl for MOF and other standard metamodels the same as it has been. There will be no change to the IDL generation rules for create operation parameters. Best regards, Don Baisley Unisys -----Original Message----- From: Baisley, Donald E Sent: Wednesday, January 17, 2001 7:16 PM To: 'Stephen Crawley' Cc: Stephen Brodsky; mof-rtf@omg.org; ckobryn@acm.org Subject: RE: Model::Contains::container return type wrong Hi MOF folks, I had recommended two changes to the MOF specification. The first is related to Association ends. I believe we have agreement on that one. The accessor for an association end with [0..1] will use the end's type as the return type rather than a bag type. This leaves the IDl for MOF and other standard metamodels the same as it has been. The second recommendation has a problem. I recommended we make the same type change for the create operation parameters of attributes with [0..1]. As Steve has pointed out, this will not work for all attribute types. It will not work for types for which null cannot be passed (like int), nor for CORBA pointer types. It does work very nicely for string and object types (which are the types of the many optional attributes in UML 1.4). I would like to change my second recommendation to apply only to attribute types that support passing null. The wording will be changed to exclude CORBA pointer types and types for which null cannot be passed. The affect of the first recommendation will be to cause no change in the UML IDL because the code that generated the 1.3 IDL incorrectly assumed what is only now being proposed. The Unisys IDL generator had the same "problem" as DSTC's. The affect of the second recommendation will be to minimize changes to the UML IDL caused by many attributes in the UML metamodel being made optional. And it will minimize the inconvenience of using bags needlessly when creating objects. For example, there are hundreds of create operations in the UML IDL that take a name parameter. If we make the recommended change then the type of these name parameters will be Name. If we don't, the type will be NameBag, and everyone creating model elements (with or without a name) will need to pass a NameBag. I submit to the will of the group. If we can quickly agree then I can make sure the UML 1.4 IDL matches the coming MOF 1.4 rules. If we cannot agree or if the general agreement is to not accept the second recommendation, then I will regenerate the UML 1.4 IDL with all the necessary bag types. Thanks for your prompt responses on this subject. Best regards, Don Baisley Unisys -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Wednesday, January 17, 2001 6:37 PM To: ckobryn@acm.org Cc: Stephen Brodsky; Baisley, Donald E; Stephen Crawley; mof-rtf@omg.org Subject: Re: Model::Contains::container return type wrong Steve Brodsky wrote: > > I agree with your [Don's] suggestion. > > MOF APIs should use only the upper bound > > multiplicity in all cases. Trying to represent lower bound multiplicites > > in language mappings causes considerable problems. I let this pass earlier, but I don't understand Steve Brodsky's comment. Don is not suggesting that we ignore the lower bound of multiplicities across the board in the IDL mapping. Indeed, it would be a very BAD THING to do this, because it would introduce gratuitous inconsistencies with IDL generated by MOF 1.3 compliant tools. Besides, you cannot treat [0..1] and [1..1] as identical in all cases because: 1) Some set base-types do not have a 'null' value, and 2) For some sets, the 'null' value is a meaningful value. Don's suggestion is that we change the treatment of [0..1] to be like [1..1] in ONE CASE ONLY; i.e. the return type of an () operation in the interfaces. My view (as I stated elsewhere) is that this is not harmful (in terms of generality, consistency and ease of use). Furthermore, it fixes the inconsistency problem for the published MOF IDL. Incidentally this helps DSTC's customers, since their generated IDL doesn't change when we go to MOF 1.4. [This mess arose because DSTC implemented the MOF 1.3 spec IDL mapping incorrectly in this case ... and supplied the resulting generated code for the MOF 1.3 spec.] To answer Chris Kobryn's question about the impact on the UML 1.4 IDL ... I'm not sure. Unisys generated the UML 1.3 and UML 1.4 IDL, and I don't know if their IDL generators have the same "bug" as DSTC's do / did. It >>looks<< like the bug was present for the UML 1.3 IDL ... Incidentally, there will be differences in the IDL from UML 1.3 to 1.4 ... because there have been changes to the UML meta-model. Besides, the UML 1.3 IDL looks like it was generated with a pre-MOF 1.3 IDL generator ... judging from the fact that it raises Reflective exceptions that no longer exist in MOF 1.3. -- Steve X-Mailer: exmh version 2.1.0 09/18/1999 To: "Stephen Brodsky" cc: Stephen Crawley , ckobryn@acm.org, "Baisley, Donald E" , mof-rtf@omg.org Subject: Re: Model::Contains::container return type wrong In-Reply-To: Message from "Stephen Brodsky" of "Wed, 17 Jan 2001 18:57:56 PST." Mime-Version: 1.0 Date: Fri, 19 Jan 2001 14:30:10 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: g[dd96^Ke9?E]!!"]2!! Steve, You wrote: > My comment is directed at MOF APIs in general. There is a difference > between enabling and constraining multiplicities in language mappings. The > APIs should enable invocation by having a signature that allows for the > potential (upper bound) multiplicity. The operation invoked (MOF) is > responsible for enforcement of constraints on the input parameters. > Attempting to provide constraint enforcement at the language (IDL) level > rather than the semantic (MOF) level will result in problems, such as > inconsistency across languages and incomplete and inflexible enforcement. I'm still not sure what you are getting at. Can you give us some concrete examples where you think that the MOF Model -> IDL mapping is wrong, and where changing it would improve things? Having said that, tinkering with the IDL mapping in MOF 1.4 would most likely break a good deal of existing customer code. That would be a BAD THING ... in my opinion. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Proposed resolution to Issue 4133 (and 3379) Mime-Version: 1.0 Date: Mon, 09 Apr 2001 17:00:25 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: 0(!!!E1cd9QnZ!!F-^!! > Title: Issue 4133: Model::Contains::container return type wrong > Summary: The "Contains" Association is defined with the "container" > end > having type "Namespace" and multiplicity [0..1]. According to the > MOF > to IDL mapping (see 5.8.10 ) this means that > the Model::Contains::container() operation should return a > "NamespaceBag". > However, the IDL in both Chapter 3 and Appendix C incorrectly > declares > Model::Contains::container() as returning a "Namespace". Issue 4133 is (I now realise) a duplicate of issue 3379, so this resolution covers both issues. Resolution: The proposed resolution to this issue is to change the IDL templates to match the Model IDL. Revised Text: Make the following changes to the description for the operation in 5.8.10. In the third paragraph, change "If it has bouonds of [1..1] ... " to read "If it has bounds [0..1] or [1..1] ..." Add a new paragraph after paragraph 3 that reads as follows: "The result of the operation gives the object or collection of objects related to the parameter object by a Link or Links in this Association. If the multiplicity is [1..1], the result will be a non-nill object reference. If the multiplicity is [0..1], the operation will return a non-nil object reference if there is a related object, and a nil object reference otherwise. In other cases, the operation will return a (possibly zero length) sequence of non-nil object references. If the association end being queried is ordered, the order of the contents of the returned collection is significant."