Thanks for all the great feedback!

We always encourage MusicXML developers to use validating parsers.
Music notation is complicated, so MusicXML has grown quite large to
accommodate everything that is needed for industrial-quality
interchange of documents between programs. Validation has been a huge
help in making document interchange work better for our audience of
composers, arrangers, engravers, publishers, and other musicians.

MusicXML has had its success in large part by being
developer-friendly. For instance, when we updated to MusicXML 1.1, we
made sure that all valid MusicXML 1.0 documents are also valid
MusicXML 1.1 documents. There's no way we can have the flagship
MusicXML writer produce invalid documents. Fortunately, SOAP's
limitations aren't an issue for MusicXML applications.

We have just two applications that really need this added
functionality ASAP - our writing application and a third-party reading
application. It turns out that writing a processing instruction
without a data field is problematic with our Java/Xerces combination,
so instead of using

<?feature?>

we are now using

<?treat-like feature?>

This indicates that the following element would really be treated as
another element if only that element had a little more extensibility
to it. This provides the extra generalization that Peter suggested,
without requiring any parsing overhead beyond doing two exact matches
instead of one.

Elliotte, you're right that any application that reads this processing
instruction won't be able to get rid of the PI-reading code.
Fortunately that may just be one application, though anybody else will
be free to join in. But we should be able to get rid of the PI-writing
code when MusicXML 1.2 comes out.

MusicXML is developed via an informal community process, so we can't
just release a patch version as quickly as we need for this feature.
As long as the reading application's parser can handle a simple
processing instruction, we should be OK.

Rick, we've already discussed this with the developers that needs this
feature now, and we'll be discussing this on our MusicXML list with
the major MusicXML implementers later today. I wanted the broader
advice of the XML developer community to help develop the initial
proposal. It has been very helpful. Thanks again!

Best regards,

Michael Good
Recordare LLC
www.recordare.com