Improve documentation of supports element with best practices

[mdgood]

Michael Cuthbert (@mscuthbert) raised an issue on the MusicXML forum about provide better documentation and best practices for the supports element:

It would also be helpful to get a more standard list of elements that can go into <supports> and get vendor support ... for honoring what is put in <supports>. It may also be important to encourage <supports type="no"> for explicitly indicating lack of support for a given item. Given the amount of musicxml out there already, it seems correct to assume that accidental display is supported even if there are no notated accidentals in the score and the <supports> is empty; so it might be prudent for a software package that does not support notated accidentals to be able to put <supports type="no"> for these.

See the MusicXML forum discussion at http://forums.makemusic.com/viewtopic.php?f=12&t=2389&p=6446.

[mscuthbert]

This arose again today in a musicxml document where a note is encoded as a dotted half note of duration of 2.5 qtrs (this appears in Brahms among other places. Quite often this is an error in encoding, so most processing systems would be right to ignore one or the other cases, but if there were a <supports> tag that could specify that cases like this might be deliberate, it would help.

Can I suggest that this case be standardized as:

<supports element="duration" type="yes" value="independent-from-type" />

This of course depends on whether an element like "duration" can appear multiple times in <supports> with different values. Otherwise pseudo attributes might be used:

<supports element="duration" attribute="independent-from-type" type="yes" />