Issue 12502: Clarify when a Payload is present in a submessage (dds-interop-rtf) Source: Real-Time Innovations (Mr. Kenneth Brophy, ken@rti.com ken.brophy@rti.com) Nature: Uncategorized Issue Severity: Summary: Some submessages can optionally include a payload. For example the DATA submessage includes a payload in most cases, except in some special cases where the submessage indicates unregistration and/or disposal of the data. Currently the presence of the payload is tied to the value of the unregister and dispose flags. This is inflexible and also does not support some use-cases where it is desirable to send data with dispose messages. It would be much better to make the presence of the Data Payload separately configurable in the submessage. Resolution: Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information Resolution: Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information Revised Text: Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information . Revised Text: Replace in Table 8.36 (Structure of the Data Submessage ) the row of element "DataFlag"with the following: DataFlag SubmessageFlag Appears in the Submessage header flags. Indicates to the Reader that the dataPayload submesssge element contains the serialized value of the data-object. Add in Table 8.36 (Structure of the Data Submessage ) a row with the following: KeyFlag SubmessageFlag Appears in the Submessage header flags. Indicates to the Reader that the dataPayload submessage element contains the serialized value of the key of the data-object. Replace in Table 8.36 (Structure of the Data Submessage ) the row of element "serializedData" with the following: element type Meaning serializedPayload SerializedPayload Present only if either the DataFlag or the KeyFlag are set in the header. If the DataFlag is set, then it contains the encapsulation of the new value of the data-object after the change.If the KeyFlag is set, then it contains the encapsulation of the key of the data-object the message refers to. ============================================================= Remove in Section 8.3.7.2.5 (Logical Interpretation) the existing second paragraph: Changes to the lifecycle are communicated using the StatusInfo SubmessageElement, which contains the DisposedFlag and the UnregisteredFlag. The settings of the DisposedFlag and UnregisteredFlag indicate whether the corresponding data-object has been disposed or unregistered (or both) by the writer. ============================================================= Revise in Section 8.3.7.2.5 (Logical Interpretation) the existing third paragraph: Changes to the value are communicated by the presence of the serializedData. This element is only present if the DataFlag is set. Changes to the value are communicated by the presence of the serializedPayload. When present, the serializedPayload is interpreted either as the value of the data-object or as the key that uniquely identifies the data-object from the set of registered objects. · If the DataFlag is set and the KeyFlag is not set, the serializedPayload element is interpreted as the value of the data-object. · If the KeyFlag is set and the DataFlag is not set, the serializedPayload element is interpreted as the value of the key that identifies the registered instance of the data-object. ============================================================= Replace in Table 8.37 the row of element "serializedData" with the following: element type Meaning serializedPayload SerializedPayload Present only if either the DataFlag or the KeyFlag are set in the header. If the DataFlag is set, then it contains a consecutive set of fragments of the encapsulation of the new value of the data-object after the change.If the KeyFlag is set, then it contains a consecutive set of fragments of the encapsulation of the key of the data-object the message refers to.In either case the consecutive set of fragments contains fragmentsInSubmessage fragments and starts with the fragment identified by fragmentStartingNum. ============================================================= Replace in Section 9.4.2.12 the existing first sentence of the first paragraph, and the wire representation, with the following: A SerializedPayload SubmessageElement contains the serialized representation of either the value of an application-defined data-object or the value of the key that uniquely identifies the data-object. Replace in section 9.4.2.12 (SerializedData): The wire representation for the SerializedData is: +---------------+---------------+---------------+---------------+ | | ~ octet[] serializedData ~ | | +---------------+---------------+---------------+---------------+ With: The wire representation for the SerializedPayload is: +---------------+---------------+---------------+---------------+ | | ~ octet[] serializedPayload ~ | | +---------------+---------------+---------------+---------------+ Change section name for 9.4.2.12 (SerializedData). New name is SerializedPayload 9.4.2.12 SerializedDataPayload Actions taken: May 20, 2008: received issue Discussion: End of Annotations:===== s is issue # 12502 Clarify when a Payload is present in a submessage Source: Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com) Summary: Some submessages can optionally include a payload. For example the DATA submessage includes a payload in most cases, except in some special cases where the submessage indicates unregistration and/or disposal of the data. Currently the presence of the payload is tied to the value of the unregister and dispose flags. This is inflexible and also does not support some use-cases where it is desirable to send data with dispose messages. It would be much better to make the presence of the Data Payload separately configurable in the submessage. Resolution: Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information . Revised Text: Replace in Table 8.36 the row of element .DataFlag.with the following: DataFlag SubmessageFlag Appears in the Submessage header flags. Indicates to the Reader that the dataPayload submesasge element contains the serialized value of the data-object. Add in Table 8.36 a row with the following: KeyFlag SubmessageFlag Appears in the Submessage header flags. Indicates to the Reader that the dataPayload submesasge element contains the serialized value of the key of the data-object. Replace in Table 8.36 the row of element .serializedData. with the following: element type Meaning serializedPayload SerializedPayload Present only if either the DataFlag or the KeyFlag are set in the header. If the DataFlag is set, then it contains the encapsulation of the new value of the data-object after the change. If the KeyFlag is set, then it contains the encapsulation of the key of the data-object the message refers to. ============================================================= Remove in Section 8.3.7.2.5 the existing second paragraph: Changes to the lifecycle are communicated using the StatusInfo SubmessageElement, which contains the DisposedFlag and the UnregisteredFlag. The settings of the DisposedFlag and UnregisteredFlag indicate whether the corresponding data-object has been disposed or unregistered (or both) by the writer. ============================================================= Revise in Section 8.3.7.2.5 the existing third paragraph: Changes to the value are communicated by the presence of the serializedData. This element is only present if the DataFlag is set. Changes to the value are communicated by the presence of the serializedPayload. When present, the serializedPayload is interpreted either as the value of the data-object or as the key that uniquely identifies the data-object from the set of registered objects. · If the DataFlag is set and the KeyFlag is not set, the serializedPayload element is interpreted as the value of the data-object. · If the KeyFlag is set and the DataFlag is not set, the serializedPayload element is interpreted as the value of the key that identifies the registered instance of the data-object. ============================================================= Replace in Table 8.37 the row of element .serializedData. with the following: element type Meaning serializedPayload SerializedPayload Present only if either the DataFlag or the KeyFlag are set in the header. If the DataFlag is set, then it contains a consecutive set of fragments of the encapsulation of the new value of the data-object after the change. If the KeyFlag is set, then it contains a consecutive set of fragments of the encapsulation of the key of the data-object the message refers to. In either case the consecutive set of fragments contains fragmentsInSubmessage fragments and starts with the fragment identified by fragmentStartingNum. ============================================================= Replace in Section 9.4.2.12 the existing first sentence of the first paragraph, and the wire representation, with the following: A SerializedPayload SubmessageElement contains the serialized representation of either the value of an application-defined data-object or the value of the key that uniquely identifies the data-object. Replace in section 9.4.2.12: The wire representation for the SerializedData is: +---------------+---------------+---------------+---------------+ | | ~ octet[] serializedData ~ | | +---------------+---------------+---------------+---------------+ With: The wire representation for the SerializedPayload is: +---------------+---------------+---------------+---------------+ | | ~ octet[] serializedPayload ~ | | +---------------+---------------+---------------+---------------+ Disposition: