OMF » OML - Measurement Library

I was about to file the same request (for the window size). I strongly support that to allow to have unambiguous data, and to be able to compare them correctly (an average on one sample is not the same as one on 100).

For the units, I'd have a preference for a metadata table, but it would make sense that the measurement points (and filters) provide an extended schema so this information can be obtained at the source.

The window size should be reported with each measurement so that, for interval-driven filters, one can still work out the number of samples that were processed, which may vary in each interval.

Maybe even the version/git tree id/build of the OML library could be relevant (let alone that of the reporting application) for later debug/reproduction of experiment.

From a further email exchange (mid August 2011) with Christoph, Max, and Thierry:

• The MP definition should be extending to include these metadata (i.e. unit, reference)
• The Filter definition should be extending to include these metadata (i.e. unit, reference, window size)
• The resulting metadata will be stored in separate dedicated "metadata table" to un-clutter the MP-derived table itself

In addition, we must support backward compatibility (at least for the next couple fo major releases...), thus it was suggested that these new features should result in additional API calls (suffixed by "2" for example) instead of changing the signature of the current API calls. In this case, this would related to the MP and Filter data structures, and registering functions.

Finally, it was suggested that the type being used for these metadata is String with a documented formatting convention.