John Cowan wrote about MicroXML:
"But I don't think it's fair to describe this as a slightly smaller square peg in a round hole."
Hi John, I hope you are well. (And no disrespect to anyone intended, by my comments here: I will err on the side of overstating to avoid the constant digressions and cheeseparing that reasonableness requires :-) though I am not attempting to troll.)
At this stage, it should be axiomatic that any dialect of XML based on quasi-technical qualities like "simplicity"* (or perhaps even "liberality") is doomed to find no consensus, traction or uptake. And it is clear that there is no will by people who have implemented XML subsets (especially embedded into other language) to agree to an external standard specification: like markdown or regular expressions, unity would only be approximated by cross-pollenation and experience. Experts don't make standards, communities do.
To me, the big flaw in the argument for 100% compatible minimalism is that it is essentially backwards-looking. What brave new world does it open up? ... and the people who only do partial implementations will just see it as an irrelevant attempt to stifle them.
XML was not a profile of the original SGML, SGML needed to be tweaked to support it, just as SGML would need to be tweaked to support modern HTML. That is not a fault of SGML or XML or HTML, it is not a regrettable hack, it is the way life (and SDLC) is. What the formalized standards give us is, when an incompatible dialect is required, a way to specify the new thing in terms of deltas (like Annex A of MicroXML) so that existing tools (and documents) can be upgraded rather than re-implemented.
Which is not to say that any advance on XML would not support many documents that also could be accepted as MicroXML or CanonicalXML. Indeed, an XML dialect with no DOCTYPE declaration but predefined standard public entity sets is already supported by WebSGML (
IMPLYDEF DOCTYPE - See http://xml.coverpages.org/wg8-n1929-g.html), though the other change to disallow CDATA marked sections is not. (It matters not because compatibility with those things are important for developers, but because it suggests that the scope of the work for implementing the feature in existing tools could be quite limited.)
We have to consider whether the minimalist approach is not just lazy thinking: a rut. "Simplifying SGML to XML was good, therefore simplifying XML to something else will be better." But XML also extended SGML in numerous significant ways: not the least that the entire approach to characters was thrown out because the new technology of the ISO 10646 repertoire had superseded the 1980s approach. Seeing that you have to support a compelling new functionality (like Unicode) sets of a cascade, where you can say "we needed an SGML declaration before because of character sets, but we don't need that now": complexity of declaration could be reduced without reducing the richness of markup.
For example, lets take the issue of disallowing comment declarations. MiniXML takes the approach, if I understand it, to not support them because developers read the text into trees where only element nodes are supported. But that only means that the comments should be stripped, doesn't it? The developer requirement is in no way compromised by having comments: so the only rationale for not providing them is actually just the quasi-technical consideration (by which I mean something between wise expert rule-of-thumb and groundless, ill-founded, immoderate, flop-generating OCD) of minimalism.
Evolution not amputation!
Cheers
Rick
