KeepAlive message depend on the parameter

• PublishingInterval (WriterGroup)
• KeepAliveTime (WriterGroup) (The minimum value shall equal the PublishingInterval)
• KeyFrameCount (DataSetWriter)

These three parameters are independent of the Message Mapping.

If KeyFrameCount is 0 or >1, there can be KeepAlive messages (also for JSON message mapping)

I disagree with MatthiasD's note https://opcfoundation-onlineapplications.org/mantis/view.php?id=5372#c12220 .

The part where he has it wrong is: "If KeyFrameCount is 0 or >1, there can be KeepAlive messages (also for JSON message mapping)".
That might be what the intent of the spec was, but the spec does not allow that currently.

In reality, the Delta Frames are only defined in UADP mapping. As opposed to that, for JSON, the spec does not describe that they exist, nor how they should look like. The only logical conclusion for the reader is that they do not exist in JSON - because he cannot construct them.

Technically Delta Frames exist for JSON. The spec may be silent on it.

In UADP Delta Frames are special since they contain an array of index/value pairs for the changed fields.
In JSON, the name of the field is always provided and therefore the index is not necessary.
A Delta Frame with JSON is just a regular message that does not contain all fields.

If the missing clarification for Delta Frames is the only remaining issue, this can be fixed.

Added clarification for key and delta frames in JSON encoding:

7.2.3.3 DataSetMessage
A key frame DataSetMessage or an event based DataSetMessage contains name and value for all fields of the DataSet.
A delta frame DataSetMessage contains only name and value for the changed fields.

Added in OPC 10000-14 - UA Specification Part 14 - PubSub Draft 1.05.26.docx

I think the clarification resolves 99% of the issue, thank you.

But I am reopening this issue just for one last consideration: If both delta and key frames exist in JSON, and their only distinction is that the key frame "contains all fields", it is impossible to distinguish key frames without having the metadata. You can say that this was the intent and that the subscriber always must have the metadata. But, it would be easy to resolve it e.g. by adding something MessageSubtype or MessageKind field to JSON NetworkMessage header.

Consider the following use cases where the necessity to have the metadata causes a problem:

The Delta Frames is basically a protocol-only concept to save bandwidth. Semantically, on the application level, it "should not exist": a (data-based) DataSet is is seen by the consuming application as a stream of incoming "packets" where each packet has all the fields.

If all you want to do is, for example, transform the stream with Delta/Key frames to a stream that can be consumed by the application (the one that always has all fields), you need to assemble the data from the last Key Frame and the data from subsequent Delta Frames. This means that you cannot emit any data to the application before the first Key Frame arrives. If you have explicit indication of which frame is the Key Frame (as it is in UADP), you can simply wait for a message with that indication. But with JSON, I would have no way to tell which frame is the key frame, without having to do all the stuff that relates to obtaining the metadata. I cannot, for example, write a simple logger that would log one DataSet data per row, without the metadata. I cannot even write a processor that would remove the Delta Frames and generate a stream with Key Frames only, for easy consuming by other applications, without the metadata. And what's missing is really just a single bit of information that would distinguish the Key Frames from Delta Frames.

Added MessageType to 6.3.2.3.1 DataSetMessageContentMask
Added MessageType to 7.2.3.3 DataSetMessage

Agreed to changes edited in Draft 1.05.27 in virtual F2F.

We should have an 1.04 errata for this issue

Added to errata 1.04.10
Need to clone to Nodeset for 1.04.10

Agreed to 1.04.10 Errata.