The ElementConformsToProfile association crosses the boundary between the Interop namespace and the Implementation namespace. The association is instantiated in both namespaces, so you can enumerate it in either namespace.

The endpoint references in any instance of the ElementConformsToProfile association include the namespace for the endpoint. If you access the referenced endpoint, such as with a GetInstance() method, the request is directed to the provider in the correct namespace.

For example, if you enumerate the class OMC_ElementConformsToRecordLogProfile in the Interop namespace, you get an object that associates an instance of OMC_RegisteredRecordLogProfile in the Interop namespace with an instance of OMC_IpmiRecordLog in the Implementation namespace. The endpoint references look similar to these:

ConformantStandard =
   root/interop:OMC_RegisteredRecordLogProfile.InstanceID=”IPMI:vmware-host SEL Log”

ManagedElement = 
  root/cimv2:OMC_IpmiRecordLog.InstanceID=”IPMI:vmware-host SEL Log (Node 0)”

If you enumerate the class OMC_ElementConformsToRecordLogProfile in the Implementation namespace, you get an object in the Implementation namespace that is otherwise identical to the object in the Interop namespace.

Regardless of which namespace provides the ElementConformsToProfile instance, the endpoint references work the same. If you do a GetInstance() for the ConformantStandard endpoint, the CIM server returns an instance of OMC_RegisteredRecordLogProfile in the Interop namespace. If you do a GetInstance() for the ManagedElement endpoint, the CIM server returns an instance of OMC_IpmiRecordLog in the Implementation namespace.

To simplify the diagrams in this document, the ElementConformsToProfile association is pictured as a single object on the boundary between namespaces, rather than as two objects, one in each namespace. See Base Server Scoping Instance Associated with Profile Registration for an example diagram.