Issue 3528: Can MOF Class contain a Constant? (mof-rtf) Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com) Nature: Uncategorized Issue Severity: Summary: The MOF 1.3 Specification shows in table 3-4 that a Class can contain a Constant. But constraint [C-15] ClassContainmentRules does not allow a Class to contain a Constant. The table and the constraint need to say the same thing. Since MOF's Model.ModelElement contains Constants, it is clear that the table is correct. Recommendation: add Constant to ClassContainmentRules. Resolution: Change constraint [C-15] as recommended Revised Text: In section 3.9.3, change the OCL for [C-15] to read: ... Set{Class, DataType, Attribute, Reference, Operation, Exception, Constraint, Tag} -> ... to read: ... Set{Class, DataType, Attribute, Reference, Operation, Exception, Constant, Constraint, Tag} -> ... Also change the "description" for [C-15] to read: "... Operations, Exceptions, Constants, Constraints and Tags." The OCL change also needs to be made to [C-15] in the XMI document in Appendix A. Search for "Contents fo Class: Class", then insert "Constant, " at the appropriate point in the first <XMI.any> element. Actions taken: April 4, 2000: received issue December 3, 2001: closed issue Discussion: End of Annotations:===== From: "Baisley, Donald E" To: issues@omg.org Subject: Can MOF Class contain a Constant? Date: Mon, 3 Apr 2000 17:04:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: bF3e9b@g!!e%Wd9^RD!! The MOF 1.3 Specification shows in table 3-4 that a Class can contain a Constant. But constraint [C-15] ClassContainmentRules does not allow a Class to contain a Constant. The table and the constraint need to say the same thing. Since MOF's Model.ModelElement contains Constants, it is clear that the table is correct. Recommendation: add Constant to ClassContainmentRules. Don Baisley Unisys Date: Tue, 25 Apr 2000 16:52:24 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 3528 Help needed Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Aohd913:!!)b~e9A~~e9 Issue 3258: Can native be used in constructed IDL types? (orb_revision) http://www.omg.org/issues/issue3528.txt Source: Floorboard Software (Jonathan Biggar jon@floorboard.com) Nature: Uncategorized Issue Severity: Summary: CORBA 2.3.1, section 3.10.5 says: "A native type may be used to define operation parameters and results. However, there is no requirement that values of the type be permitted in remote invocations, either directly or as a component of a constructed type." This is ambiguous as to whether a native type may be used in a constructed IDL type that is intended to be used only locally: // IDL native MyNative; struct MyStruct { MyNative a_native; }; So, should the first sentence in 3.10.5 be read to mean that native may ONLY be used in parameters & results? If so, we ought to put the word "only" in there. -- _________________________________________________________________ So what do people think? Disallowing use of declared native types in constructed types puts the burden on the IDL compiler and saves on runtime checking when marshaling. OTOH, once we have local interfaces that can be placed anywhere, similar checking will have to be done at marshaling time for those local interfaces anyway, so why not let natives be used in constructed types too? Help with analyzing the pros and cons please. Thanks, Jishnu. Date: Tue, 25 Apr 2000 14:24:09 -0700 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: orb_revision@omg.org Subject: Re: Issue 3528 Help needed References: <39060588.8312D09A@fpk.hp.com> Content-Type: multipart/mixed; boundary="------------D7C060AA6A3C2B211120C9E2" X-UIDL: 0$8!!EQ;!!,Ig!!:OKe9 Since the locality of contained members of a constructed type appear to affect the locality of the constructed type itself, why not treat local as an attribute that can be applied to any constructed type too. ie. local struct myLocalStruct { // can contain natives or local interfaces etc }; struct myStruct { // may not contain local interfaces or natives }; The advantage to this is that this property can be taken advantage of when mapping these things and not taking the hit to detect this at runtime (or at least not as much). Vijay Jishnu Mukerji wrote: > Issue 3258: Can native be used in constructed IDL types? (orb_revision) > > http://www.omg.org/issues/issue3528.txt > Source: Floorboard Software (Jonathan Biggar jon@floorboard.com) > Nature: Uncategorized Issue > Severity: > Summary: CORBA 2.3.1, section 3.10.5 says: > > "A native type may be used to define operation parameters and results. > However, there is no requirement that values of the type be permitted in > remote invocations, either directly or as a component of a constructed > type." > > This is ambiguous as to whether a native type may be used in a > constructed IDL type that is intended to be used only locally: > > // IDL > > native MyNative; > > struct MyStruct { > MyNative a_native; > }; > > So, should the first sentence in 3.10.5 be read to mean that native may > ONLY be used in parameters & results? If so, we ought to put the word > "only" in there. > -- > _________________________________________________________________ > > So what do people think? Disallowing use of declared native types in > constructed types puts the burden on the IDL compiler and saves on > runtime checking when marshaling. OTOH, once we have local interfaces > that can be placed anywhere, similar checking will have to be done at > marshaling time for those local interfaces anyway, so why not let > natives be used in constructed types too? > > Help with analyzing the pros and cons please. > > Thanks, > > Jishnu. [] vijayn1.vcf Date: Tue, 25 Apr 2000 17:39:33 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan Cc: orb_revision@omg.org, components-ftf@omg.org Subject: Re: Issue 3528 Help needed References: <39060588.8312D09A@fpk.hp.com> <39060CF9.2DA15432@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: K'j!![/Yd9;CCe9-)Pd9 Vijaykumar Natarajan wrote: > > Since the locality of contained members of a constructed type appear to affect > the locality of the constructed type itself, why not treat local as an attribute > that can be applied to any constructed type too. ie. > > local struct myLocalStruct { > // can contain natives or local interfaces etc > }; > > struct myStruct { > // may not contain local interfaces or natives > }; > > The advantage to this is that this property can be taken advantage of when > mapping these things and not taking the hit to detect this at runtime (or at > least not as much). I suppose we could take the position that native is like local and hence native should be handled exactly as local as far as use in constructed types is concerned, and then defer to the Components FTF on what that behavior might be. The specific suggestion that you have cannot be handled in the Core RTF since the Components folks have veto rights over what is done with "local". I have CC-ed the components-ftf list on this response. Jishnu. Date: Tue, 25 Apr 2000 15:04:57 -0700 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: Vijaykumar Natarajan , orb_revision@omg.org, components-ftf@omg.org Subject: Re: Issue 3528 Help needed References: <39060588.8312D09A@fpk.hp.com> <39060CF9.2DA15432@inprise.com> <39061095.8065A4@fpk.hp.com> Content-Type: multipart/mixed; boundary="------------0AD8F7C81BF32EAABB4EDEA5" X-UIDL: K1?e9mle!!X;\!!Zd8!! Thanks Jishnu. Of course, acceptance of this solution would imply that the resolution for this issue would be to explicitly disallow the use of native in "normal" structs. Vijay Jishnu Mukerji wrote: > Vijaykumar Natarajan wrote: > > > > Since the locality of contained members of a constructed type appear to affect > > the locality of the constructed type itself, why not treat local as an attribute > > that can be applied to any constructed type too. ie. > > > > local struct myLocalStruct { > > // can contain natives or local interfaces etc > > }; > > > > struct myStruct { > > // may not contain local interfaces or natives > > }; > > > > The advantage to this is that this property can be taken advantage of when > > mapping these things and not taking the hit to detect this at runtime (or at > > least not as much). > > I suppose we could take the position that native is like local and hence > native should be handled exactly as local as far as use in constructed > types is concerned, and then defer to the Components FTF on what that > behavior might be. > > The specific suggestion that you have cannot be handled in the Core RTF > since the Components folks have veto rights over what is done with > "local". I have CC-ed the components-ftf list on this response. > > Jishnu. [] vijayn2.vcf X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Re: Issue 3528: Can MOF Class contain a Constant? Mime-Version: 1.0 Date: Wed, 13 Jun 2001 16:52:55 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: 8mHe9I?K!!8C=e9i%m!! > Source: Unisys (Mr. Don Baisley, Donald.Baisley@unisys.com) > Nature: Uncategorized Issue > Severity: > Summary: The MOF 1.3 Specification shows in table 3-4 that a Class > can contain a Constant. But constraint [C-15] ClassContainmentRules > does > not allow a Class to contain a Constant. The table and the > constraint > need to say the same thing. Since MOF's Model.ModelElement contains > Constants, it is clear that the table is correct. > > Recommendation: add Constant to ClassContainmentRules. Proposed Resolution: Change constraint [C-15] as recommended. Proposed Revised Text: In section 3.9.3, change the OCL for [C-15] to read: ... Set{Class, DataType, Attribute, Reference, Operation, Exception, Constraint, Tag} -> ... to read: ... Set{Class, DataType, Attribute, Reference, Operation, Exception, Constant, Constraint, Tag} -> ... Also change the "description" for [C-15] to read: "... Operations, Exceptions, Constants, Constraints and Tags." The same changes need to be made to [C-15] in the XMI document in Appendix A. Search for "Contents fo Class: Class", then add "Constant, " at the appropriate point in the first element.