Issue 4607: resolveQualifiedName operation (mof-rtf) Source: GoodData Corporation (Mr. Martin Matula, matulic(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: I think it would be much more convenient to have resolveQualifiedName as a "classifier_level" operation on ModelElement instead of "instance_level" operation on Namespace. Now each time I want to resolve some object using its qualified name, I have to find all outermost packages (which is quite slow, because currently there is no better way of doing it than just iterate through all package instances and check whether they are outermost), then choose a package with a specified name and call resolveQualifiedName on that package passing rest of the qualified name as a parameter. This is much more complicated for users than it should be. Resolution: Revised Text: Actions taken: October 8, 2001: received issue Discussion: End of Annotations:===== From: "Martin Matula" To: "Mof-Rtf@Omg.Org" Cc: Subject: mof issue: resolveQualifiedName operation Date: Mon, 8 Oct 2001 18:14:19 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: V0ed9JKV!!2fW!!J\~!! I think it would be much more convenient to have resolveQualifiedName as a "classifier_level" operation on ModelElement instead of "instance_level" operation on Namespace. Now each time I want to resolve some object using its qualified name, I have to find all outermost packages (which is quite slow, because currently there is no better way of doing it than just iterate through all package instances and check whether they are outermost), then choose a package with a specified name and call resolveQualifiedName on that package passing rest of the qualified name as a parameter. This is much more complicated for users than it should be. Martin Matula (mailto:martin.matula@sun.com) tel: +420(2)3300-9153 Sun Micro: x49153 Praha, CR From: "Martin Matula" To: "Mof-Rtf@Omg.Org" Subject: Re: issue 4607 -- MOF RTF issue Date: Tue, 9 Oct 2001 17:51:06 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: pd&e9ShUd9l6)!!dg6e9 Hi Steve, thanks for the explanation. I didn't realize that there can be more outermost packages of the same name. In the light of this fact I agree with you that we should wait for MOF 2.0 versioning. Martin BTW: I don't understand how you can reasonably store several versions of one outermost package in a same extent. How do you distinguish between them? (By an additional tag?) I thought that correct way to store several versions of the same metamodel is to create several instances of MOF Model package and store 1 version per 1 instance of MOF Model package - this way you don't have this problem and the classifier_level resolveQualifiedName method would work, because it would be invoked on a ModelElement class proxy that is part of exactly one of these extents. > ----- Original Message ----- > From: "Stephen Crawley" > To: "Martin Matula" > Cc: ; > Sent: Monday, October 08, 2001 11:16 PM > Subject: Re: issue 4607 -- MOF RTF issue > > > > > This is issue # 4607 Martin Matula" > > > > > > resolveQualifiedName operation > > > > > > I think it would be much more convenient to have resolveQualifiedName as > a > > > "classifier_level" operation on ModelElement instead of "instance_level" > > > operation on Namespace. Now each time I want to resolve some object > using > > > its qualified name, I have to find all outermost packages (which is > quite > > > slow, because currently there is no better way of doing it than just > iterate > > > through all package instances and check whether they are outermost), > then > > > choose a package with a specified name and call resolveQualifiedName on > that > > > package passing rest of the qualified name as a parameter. This is much > more > > > complicated for users than it should be. > > > > Martin, > > > > This suggestion has a greater impact than you may realise. There is no > > Constraint in the MOF Model that says that the name of an unnested > > Model::Package must be unique within the extent; i.e. in the context of > > the Model::ModelPackage. Without such a constraint, an operation on > > ModelElement to resolve a qualified name cannot guarantee to return just > > one object. > > > > If we were to add a Constraint to the MOF Model to ensure that the fully > > qualified name always resolved to at most one object, you would not be > > able to put many versions of a metamodel into one Model::ModelPackage > > extent. This would impact on existing MOF 1.x implementations. > > > > If we are going to change this, I think we should wait until MOF 2.0. It > > could be done in the context of the yet-to-be-drafted MOF 2.0 Versioning > > / Federation / Repository RFP. > > > > -- Steve > > > > > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin Matula" Cc: mof-rtf@omg.org Subject: Re: issue 4607 -- MOF RTF issue Mime-Version: 1.0 Date: Mon, 15 Oct 2001 08:56:56 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: $RIe9!d5!!!^,e9H<)e9 [Resent because is off the air.] > This is issue # 4607 Martin Matula" > > resolveQualifiedName operation > > I think it would be much more convenient to have resolveQualifiedName as a > "classifier_level" operation on ModelElement instead of "instance_level" > operation on Namespace. Now each time I want to resolve some object using > its qualified name, I have to find all outermost packages (which is quite > slow, because currently there is no better way of doing it than just iterate > through all package instances and check whether they are outermost), then > choose a package with a specified name and call resolveQualifiedName on that > package passing rest of the qualified name as a parameter. This is much more > complicated for users than it should be. Martin, This suggestion has a greater impact than you may realise. There is no Constraint in the MOF Model that says that the name of an unnested Model::Package must be unique within the extent; i.e. in the context of the Model::ModelPackage. Without such a constraint, an operation on ModelElement to resolve a qualified name cannot guarantee to return just one object. If we were to add a Constraint to the MOF Model to ensure that the fully qualified name always resolved to at most one object, you would not be able to put many versions of a metamodel into one Model::ModelPackage extent. This would impact on existing MOF 1.x implementations. If we are going to change this, I think we should wait until MOF 2.0. It could be done in the context of the yet-to-be-drafted MOF 2.0 Versioning / Federation / Repository RFP. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin Matula" cc: mof-rtf@omg.org Subject: Re: issue 4607 -- MOF RTF issue Mime-Version: 1.0 Date: Mon, 15 Oct 2001 08:59:01 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: :2K!!!$N!!b)M!!&;bd9 > BTW: I don't understand how you can reasonably store several versions of one > outermost package in a same extent. How do you distinguish between them? (By > an additional tag?) I thought that correct way to store several versions of > the same metamodel is to create several instances of MOF Model package and > store 1 version per 1 instance of MOF Model package - this way you don't > have this problem and the classifier_level resolveQualifiedName method would > work, because it would be invoked on a ModelElement class proxy that is part > of exactly one of these extents. There is no CORRECT way to do any of this. The MOF 1.x spec simply doesn't say anything about this question. For the record, one way to support multiple versions of metamodels in a Model::ModelPackage is to define some extra (proprietary) IDL for a metamodel directory that provides name + version lookup for Packages. There may well be others. -- Steve