joeberkovitz
commented
2 years ago @notator I think this is just some remaining work to be done, a gap needing correction just as you said. Dimensions can be optionally supplied for a <score> element, which just means that any pages created on an as-needed basis for that score, e.g. when printing it, will use those dimensions. This is not really different from including dimensions at the <page> level, but it allows a document to specify overall page dimensions for a score when they are known, without having to micromanage every single system break by including a raft of individual <page> elements.
I was going to propose a set of style properties to address this but was derailed this week by some minor health issues. It is not complicated and it should wind up looking just like putting optional dimensions in attributes of <score> or <page>. The CSS print specification already offers a nice model. Styles make sense here since they are always optional and can be speced and overridden at multiple levels of the hierarchy.
Finally, I think you have misunderstood @dspreadbury's comment. What Daniel said was:
I don't believe we ever contemplated making one of the goals of the new standard that it should replace the file formats already in use by existing, mature music notation applications, because that is not a goal that would ever be likely to be achieved.
By "file formats" he would seem to clearly mean the proprietary file formats of Dorico, Sibelius, Finale, etc. not MusicXML, and I absolutely agree with him on that point as we have discussed it many times. However, there is no intention of restricting MNX to only live within the expressive limits of MusicXML, otherwise the co-chairs would have little interest in continuing this effort (and I would never have initiated it in the first place).
notator
According to https://github.com/w3c/mnx/issues/266#issuecomment-982784740, we have now agreed that spatial dimensions are optional for
<score>elements. There is, however, no reference to dimensions, optional or otherwise, in the current<score>documentation. This needs to be corrected.I'd like to use optional dimensions to solve the impasse experienced in #270:
Applications that read
<score>elements containing no spatial dimensions have to use their own internal defaults to display the score. MNX is being used, in this case, as an interchange format like MusicXML.If the
<score>element does contain spatial dimensions, then it completely describes a particular score, and can be used as a fully fledged music notation format that could, in the long run, replace proprietary formats.Implementing styles for
<score>'s spatial dimensions is non-trivial, but possible. Its also a task that could be postponed.So I'd like to propose that the stipulation of
<score>'s spatial dimensions should be explicitly forbidden in MNX 1.0. Only the styles allowed by MusicXML should be allowed in MNX 1.0. That restricts MNX 1.0 to being a replacement for MusicXML, which is what, I think, @dspreadbury wanted in https://github.com/w3c/mnx/issues/270#issuecomment-981415348.Once MNX 1.0 exists, we can consider adding spatial dimensions to
<score>. This may not be what the Co-Chair originally had in mind, but it follows logically, and the advantages to the music industry, are large and obvious (to me at least). We can, of course, continue that debate elsewhere.Note that disallowing spatial dimensions in
<score>means both thatgapis undefined, and that #247 needs to be reviewed.