...

Data formats sometimes overlap protocol definitions because some protocols (but not all) define the data format in its specification.  VISS / W3C Gen2 is an example of a protocol definition that defines both the protocol interactions between client and server, and the data exchange format that fits the VSS model.  Ultimately, any chosen (stack of) protocols must at some point clarify define the transferred data formats, otherwise no understandable exchange can be had, and this page is intended to support the development of such a definition.

Looking at a wider set of protocols it is clear that we have some more work remaining.
The data exchange protocols we discuss fall into different categories, each requiring some more work on defining value exchange data formats:

1. A protocol does not (yet) cover all variations of data exchange.
   1.  VISS / W3C Gen2 covers a lot of usage, but supports primarily fetching a single "latest value" measurement, and transferring instant updates according to subscriptions.  Exchanging a set of historically measured values has been discussed for future extension.  The picture we are looking at here should include also exchanging sets of previously measured data between systems.  We can benefit from adding transfer of historically measured data, or derived statistics (e.g. get the average value over time instead of transferring all values), for tying measurements to physical location in addition to the timestamp, and similar extensions. 
      This analysis is hopefully useful also for protocols like W3C "Gen 2" to cover these bases When this page was written, W3C VISS protocol (v2) supported subscription to updates and on-demand fetching of the current value of one or several, specified signals in one go.  In its latest form it has a significant number of query parameters and filters, and supports the fetching of a series of historical recorded values (i.e. TimeSeries according to the definitions below).  VISS v2 now specifies features that mirror most of the types of messages listed here, with the exception of Snapshots.
2. A protocol defines only a "transport"
   1. We often discuss protocols that define some behavior of data transfer, such as pub/sub semantics, but they are designed to be generic and therefore support any type of information to be transferred by the protocol.  This means they do not (can not) define the format of the content of the data container (payload), and frequently are set up to transfer just any arbitrary sequence of bytes.   This makes those technologies widely applicable, but choosing them is not enough without also defining the payload format.  Examples of some such protocols would be MQTT or WAMP, but the principle extends to many "generic" protocols or frameworks.
3. A protocol defines transport, query semantics, and even a few expectations for the exchanged data format, but is still generic and requires additional definitions to become unambiguous for a particular case.
   1. Example:  GraphQL is a generic technology that clarifies a bit more about expected data semantics and formats but still requires a schema to be defined to indicate the exact underlying data model, what types of queries can be made using the GraphQL language, and other details such as the datatypes that are expected to be returned.   A schema must be defined for GraphQL, and for other similar situations, and that schema might also be derived from this generic analysis.

...

1. 1. Example 2:  To consume and process data in Apache Spark, Kafka and presumably for many other generic data-handling frameworks we also need to define schemas that define the format and content of the transferred data, in a similar fashion.  These

...

1. 1. protocols may also

...

1. 1. match category 2/3.

...

Definitions

(proposal, open for discussion)

...