Adopt Normative Definitions

[e-lo]

The OMX project currently describes its data structure and goals across multiple wiki pages:

• Data Structure 0.2 – abstract data structure description.
• Open matrix requirements – project-level requirements for storage, access, and evolution.

These documents are excellent background, but they mix abstract data-structure ideas, project requirements, and on-disk details in ways that make it harder to:

• Implement new language bindings consistently;
• Validate whether a given HDF5 file is truly “OMX-compliant”;
• Reason about compatibility as the format evolves.

This issue proposes a modern, normative, versioned specification that:

1. Clearly defines the OMX File Specification (on-disk .omx file layout) using RFC 2119 language (MUST, SHOULD, MAY etc) which is common across most modern data specificaitons
2. Defines minimum capabilities for Official OMX language bindings (Python, R, Java, C++, C#, etc.);
3. Differentiates between official and community-supported OMX language bindings
4. Clarifies definition plug-ins in host applications;
5. Leaves existing documents as non-normative background.

Implementation

Please see the associated PR.

Ambiguities to resolve

• Should we strictly require zlib compression for portability, or just “strongly recommend” it?
• Do we want to reserve any standard attribute keys (e.g. year, scenario, units) across the ecosystem?