Issue 8695: Key Qualifiers Missing in MOF (mof2core-rtf) Source: SAP SE (Dr. Axel Uhl, axel.uhl(at)sap.com) Nature: Uncategorized Issue Severity: Summary: MOF has always lacked the capabilities to navigate an association qualified by the values of properties of the end to which to navigate. This has been a feature in UML since at least UML 1.3. When implementing MOF, this leads to the unpleasant effect that in order to pick elements from a collection returned from navigating a to-many association requires iterating over all elements returned and filtering for the ones meeting the desired criteria. The way MOF works, this makes it impossible to provide an efficient implementation that yet is standard-compliant. Key qualifiers address exactly this issue. However, when the UML was split into infrastructure and superstructure, this valuable UML feature was placed into the superstructure, thus not being accessible by the MOF specification. MOF itself doesn't provide its own approach to qualified navigation either. A concrete example of why the current situation is less than optimal is the UML with its association between Namespace and NamedElement, using role names "ownedMember" and "namespace." When navigating to a member of a namespace with a particular name, one has to enumerate all elements owned by that namespace and compare its name with the name looked for. The effort scales with the number of elements contained by that namespace, and there is no way for a repository to provide an efficient implementation for that in a standard-compliant way. A fix for this problem would be to move the association from UML::Classes::AssociationClasses::Property to itself with properties named "qualifier" and "associationEnd" to InfrastructureLibrary::Core::Basic and connect it to InfrastructureLibrary::Core::Basic::Property instead. With this, MOF2 could use this useful feature, and a language binding for MOF2 could use this to offer qualified navigation. Repository implementations may provide a naive implementation at least, whereas advanced repositories may use the opportunity to maintain internal index structures that facilitate performant qualified access. I don't know whether this changes anything in the way an issue is handled by the OMG, but I've already talked to several vendors, current MOF implementors and active OMG contributors (also see Cc list), and there is wide consensus that this would be a very helpful change. Resolution: Revised Text: Actions taken: April 11, 2005: received issue October 10, 2012: moved to the MOF 2 Core RTF Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== iler: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 11 Apr 2005 09:58:25 -0400 To: issues@omg.org, uml2-rtf@omg.org, mof2xmi-ftf@omg.org, mof-rtf@omg.org From: Juergen Boldt Subject: issue 8695 MOF issue This issue is parked at the UML 2 RTF until the MOF RTF (Core, I guess) is chartered This is issue # 8695 From: "Uhl, Axel" Key Qualifiers Missing in MOF MOF has always lacked the capabilities to navigate an association qualified by the values of properties of the end to which to navigate. This has been a feature in UML since at least UML 1.3. When implementing MOF, this leads to the unpleasant effect that in order to pick elements from a collection returned from navigating a to-many association requires iterating over all elements returned and filtering for the ones meeting the desired criteria. The way MOF works, this makes it impossible to provide an efficient implementation that yet is standard-compliant. Key qualifiers address exactly this issue. However, when the UML was split into infrastructure and superstructure, this valuable UML feature was placed into the superstructure, thus not being accessible by the MOF specification. MOF itself doesn't provide its own approach to qualified navigation either. A concrete example of why the current situation is less than optimal is the UML with its association between Namespace and NamedElement, using role names "ownedMember" and "namespace." When navigating to a member of a namespace with a particular name, one has to enumerate all elements owned by that namespace and compare its name with the name looked for. The effort scales with the number of elements contained by that namespace, and there is no way for a repository to provide an efficient implementation for that in a standard-compliant way. A fix for this problem would be to move the association from UML::Classes::AssociationClasses::Property to itself with properties named "qualifier" and "associationEnd" to InfrastructureLibrary::Core::Basic and connect it to InfrastructureLibrary::Core::Basic::Property instead. With this, MOF2 could use this useful feature, and a language binding for MOF2 could use this to offer qualified navigation. Repository implementations may provide a naive implementation at least, whereas advanced repositories may use the opportunity to maintain internal index structures that facilitate performant qualified access. I don't know whether this changes anything in the way an issue is handled by the OMG, but I've already talked to several vendors, current MOF implementors and active OMG contributors (also see Cc list), and there is wide consensus that this would be a very helpful change. ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org Subject: RE: issue 8695 MOF issue Date: Thu, 21 Apr 2005 21:47:46 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 8695 MOF issue Thread-Index: AcVBM+k/wKL8fFGnQKKRXVGOQ7SgPAFper9A From: "Pete Rivett" To: "Jim Amsden" , "Kerry Raymond" Cc: , "Juergen Boldt" , , , X-Virus-Scanned: by amavisd-new at sentraliant.com MOF defines metamodel-driven interfaces for the functionality Jim describes. I think that the interfaces should be defined in such a way that they permit efficient encapsulated implementations to be provided for common scenarios. And in a heterogeneous client-server environment (i.e. not completely in-memory access). The point of the issue is that the current interfaces are too granular to allow efficient implementation for a common set of scenarios. I agree, and hence think we should consider a solution in the standard. This need not affect the structure of the meta-metamodel (such as is being requested in the issue) but could consist of adding new operations to the reflective (and generated) interfaces. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. 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 -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Thursday, April 14, 2005 9:35 PM To: Kerry Raymond Cc: issues@omg.org; Juergen Boldt; mof-rtf@omg.org; mof2xmi-ftf@omg.org; uml2-rtf@omg.org Subject: Re: issue 8695 MOF issue This sounds like a good idea, but it may not be necessary to include it in MOF. The purpose of MOF is to provide a standard way to define metamodels so that they can be interchanged and maniuplated in interoperable ways. To facilitate this, EMOF was an attempt to specify the minimum required modeling constructs necessary to capture the structure of metamodels. CMOF adds (among other things) the ability to specify constraints in order to capture more information about metamodels. Eventually we may have "executable MOF" to define full metamodel semantics. MOF explicitly stays out of the area of efficient client access because it does not presume to know what clients might want to do. Therefore, an implementation should feel free to provide operations and services that do provide more efficent access such as the selection capability described below. This will not effect the structural definition of metamodels, or metamodel interchange. Therefore could be considered out of scope for MOF. "Kerry Raymond" 04/11/2005 07:35 PM Please respond to "Kerry Raymond" To , , , , "Juergen Boldt" cc Subject Re: issue 8695 MOF issue My feeling is that this is a MOF-to-language-mapping issue rather than a MOF issue. Kerry ----- Original Message ----- From: Juergen Boldt To: issues@omg.org ; uml2-rtf@omg.org ; mof2xmi-ftf@omg.org ; mof-rtf@omg.org Sent: Monday, April 11, 2005 11:58 PM Subject: issue 8695 MOF issue This issue is parked at the UML 2 RTF until the MOF RTF (Core, I guess) is chartered This is issue # 8695 From: "Uhl, Axel" Key Qualifiers Missing in MOF MOF has always lacked the capabilities to navigate an association qualified by the values of properties of the end to which to navigate. This has been a feature in UML since at least UML 1.3. When implementing MOF, this leads to the unpleasant effect that in order to pick elements from a collection returned from navigating a to-many association requires iterating over all elements returned and filtering for the ones meeting the desired criteria. The way MOF works, this makes it impossible to provide an efficient implementation that yet is standard-compliant. Key qualifiers address exactly this issue. However, when the UML was split into infrastructure and superstructure, this valuable UML feature was placed into the superstructure, thus not being accessible by the MOF specification. MOF itself doesn't provide its own approach to qualified navigation either. A concrete example of why the current situation is less than optimal is the UML with its association between Namespace and NamedElement, using role names "ownedMember" and "namespace." When navigating to a member of a namespace with a particular name, one has to enumerate all elements owned by that namespace and compare its name with the name looked for. The effort scales with the number of elements contained by that namespace, and there is no way for a repository to provide an efficient implementation for that in a standard-compliant way. A fix for this problem would be to move the association from UML::Classes::AssociationClasses::Property to itself with properties named "qualifier" and "associationEnd" to InfrastructureLibrary::Core::Basic and connect it to InfrastructureLibrary::Core::Basic::Property instead. With this, MOF2 could use this useful feature, and a language binding for MOF2 could use this to offer qualified navigation. Repository implementations may provide a naive implementation at least, whereas advanced repositories may use the opportunity to maintain internal index structures that facilitate performant qualified access. I don't know whether this changes anything in the way an issue is handled by the OMG, but I've already talked to several vendors, current MOF implementors and active OMG contributors (also see Cc list), and there is wide consensus that this would be a very helpful change. ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ To: "Kerry Raymond" Cc: issues@omg.org, "Juergen Boldt" , mof-rtf@omg.org, mof2xmi-ftf@omg.org, uml2-rtf@omg.org Subject: Re: issue 8695 MOF issue X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Thu, 14 Apr 2005 16:34:48 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/14/2005 14:34:52, Serialize complete at 04/14/2005 14:34:52 This sounds like a good idea, but it may not be necessary to include it in MOF. The purpose of MOF is to provide a standard way to define metamodels so that they can be interchanged and maniuplated in interoperable ways. To facilitate this, EMOF was an attempt to specify the minimum required modeling constructs necessary to capture the structure of metamodels. CMOF adds (among other things) the ability to specify constraints in order to capture more information about metamodels. Eventually we may have "executable MOF" to define full metamodel semantics. MOF explicitly stays out of the area of efficient client access because it does not presume to know what clients might want to do. Therefore, an implementation should feel free to provide operations and services that do provide more efficent access such as the selection capability described below. This will not effect the structural definition of metamodels, or metamodel interchange. Therefore could be considered out of scope for MOF. "Kerry Raymond" 04/11/2005 07:35 PM Please respond to "Kerry Raymond" To , , , , "Juergen Boldt" cc Subject Re: issue 8695 MOF issue My feeling is that this is a MOF-to-language-mapping issue rather than a MOF issue. Kerry ----- Original Message ----- From: Juergen Boldt To: issues@omg.org ; uml2-rtf@omg.org ; mof2xmi-ftf@omg.org ; mof-rtf@omg.org Sent: Monday, April 11, 2005 11:58 PM Subject: issue 8695 MOF issue This issue is parked at the UML 2 RTF until the MOF RTF (Core, I guess) is chartered This is issue # 8695 From: "Uhl, Axel" Key Qualifiers Missing in MOF MOF has always lacked the capabilities to navigate an association qualified by the values of properties of the end to which to navigate. This has been a feature in UML since at least UML 1.3. When implementing MOF, this leads to the unpleasant effect that in order to pick elements from a collection returned from navigating a to-many association requires iterating over all elements returned and filtering for the ones meeting the desired criteria. The way MOF works, this makes it impossible to provide an efficient implementation that yet is standard-compliant. Key qualifiers address exactly this issue. However, when the UML was split into infrastructure and superstructure, this valuable UML feature was placed into the superstructure, thus not being accessible by the MOF specification. MOF itself doesn't provide its own approach to qualified navigation either. A concrete example of why the current situation is less than optimal is the UML with its association between Namespace and NamedElement, using role names "ownedMember" and "namespace." When navigating to a member of a namespace with a particular name, one has to enumerate all elements owned by that namespace and compare its name with the name looked for. The effort scales with the number of elements contained by that namespace, and there is no way for a repository to provide an efficient implementation for that in a standard-compliant way. A fix for this problem would be to move the association from UML::Classes::AssociationClasses::Property to itself with properties named "qualifier" and "associationEnd" to InfrastructureLibrary::Core::Basic and connect it to InfrastructureLibrary::Core::Basic::Property instead. With this, MOF2 could use this useful feature, and a language binding for MOF2 could use this to offer qualified navigation. Repository implementations may provide a naive implementation at least, whereas advanced repositories may use the opportunity to maintain internal index structures that facilitate performant qualified access. I don't know whether this changes anything in the way an issue is handled by the OMG, but I've already talked to several vendors, current MOF implementors and active OMG contributors (also see Cc list), and there is wide consensus that this would be a very helpful change. ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ ================================