Issue 2189: Reflective::InvalidDesignator exception (mof-rtf) Source: (, ) Nature: Revision Severity: Minor Summary: Summary: The IDL should contain constant declarations for the possible values of the "element_kind" field of the exception. Since more than one element kind might be expected in some cases (e.g. RefObject::set_value() applies to attributes AND references) perhaps, the field should be multi-valued. Resolution: resolved, closed Revised Text: Actions taken: November 6, 1998: received issue May 8, 2000: closed issue Discussion: Discusssion : Please provide specific context (Section number, page) for us analyze the problem [DK] Proposal is to revise the InvalidDesignator exception as follows: exception InvalidDesignator { DesignatorType designator; StringSet element_kinds; };A predefined set of possible string values that the 'element_kind' members could be as-signed needs to be defined in Reflective.idl like this: const string PACKAGE_KIND = "Package"; const string TYPE_KIND = "Type"; const string ASSOCIATION_KIND = "Association"; and so on for each of the concrete MOFclasses. Implementation: Revised the InvalidDesignator exception in Section 5.4.6, “Reflec-tive Errors,” on page 5-30 to return multiple element_kinds and to define the string values that can be returned. Note that the possible kinds have been determined by analysing the operations that can raise InvalidDesignator (and also InvalidValue which also has an element_kind field). The corresponding changes have been made in Appendix B.2 “MOF IDL Summary”. Done [KR]. Implementation: Definition of is_instance_of now says that MofError("Invalid Des-ignator", "Wrong Designator Kind") get raised. Done. [SC] End of Annotations:===== Return-Path: To: mof-rtf@omg.org, issues@omg.org Subject: Issues with the MOF Reflective interfaces Date: Sat, 07 Nov 1998 02:04:02 +1000 From: Stephen Crawley This message contains a set of issues that DSTC have discovered while implementing the MOF Reflective interfaces. Don't panic. They are all "minor" :-) Credit for finding them and carefully documenting them is due to Douglas Kosovic. -- Steve =================================================================== Subject: Reflective::InvalidDesignator exception Source: DSTC (Douglas Kosovic, douglask@dstc.edu.au) Nature: Revision Severity: Minor Summary: The IDL should contain constant declarations for the possible values of the 'element_kind' field of the exception. Since more than one element kind might be expected in some cases (e.g. RefObject::set_value() applies to attributes AND references) perhaps, the field should be multi-valued. Additional text: The exception is defined as follows: exception InvalidDesignator { DesignatorType designator; string element_kind; }; A predefined set of possible string values that the 'element_kind' member could be assigned, hasn't been defined in Reflective.idl. Something like the following string constants should probably be defined in Reflective.idl: const string PACKAGE_KIND = "Package"; const string TYPE_KIND = "Type"; const string ASSOCIATION_KIND = "Association"; const string ATTRIBUTE_KIND = "Attribute"; const string REFERENCE_KIND = "Reference"; const string ASSOCIATION_END_KIND = "AssociationEnd"; const string OPERATION_KIND = "Operation"; const string PARAMETER_KIND = "Parameter"; const string EXCEPTION_KIND = "Exception"; The 'element_kind' member is suppose to indicate what kind of model element was expected, but in some cases there can be more than one kind of model element (e.g. An Attribute or Reference could be expected in the set_value() operation of the RefObject interface). Perhaps InvalidDesignator could be changed to something like: exception InvalidDesignator { DesignatorType designator; StringSet element_kinds; }; =================================================================== X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: 2189 - proposed corrigenda Mime-Version: 1.0 Date: Tue, 03 Jul 2001 16:58:52 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: UXL!!^5-!!"S#"!,p+!! These proposed corrigenda to 2198 are "significant" (non-editorial) and will need to be voted on at some point. Comments please ... 1) In order to clarify the intent on how standard PrimitiveType instances are recognized as such, insert into 3.9 (PrimitiveTypes) the following sentences. "Technology mappings shall recognize standard PrimitiveType instances based on their qualified names. Multiple PrimitiveType instances with the required qualified name are deemed to mean the same thing." [This should tie a loose end so that we can back out of the UUID tar pit.] 2) To make the MOF -> IDL mapping work, we need to make sure that StructureTypes contain AT LEAST ONE StructureField. We could make this an "IDL mapping precondition", but I think it is more sensible to make this a Constraint on the MOF Model. I therefore propose the following Constraint be added to StructureType: [C-XX] MustHaveFields -- "A StructureType must contain at least one StructureField.", evaluationPolicy: deferred, OCL: TBD. [I'll probably find more corrigenda as I do the editing. Stay tuned.] -- Steve From: "Martin Matula" To: , "Stephen Crawley" References: <200107030658.f636wo410489@piglet.dstc.edu.au> Subject: Re: 2189 - proposed corrigenda Date: Tue, 3 Jul 2001 09:22:47 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: YQl!!7S!e9p83!!0c9e9 Steve, is it a problem to recognize primitive types also by URL of the MOF 1.4 model? Martin ----- Original Message ----- From: "Stephen Crawley" To: Sent: Tuesday, July 03, 2001 8:58 AM Subject: 2189 - proposed corrigenda > > These proposed corrigenda to 2198 are "significant" (non-editorial) >and > will need to be voted on at some point. > > Comments please ... > > 1) In order to clarify the intent on how standard PrimitiveType >instances are > recognized as such, insert into 3.9 (PrimitiveTypes) the following sentences. > > "Technology mappings shall recognize standard PrimitiveType >instances > based on their qualified names. Multiple PrimitiveType instances >with > the required qualified name are deemed to mean the same thing." > > [This should tie a loose end so that we can back out of the UUID tar >pit.] > > 2) To make the MOF -> IDL mapping work, we need to make sure that StructureTypes > contain AT LEAST ONE StructureField. We could make this an "IDL >mapping > precondition", but I think it is more sensible to make this a >Constraint > on the MOF Model. I therefore propose the following Constraint be >added to > StructureType: > > [C-XX] MustHaveFields -- "A StructureType must contain at least >one > StructureField.", evaluationPolicy: deferred, OCL: TBD. > > [I'll probably find more corrigenda as I do the editing. Stay >tuned.] > > -- Steve > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin Matula" cc: mof-rtf@omg.org, "Stephen Crawley" , "Mutschler, Gene O" Subject: Re: 2189 - proposed corrigenda In-Reply-To: Message from "Martin Matula" > of "Tue, 03 Jul 2001 09:22:47 +0200." ><0e5701c10390$f623f490$844b9c81@matula> Mime-Version: 1.0 Date: Tue, 03 Jul 2001 17:43:11 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 >(http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: baTd9JGkd98>-e9oQ+!! > is it a problem to recognize primitive types also by URL of the MOF 1.4 > model? That would have to be expressed in the yet-to-be-written material which describes the how XMI is instantiated for MOF 1.4. The notion of a URL does not belong in any of Chapters 3, 4, 5 or 6 ... I believe that there is an Action on Don to handle XMI 1.x for MOF 1.4. There was also some discussion of this from the XMI RTF side, and someone there was delegated to talk to Andrew Watson about issuance of standard URNs, etc. Have I remembered this correctly Don / Sridhar / Gene? [Is something happening on URLs / URNs / etc?] By the way, the XMI guys at IBM have just raised an XMI RTF issue to pass responsibility for the "XMI / MOF" DTDs etc to the MOF RTF. We must be sure this doesn't drop into the time gap between the MOF 1.4 and XMI 1.2 RTF deadlines ... -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Baisley, Donald E" cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: 2189 - proposed corrigenda In-Reply-To: Message from "Baisley, Donald E" of "Tue, 03 Jul 2001 15:48:12 EST." Mime-Version: 1.0 Date: Wed, 04 Jul 2001 11:47:40 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: WLG!!?"J!!8oI!!TdI!! Don, > I don't understand the point of the statement in number 1 below. The problem I'm trying to solve is: >>How<< does a language mapping known if a PrimitiveType instance in a MOF meta-model denotes one of the standard MOF primitive data types. At the moment, this is unspecified. It is not clear if there should be only one "instance" of PrimitiveTypes::Boolean (say), or if there can be multiple instances. And it is not clear if generators should treat all instances of PrimitiveTypes::Boolean as meaning the same thing. > First, technology mappings must recognize all sorts of model elements, not > just primitive types. I don't see why something special is said here about > qualified names of primitive types. You are missing something here. For most ModelElement instances, a language mapping typically does not care about identity. Rather, it maps the "meaning" expressed as attribute values of the element and its relationship to other elements to various constructs in the target language. In general, the names of elements have no special meaning. they just map to programming language identifiers and the like. By contrast, a PrimitiveType instance has no attributes that give it "meaning". All it has is a qualified name and a MOF identifier. The mapping has to use one or the other of these as the basis for recognising PrimitiveType instances that denote standard MOF primitive data types. Only when it has done this can it map them to concrete types. > It is perfectly plain in the context of > MOF 1.4 what ::PrimitiveTypes::Boolean is just as it is perfectly > plain what > ::Model::ModelElement is. It is NOT perfectly plain what ::PrimitiveTypes::Boolean "is" in the context of a MOF repository. The spec says what it means, but it does not clearly say how it is represented; e.g. whether it is a distinguished instance or whether it can be any instance with that qualified name. > Second, the point about multiple instances with the same qualified name > seems to have no special meaning for primitive types over other model > elements. Not true. See above. > When you say instances, are you talking about logical instances > or "physical" ones. If "physical", then that level of instance > should be > dealt with in the binding specification separately for each binding, > not in > chapter 3. If logical, then two instances that mean the same thing > are > logically the same one instance, so you don't have two instances. You can't use this line of reasoning in the context of MOF 1.3 / 1.4. The specification does not recognize the concepts of "logical" and "physical" instances. If you start using these terms, you are reading meaning into the spec that is not there. The closest the spec comes to a logical/physical distinction is that IN THE CONTEXT OF THE IDL MAPPING, two objects with the same MOF Identifier are "equal" for the purposes of structural (etc) constraint checking. But that doesn't help us here. We've got nothing that says what the MOF Identifiers for the standard primitive types are ... and no way of creating instances that have specific MOF Identifier values. I am trying to solve a REAL problem here Don. One that would cause vendor repository's and tools to not be interoperable, and that could could present difficulty for cross-vendor meta-model interchange. The fix is simple and should be non-contentious ... but believe me, it is necessary! -- Steve From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: RE: 2189 - proposed corrigenda Date: Tue, 3 Jul 2001 15:48:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: KWH!!42Ae9jV%!!ZlNd9 I don't understand the point of the statement in number 1 below. First, technology mappings must recognize all sorts of model elements, not just primitive types. I don't see why something special is said here about qualified names of primitive types. It is perfectly plain in the context of MOF 1.4 what ::PrimitiveTypes::Boolean is just as it is perfectly plain what ::Model::ModelElement is. Second, the point about multiple instances with the same qualified name seems to have no special meaning for primitive types over other model elements. When you say instances, are you talking about logical instances or "physical" ones. If "physical", then that level of instance should be dealt with in the binding specification separately for each binding, not in chapter 3. If logical, then two instances that mean the same thing are logically the same one instance, so you don't have two instances. I recommend you leave out number 1. But number 2 is fine. Enjoy, Don -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Monday, July 02, 2001 11:59 PM To: mof-rtf@omg.org Subject: 2189 - proposed corrigenda These proposed corrigenda to 2198 are "significant" (non-editorial) and will need to be voted on at some point. Comments please ... 1) In order to clarify the intent on how standard PrimitiveType instances are recognized as such, insert into 3.9 (PrimitiveTypes) the following sentences. "Technology mappings shall recognize standard PrimitiveType instances based on their qualified names. Multiple PrimitiveType instances with the required qualified name are deemed to mean the same thing." [This should tie a loose end so that we can back out of the UUID tar pit.] 2) To make the MOF -> IDL mapping work, we need to make sure that StructureTypes contain AT LEAST ONE StructureField. We could make this an "IDL mapping precondition", but I think it is more sensible to make this a Constraint on the MOF Model. I therefore propose the following Constraint be added to StructureType: [C-XX] MustHaveFields -- "A StructureType must contain at least one StructureField.", evaluationPolicy: deferred, OCL: TBD. [I'll probably find more corrigenda as I do the editing. Stay tuned.] -- Steve