Does MNX encode detailed horizontal layout information?

[joeberkovitz]

MusicXML is capable of encoding detailed information about the horizontal positions of many elements through the default-x attribute. This is not a required piece of MusicXML, and not all exporting applications provide it. Similarly, not all importing applications need it.

Many applications that require this information today in MusicXML use it in lieu of having their own layout engines, and use it to understand where various elements like staves, measures and notes have been placed on a graphical rendition that is provided separately in image form, exported from the same application that created the MusicXML.

Should CWMNX continue to support this type of encoding? It is arguable that GMNX is actually the better vehicle for doing so, since it encapsulates graphics and allows graphical elements and regions to be identified in various ways that are notationally neutral (but can still be traced back to semantic information).

[siennamw]

No, CWMNX should not continue to support this type of encoding. Non-semantic layout information should be in CSS styles alone, and semantic information will be captured elsewhere throughout the encoding. If it does have a place in MNX, it will be in GMNX only.

[mdgood]

I consider the CSS styling to be part of MNX, as MNX will need to invent its own way to represent styles within the CSS framework. I would say yes, we want to maintain this information, moving it into CSS as feasible.

If CWMNX is less capable than MusicXML for key use cases that will hinder adoption. Moving this into GMNX would be a significant usability issue for applications relying on this information, much more so than moving to CSS.

[joeberkovitz]

Just to capture a point for future discussion (since there obviously will be some!):

• What does "reflowable" mean for a CWMNX score, if the presentation includes information that relates only to one particular visual instantiation? default-x seems like something that can only be known in the context of a particular set of system widths and system breaks.

[siennamw]

If we follow @mdgood's view that CWMNX is the parent of a semantic XML music encoding language and an associated CSS dialect, then I would say the following: In my view, the XML part of a CWMNX encoding should not include information that only relates to one particular visual instantiation. Moreover, the CSS component of a CWMNX encoding should avoid applying styles that compromise the reflowability (not a word, and yet exactly the right word) of the score because this will cause accessibility problems and often prevent usable display of notation on screens of various sizes (ex. mobile devices).

In short, MNX is intended to be a web technology and reflowability is central to that. If you want a fixed visual instantiation, create a PDF or image file. (Side note: this will be a difficult and completely different issue in GMNX)

To bring this back to the topic of this thread, if default-x is only meaningful within a fixed layout, then it does not belong in MNX.

[joeberkovitz]

@siennamw overall I agree. But I don't understand why you feel GMNX cannot capture a fixed visual instantiation -- the SVG component of a GMNX encoding is functionally equivalent to a PDF or image file.

One aspect of GMNX is that it can (optionally of course) incorporate references back to semantic CWMNX elements in a source document from which it was generated. So if we have some GMNX element (say, a <g> that renders some measure) that refers back to the ID of the original <measure> element that it's a rendering of, it seems to me we get what we need, without either bringing visual instantiations into CWMNX or bringing semantics into GMNX.

We'd see this in a GMNX file: <g mnx:semantics="score.cwmnx#part1m23">...</g>

And this in the score.cwmnx file: <measure id="part1m23">...</measure>

[siennamw]

@joeberkovitz I see your point and I agree. Unlike CWMNX, GMNX is intended to capture a fixed visual instantiation, and SVG is indeed functionally equivalent to a PDF or image file. Perhaps some GMNX documents will have a degree of reflowability (multiple movements captured in separate SVG files, for example), but that is neither here nor there. I agree that your approach gets us what we need

without either bringing visual instantiations into CWMNX or bringing semantics into GMNX.

[mdgood]

MNX is intended to be a web technology, yes, but not only that. There are many use cases for CWMNX that do not involve the web and do involve encoding a specific visual representation of a score. Many of the Music Creation use cases for instance are similar to MusicXML use cases. CWMNX needs to support these use cases, not just the web use cases.

Capturing detailed horizontal layout information is a key element of many CWMNX use cases. We want to do as much as possible with CSS, but until we get into the design we really won't know what "as much as possible" is.

We also need to design CWMNX in a way that it can be automatically generated from existing MusicXML files. I don't believe this is possible if we relegate a specific visual instantiation to GMNX.

[joeberkovitz]

This has a heavy relationship to #13.