mx matches element and attribute names as literal strings (e.g. "score-partwise",
"xlink:href"). This has two implications:
-
If a document declared a namespace prefix for MusicXML elements, e.g.
xmlns:foo="http://www.musicxml.org/..." and used <foo:score-partwise>, mx would
not recognize the element.
-
If a document used a different prefix for XLink, e.g.
xmlns:xbar="http://www.w3.org/1999/xlink" and used xbar:href instead of
xlink:href, mx would not recognize the attribute on <opus> and <link> elements.
Neither is a practical problem today - no known MusicXML files in the wild use
non-standard prefixes. But a fully namespace-aware XML processor would resolve these
by URI, not by prefix string.
Tracking this as a known limitation, not a priority fix.
mx matches element and attribute names as literal strings (e.g.
"score-partwise","xlink:href"). This has two implications:If a document declared a namespace prefix for MusicXML elements, e.g.
xmlns:foo="http://www.musicxml.org/..."and used<foo:score-partwise>, mx wouldnot recognize the element.
If a document used a different prefix for XLink, e.g.
xmlns:xbar="http://www.w3.org/1999/xlink"and usedxbar:hrefinstead ofxlink:href, mx would not recognize the attribute on<opus>and<link>elements.Neither is a practical problem today - no known MusicXML files in the wild use
non-standard prefixes. But a fully namespace-aware XML processor would resolve these
by URI, not by prefix string.
Tracking this as a known limitation, not a priority fix.