Lists Home |
Date Index |
Michael Good wrote:
> We always encourage MusicXML developers to use validating parsers.
Yes, validation is useful for any non-toy work.
But the essense of extensibility is for the document to say what schema
it was written for, and the receiving application to have a policy on
unexpected elements or attributes. In other words, when a receiving
application validates using a fixed schema (rather than one suggested by
information in the document), it is setting a particular policy on
elements or attributes.
In the long run, you might also consider this approach: as well as your
strict schema, also have a very loose fallback schema that allows
extensions: if the incoming document fails against the strict schema,
the user is told the file is unusual and then asked whether they want to
attempt to continue (with the loose schema). That provides the benficial
inconvenience of invalidity without preventing import of extended documents.
> 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,
Why is this? Xerces can report PIs... (I can understand it if you have
some elements that are EMPTY that you might otherwise want to put a PI