Separation of concerns

[bhamblok]

We should define to what extend the MNX file-format is scoped.

• Is MNX solely about music semantics?
• Does MNX contain layout information?
• Does MNX contain functional information?
• Does MNX contain performance information?

This has been discussed before, but I'm referencing to w3c/musicxml#294 where a proposal is being made to include score-following data into musicXML.
This is not the same discussion again about CWMNX vs GMNX.

I propose to make MNX extendable to other formats, and I like to reference (again) to:

• HTML (which is only about semantics)
• CSS (which is only about layout)
• JavaScript (which is all about functionality)

This Github-issue should resolve to a clear implementation/explanation in the explainer-text and the spec about separation of concerns.

• Is MNX solely about music semantics? YES
• Does MNX contain layout information? YES - as we decided in Use container element for style decls #83, however did not agree :-)
• Does MNX contain functional information (like score-following?) I would say NO. Not inside the MNX-format itself.
• Does MNX contain performance information? (like audio playback) maybe via references to audio or midi-files or through a direct implementation of midi data? I would again say NO. We have lots of audio-formats or MIDI data for that, and we could derive the midi-data from the semantical data...

[adrianholovaty]

Hi @bhamblok,

MNX-Common isn't primarily about semantics — it will also include presentational information. We just don't know the details yet. :-)

Put another way: we want MNX-Common to be a successful format, so if it doesn't include presentational information, it's very unlikely to gain adoption. We don't just want MNX-Common to support new use cases, we also want to support the existing use cases of MusicXML.

I'll leave this issue open if you have any further questions; otherwise I'll close it within a week. Thanks for the questions!

[bhamblok]

I agree on including as much information as possible of all "layers" we can think of (Semantics, Presentational/Layout, Performance/Audio, ...). But I would like to argue if all of this data should be captured in one and the same file?

I propose to make multiple file-formats, each for it's own purpose. That way we can use one and the same "semantics" file on which we could apply different presentational layers, performance-layers, ... all within the context of the end-user.

I would like to reference to "the hype of light and dark modes" on the web/phones these days. The semantics of the applications/websites aren't changing at all. But the layout (at least the colours) is/are totally mixed up.

Wouldn't it be nice if we could do the same for sheet music? Alter the presentation depending on the device and the context which is being used by the end user?

Also, think about the diversity of end-users... (this subject might be a bit out of scope, but...) billions of people (mostly in south-east Asia or Africa) have no access to high speed internet, or might only have access to a feature-phone (having no access to desktop computers). For them, to be able to use apps which will make use of MNX, it would be so much overhead to download an MNX-file containing so much information, while they might only need the semantics and one presentational layer...

Another (more obvious) example... changing note-spacing and/or fonts... Wouldn't it be nice to be able to just load a different presentational-layer? Instead of heaving to create a complete new file, which basically would be a copy of the original file, having altered just 2 values?

I'm just talking about presentation here, while in the performance-area we can foresee a gigantic pool of new ideas to be implemented on top of MNX.

I propose to first agree on all aspects of semantics. Saving all of this under "MNX". At the same time, during this standardisation-effort of the semantics, we can/could talk about (and define) default presentational and performance aspects. But I propose to make these "other layers" to be scalable and extractable into different file-formats later on.

In future this will benefit to us all... The (digital) world is evolving to distributed and deduplicated data-models... so please let us be prepared for that to ;-)

[adrianholovaty]

You put your finger squarely on one of the trickiest things we still need to figure out with MNX-Common. :-)

I agree in theory that it would be very nice to support multiple presentation "files" for the same piece of semantic music. Taking that idea further, one could imagine more generic "house styles" that could apply to an entire collection of MNX-Common files — super interesting and useful!

At the same time, we need to be practical. MNX-Common import and export should be as easy as with MusicXML — that is, using a single file. Requiring people to import (or export) separate "semantic music" and "presentation" files is not only too much of a barrier to entry for end users, it's also likely a dealbreaker for nearly all existing notation applications (which might need to completely rethink their internal data models).

I think the trick will be to enable a true separation of content from presentation while at the same time retaining simplicity and usability for end users and providing a clear way forward for notation applications. We need to find a balance.

[bhamblok]

OK :-) Unfortunately you have a good point that it could be a dealbreaker for nearly all existing notation applications :-/

I'm just a bit afraid we are going to redo the roadmap that other formats have taken, and that we are not learning from their development and experience.
As an example: HTML in early days had presentational data directly in the format. Like the <font>-element which had "size", "color" and "face"-attributes. Developers today are laughing at "semantics" like that... It doesn't even exists anymore and is deprecated since HTML5.

Are we sure we are going to do that all over again? At least let us prepare for the possibility to extract the different layers from one another, and make a good balance for this.

How do we go forward? Should we try to make a proposal that "some" elements could be declared inside MNX as an xml-element as well as in an externally defined and linked resource?

[bhamblok]

Having thought about my concerns overnight, I now think it would hold us back too much to even try and create multiple standards for al of these layers at the same time.
I realise a baby needs to grow step by step. I only hope MNX will not need 30 years of development to reach a point where the standards of the web stands today.
I'm closing this issue for now, others may reopen it if or when they have similar concerns at some point in time.