Issue 10733: The classname in FullOid makes no sense in case of a 'local' Object model (data-distribution-rtf) Source: PrismTech (Mr. Erik Hendriks, erik.hendriks(at)prismtech.com) Nature: Revision Severity: Summary: Problem: When using a keyDescription set to "FullOid" in the XML mapping file, each OID field is accompanied by a class-name field that represents the actual type of a specific object instance (i.e. the name of the class that that object instance was instantiated to.) However, in case of a purely 'local' object model, this class name has no meaning outside the scope of the application that uses this local model. If the topics used for transport are also mapped to another 'local' object model, you get a confusing mix of local and global information in the same topic. This sort of confusion should be avoided at all costs: topics may only transport information that refers to the global information model, not to some local representation of it. Solution: Either allow the FullOid tag to only be used in case of a 'global' object model (default mapping, topic model is generated to match it), or describe that the class-name should not represent the name of a 'local' DLRL class, but rather the name of the topic that represents the state of that 'local' class. TBD. Resolution: Revised Text: Actions taken: February 14, 2007: received issue Discussion: End of Annotations:===== s is issue # 10733 From: "Erik Hendriks" The classname in FullOid makes no sense in case of a 'local' Object model Problem: When using a keyDescription set to "FullOid" in the XML mapping file, each OID field is accompanied by a class-name field that represents the actual type of a specific object instance (i.e. the name of the class that that object instance was instantiated to.) However, in case of a purely 'local' object model, this class name has no meaning outside the scope of the application that uses this local model. If the topics used for transport are also mapped to another 'local' object model, you get a confusing mix of local and global information in the same topic. This sort of confusion should be avoided at all costs: topics may only transport information that refers to the global information model, not to some local representation of it. Solution: Either allow the FullOid tag to only be used in case of a 'global' object model (default mapping, topic model is generated to match it), or describe that the class-name should not represent the name of a 'local' DLRL class, but rather the name of the topic that represents the state of that 'local' class. TBD.