Lists Home |
Date Index |
- To: "Rick Jelliffe" <firstname.lastname@example.org>,<email@example.com>
- Subject: RE: [xml-dev] Choosing a target name for a processing instruction
- From: "Bullard, Claude L \(Len\)" <firstname.lastname@example.org>
- Date: Mon, 1 May 2006 08:54:17 -0500
- Thread-index: AcZsALWWSoQFh9DjTlSQUIkZKzfmwABJISPQ
- Thread-topic: [xml-dev] Choosing a target name for a processing instruction
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.
From: Rick Jelliffe [mailto:email@example.com]
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
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
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.