Checklist for submitting a schema change

[infojunkie]

As I rebuilt the MusicXML documentation, I got exposed to all the parts that make up the site, especially concerning the MusicXML schema. Based on this, I suggest the following list of "desirables" when publishing a schema change:

• A example from the (worldwide) repertoire that justifies the change. This would include a bibliographic reference to the music score (or closest approximation thereof) , and a clear scan of the relevant section of the score.
• The XSD change(s) in musicxml.xsd, container.xsl, opus.xsd and/or sounds.xsd - including the updated annotation/documentation sections that are affected by the changes.
• Any additional notes / deeper discussions go into the Markdown notes section of the site.
• A minimal MusicXML document that recreates the example section above - illustrating the use of the updated schema.
• A Markdown example including the example image scan and MusicXML document.
• Adding the above MusicXML document to the test folder to prove it correctly validates against the new schema and does not regress in future versions.
• An entry in the relevant version history document corresponding to the target release version.
• Edit the latest XSL transformation schema/toXY.xsl (currently to40.xsl) to remove the added elements / attributes that were added to the target release version.
• Update notationref.json to reflect the changes.

This list is open for discussion and refinement.

[infojunkie]

The test infrastructure now supports a schema change PR with the following checks at each commit:

• Ensuring that the 4 XSD schemas at schema/*.xsd are syntactically valid against XMLSchema.xsd
• Ensuring that all MusicXML files in tests/files (including symlinked examples in docs/** and files from the musicXmlTestSuite) are passing / failing against musicxml.xsd as specified in tests/assertions.json
• Ensuring that selected MusicXML files in tests/files are passing / failing against Schematron validations as specified in tests/assertions.json
• Ensuring that selected MusicXML files in test/files are correctly downgraded to the previous MusicXML version (using schema/toXY.xsl) and are passing / failing against the corresponding version of musicxml.xsd