> Why is this? Xerces can report PIs...

Well, maybe I'm doing something wrong, but when I tried to use

  ProcessingInstruction pi = doc.createProcessingInstruction("feature", "");

the result was

<?feature ?>

instead of

<?feature?>

Multiple XML parsers complained that a document using the former is
not well-formed. Maybe there's a different way to make it work, but
just adding some simple PI data seemed more robust, and it was a
trivial fix.

Unfortunately I think this is moot for this case. One application that
needs this is written in Flash ActionScript, which only handles two
types of DOM nodes: elements and text. (Attributes are handled via a
separate attributes property.) Processing instructions seem to be
discarded, no matter what the XML spec says should happen, even in
Flash 8. If I'm wrong about that, please let me know!

I think the reading application will be able to handle things by
(shudder) exploiting a side effect in how the writing application
works. It's not clean, but it may do the job until we get a MusicXML
1.2 out. That just needs to happen before the writing application
changes enough to break this side effect.

Currently we leave validation policy up to each individual
application, which has worked pretty well in practice. Because later
versions are supersets of earlier versions, it's easy to check for the
MusicXML version and just ignore any extra elements or attributes you
don't understand. The syntax and semantics of the existing DTD subset
doesn't change. If that wasn't true, perhaps we would need more
elaborate policies.

Thanks again,

Michael Good
Recordare LLC
www.recordare.com