Pull request #302 has been merged, which updates the introductory page of the MNX Specification to provide some additional context about the reasons why MNX exists. We hope this expanded introduction will help newcomers to MNX understand both the motivations for and the benefits of the new format.
We discussed the issue of how MNX should be versioned (discussion #301), and agreed on a design where in order for an MNX document to be valid, it must have a top-level
mnx object containing a
As a principle, the co-chairs agreed that because we will try to always maintain backwards compatibility for each version of MNX, there is no need for semantic versioning, and thus we will use a single integer for the version, which is the simplest and most JSON-like way to encode the version.
We also touched on the issue of what file extensions should be used for MNX documents, and a simple proposal can be found in discussion #305. Feedback is welcome.
The remainder of the meeting was spent discussing the encoding of inner beams (issue #299). We were unable to arrive at a satisfactory design in the meeting, but a lot of useful ideas were exchanged, including considerations about the trade-offs of using the same
beams object to encode both outer and inner beams. Adrian will add more details about the discussion and some further proposals for encoding following the meeting.
The next co-chairs’ meeting will be on Thursday 6 July 2023.