Feature request: Matrix metric

Issue

Matrices and vectors are common expressions in any kind of computation. Currently, the BICEPS standard does not offer native support of such, even though there are numerous applications, including for example:

• Any kind of navigated surgery, where position vectors (3x1), rotation matrices (3x3), rotation quaternions (4x1), or general transformation matrices (4x4) are transmitted. This includes optical, electromagnetic or inertial sensor data. The data may be relevant for documentation purposes, sensor fusion for improved precision and robustness, reducing the number of tracking systems in the OR or even inter-manufacturer operation of drills, navigation and imaging systems for drilling with restricted safe-zones.
• Robotic surgery, where the pose of the endeffector may be communicated to other devices, e.g., indicating "ready-to-grab".
• Endoscopes, reading or writing the intrinsic matrix.
• Image-based collision detection, e.g., between a C-Arm and an operating table.
• External control of an x-ray: A calibration-sensor positioned in the visible field of the X-ray source, determing the distortion matrix of the device and setting it over the network.

Aspects to be considered

• Atomicity: It is not possible to use multiple scalar numeric or string metrics, as it may cause the vector/matrix to be in an invalid state, when one scalar (e.g. the x coordinate) is updated to a new value, with the others are still holding the old value (e.g. the y and z coordinates).
• Vector vs. Matrix vs. Tensor. One may differentiate between these or introduce a single generic metric with arbitrary number of dimensions, each of arbitrary size.
• Maximal size: SDC is not designed to transfer large quantities of data for which other solutions exist, e.g., image data. Introducing a maximal size may prevent mis-use, but limit future applications.
• Dense vs Sparse: The latter may be more performant in certain applications. Supporting these may reduce traffic.
• Further specification and semantic encoding: Introducing specific types of vectors, e.g., defining the order for quaternions or row/column-wise notation. May prevent misuse and benefit interoperability, but limit future applications.

Possible short-term workarounds:

• NOT RECOMMENDED: mis-use of existing waveforms metric. While it is designed for vector data of arbitrary size, there are several assumptions on the data, that hold not true for general purpose vectors and especially metrics, e.g. the dimension being time, equidistance between values and non-atomic handling of waveform data.
• NOT RECOMMENDED: use of existing string metric. While introducing a simple pattern for storing the matrix entries in a string is a performant and simple solution, the pattern itself is not standardized and interopability is in no way guarantueed. E.g. "NxMx...;row-major;a;b;c;d;..."