[
Lists Home |
Date Index |
Thread Index
]
Michael Good said:
>
> What we really need to do is add a new attribute to an existing
> element. In the absence of that attribute, In the absence of that
> attribute, it's more compatible with existing software to represent
> the data with a different element. The PI is basically saying "Even
> though the following element is of one type, you need to alter the
> interpretation to treat it more like this other element type." In the
> past we've always been able to handle interim new features via
> MusicXML's built-in extension elements, but that doesn't work here.
>
> Just doing an exact match on the PI target rather than having to do
> parsing of PI data certainly seems attractive.
A standard is an agreement. So talk to the major implementors of MusicXML
and see what they can cope with. Figure out your preferred position, and
see whether it disrupts anyone; agreement doesn't mean giving up
leadership.
MusicXML should set a policy for extensions. ("XML Governance" is an
emerging discipline.) A good policy would be "An implementation of
MusicXML should ignore any attributes in the document that are not in the
base DTD used." This has the expense that a non-validating application
cannot detect misspelled attributes, but it might still be the good
policy.
If you find that the MusicXML-accepting applications have indeed been
written robustly (to ignore foreign attributes) and some music marked up
using the new attributes will still play satisfactorily in applications
written for the old DTD (i.e. the syntax and the semantics are extensible)
then you should be OK.
It is very common that specs have a version number, but don't actually set
any policy for them. In particular, for differences between minor and
major versions. The way things stand, you would expect a major version
change to be a new namespace (if the original used namespaces), a minor
change to just add a few elements or attributes, and a change that
involves adding a new module of functionality to have that functionality
in a different explicit namespace.
Cheers
Rick Jelliffe
|
