Issue 10747: Typo in section 3.1.4.2.1 (data-distribution-rtf) Source: PrismTech (Mr. Erik Hendriks, erik.hendriks(at)prismtech.com) Nature: Uncategorized Issue Severity: Summary: Problem: Section 3.1.4.2.1 speaks of tables and rows, it is suggested to change this into topics and instances to correspond better with DCPS terminology. It is also suggested to speak of 'fields to uniquely identify the object' instead of 'fields needed to store a reference to that object'. It is also wise to change the word application in the last sentence of the last paragraph to implementation, as this mechanism is worked out by a DLRL implementation, not an application. Solution: Replace: Each DLRL class is associated with at least one DCPS table, which is considered as the 'main' table. A DLRL object is considered to exist if it has a corresponding row in this table. This table contains at least the fields needed to store a reference to that object (see below). To facilitate DLRL management and save memory space, it is generally desirable that a derived class has the same main table as its parent concrete class (if any)5, with the attributes that are specific to the derived class in an extension table. For example, this allows the application to load all the instances of a given class (including its derivations) in a single operation. With: Each DLRL class is associated with at least one DCPS topic, which is considered as the 'main' topic. A DLRL object is considered to exist if it has a corresponding instance in this topic. This topic contains at least the fields to uniquely identify the object (see below). To facilitate DLRL management and save memory space, it is generally desirable that a derived class has the same main topic as its parent concrete class (if any)5, with the attributes that are specific to the derived class in an extension topic. For example, this allows the implementation to load all the instances of a given class (including its derivations) in a single operation. Resolution: Revised Text: Actions taken: February 14, 2007: received issue Discussion: End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 14 Feb 2007 12:20:34 -0500 To: issues@omg.org, data-distribution-rtf@omg.org From: Juergen Boldt Subject: issue 10747 -- DDS RTF issue X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org This is issue # 10747 From: "Erik Hendriks" Typo in section 3.1.4.2.1 Problem: Section 3.1.4.2.1 speaks of tables and rows, it is suggested to change this into topics and instances to correspond better with DCPS terminology. It is also suggested to speak of 'fields to uniquely identify the object' instead of 'fields needed to store a reference to that object'. It is also wise to change the word application in the last sentence of the last paragraph to implementation, as this mechanism is worked out by a DLRL implementation, not an application. Solution: Replace: Each DLRL class is associated with at least one DCPS table, which is considered as the 'main' table. A DLRL object is considered to exist if it has a corresponding row in this table. This table contains at least the fields needed to store a reference to that object (see below). To facilitate DLRL management and save memory space, it is generally desirable that a derived class has the same main table as its parent concrete class (if any)5, with the attributes that are specific to the derived class in an extension table. For example, this allows the application to load all the instances of a given class (including its derivations) in a single operation. With: Each DLRL class is associated with at least one DCPS topic, which is considered as the 'main' topic. A DLRL object is considered to exist if it has a corresponding instance in this topic. This topic contains at least the fields to uniquely identify the object (see below). To facilitate DLRL management and save memory space, it is generally desirable that a derived class has the same main topic as its parent concrete class (if any)5, with the attributes that are specific to the derived class in an extension topic. For example, this allows the implementation to load all the instances of a given class (including its derivations) in a single operation. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org