7.2.5.4 DataSetMessage
Added table with examples for RawData true and false.
Replaced description of VerboseEncoding on first level with following text agreed on in MQTT meeting today:

OPC 10000-6 defines two DataEncodings: CompactEncoding and VerbosetEncoding. They have the same structure except VerbosetEncoding includes default values so verbose messages are larger.
This specification defines a DataSet field encoding for the VerbosetEncoding which simplifies the encoding of Variants and ExtensionObjects by omitting UaType and UaTypeId fields with concrete DataType defined in the FieldMetaData. In this case the Variants at the top level are collapsed.
By default, DataSet fields can only be decoded by inferring the schema from the JSON message or if the DataSetMetaData describing the DataSet fields is available (i.e. from the DataSetMetaData messages).
There are two cases where the DataSetMetaData is not sufficient to unambiguously decode messages.
• DataSet fields with BuiltInType ExtensionObject and a value which is a subtype of the DataType in the FieldMetaData. The UaTypeId is needed to decode the value.
• DataSet fields with BuiltInType Variant. The UaType is needed to decode the value.
Note that the same problem exists when a field of a nested Structure has DataType BaseDataType or AllowSubTypes=TRUE.
If RawData=FALSE, then the Publisher always include the full Variant with the UaType or ExtensionObject with UaTypeId when encoding these fields at the top level or within a nested Structure.
If RawData=TRUE the Publisher will encode the Variant but not include the UaTypeId and UaType which means a OPC UA DataSetReader is not able to the DataTypes of the original values.
Publishers should avoid publishing data that cannot be decoded with knowledge of the DataSetMetaData. They may prohibit configuration of DataSets that have fields that would be ambiguous if RawData=TRUE.
Table 186 provides examples of field encoding with the different options.

Agreed to changes in F2F meeting.