Provide a binary data format option in addition to JSON in the OSIsoft Message Format (OMF) spec.

Support the concept of time ranges / events EFs / spans as a pre-defined type in the OSIsoft Message Format (OMF) spec.

Support units of measure for types and streams in the OSIsoft Message Format (OMF) spec.

Add a data quality keyword to the OSIsoft Message Format (OMF) spec and allow specification of a data quality format.

When transferring data via satellite it is necessary to keep bandwidth usage to a bare minimum. Currently OMF must send all values regardless of whether they have changed or not. If it could send only the data parameters that have changed that would be very helpful.

Request for OMF writing to PI Server that CORS (Cross-Origin Resource Sharing) is supported.

I think it would be beneficial to have a Swagger Specification for OMF similar to what currently exists for the PI Web API. As a programmer, I would like to be able to reduce startup time by having a pre-existing libraries that allow me to reduce syntactical errors in HTTP requests by leveraging the intellisense provided by swagger specification libraries.

Allow reuse of a set of properties for multiple type definitions in the OSIsoft Message Format (OMF) spec.

In transportation, a common pattern is to use an ESB to gather all field data and make it the central point for interoperability. Examples include: JMS bus, Tibco ESB, HP OMi + IIB of Kafka, others. I believe it should be possible to configure those platforms to send OMF compliant messages, but i have no reference and can hardly estimate the approach and efforts needed.

Even though it will indeed be useful to be able to specify whether data should be retrieved in a step-wise fashion, for new PI Points (assuming you're writing data to a PI Connector), it's important to be able to specify that those tags should have the step attribute set to true, so that the step option is set at the central, database level where it can apply to all users who query that PI Point.

Right now, the documentation:

https://omf-docs.readthedocs.io/en/v1.0/Data_Messages.html

Mentions that "For each object, either typeid or containerid must be specified". However, it does not clearly state that you CANNOT include both in a data message, even if either the typeid or containerid is null (and the other is non-null). It's a minor distinction, but it helps prevent folks from trying to create a base class for a data message that includes both a typeid and containerid.

Add the ability to override the message-level CRUD mode for each object (Type, Container, or Data) within the body.

Add the ability to provide partial information for an existing data point. This is meant as a partial update which replaces values for some properties of a type without affecting others.

Ability to override Type-level property keywords on a Container level.