RE: [xml-dev] Choosing a target name for a processing instruction

["Bullard, Claude L \(Len\)" <len.bullard@intergraph.com>]

Somewhat the problem that X3D had to solve too.  An XML specification 
without a semantic/object model or at the very least, natural language 
descriptions of the business rules for handling the data in 
a limited set of cases and handling the specification itself 
in all cases is a job 1/4 done.  This becomes more obvious if the 
language is intended to control rendering and behavior.  MusicML 
possibly qualifies (any behavioral/rendering notation does).  It 
isn't as obvious in the data transport game.

As to PIs, the fact that so many XML processors don't handle 
them says the XML specification designers' job was only 
1/2 done.  MusicML is trying to use them for what they were 
intended for only to discover that XML processor implementors 
dropped the ball for technical religious reasons and that the 
specification winked at that and nudged it along.

PIs ARE out-of-band.  That's the whole point.  Only very small 
groups flying under the radar can keep an XML or any local 
specification with global markets coherent.  It's a dynamic universe 
because local semantics are the only kind there are.  As the 
reach increases, so does the noise.

The secret of Extensible ML is that it isn't. 

len


From: Rick Jelliffe [mailto:rjelliffe@allette.com.au]

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.