Never mind the browser, let's do MicroXML

[Uche Ogbuji <uche@ogbuji.net>]

I think Henri's presence as a voice from the HTML5 world (including explanation of some of the looney physics in that world) has taken this discussion off the rails.  That is not a personal attack on Henri.  First of all, I really appreciate his sustained involvement in this thread, and he has presented a combination of facts with the authentic opinions of browser vendors, and it is very good to have both as background.

But I do not think MicroXML requires browser participation to succeed.  I do think eventual browser participation would be a huge plus, and that is why I appreciate that James's contribution at least attempts HTML5 compatibility.  Browser vendors would never admit it now because they would never want to admit they might come round to something outside their control, but I think that if MicroXML can make a strong start on its own, they'll eventually take it up.  They are probably hurting from managing the complexity of "standards-mode" XML code paths right now as the rest of us are.  And what would constitute a strong start?  Well were MicroXML to gain tangible support from some of the folks on this thread, the likes of James, Mike Kay and Rick (who I know has a different proposal, but one more suited to XML.next, which we might still come to?), it could end up getting pretty far along on the "server" side, and that in itself would have a lot of benefits.

I do want to put one thing to bed: All this Vendor Capitalist Apprentice robot parroting of "what's the business case? Huh? Huh?"  Most of us work on XML tools, at various levels of the stack.  I've implemented at one time or another dozens of XML specifications.  The cost in unnecessary complexity of all this work is staggering.  For my part, I would love to have a path towards simplifying this work in the long term, even if it meant some added difficulty in the short term.  I can tell you from engagement with users that XML and some of its support standards as they are right now really introduce inefficiency all over the place.  It's not just having to again once a week explain why folks are failing to match default namespaced elements from XPath and the like.  It's all the cruft cases these lead to in the code.

So nobody who matters for MicroXML should need some spiffy business case.  Common sense is always more than enough excuse for innovation.  Those who claim they need a business case before they have a look will come around when they catch up to common sense.

So I am proposing that we refocus analysis and polishing of James Clark's MicroXML from "what would browser vendors do" to "what are we as XML developers willing to do?"  I suspect the road might not need to be so terribly long before we have something we can stand up.


-- 
Uche Ogbuji                       http://uche.ogbuji.net
Weblog: http://copia.ogbuji.net
Poetry ed @TNB: http://www.thenervousbreakdown.com/author/uogbuji/
Founding Partner, Zepheira        http://zepheira.com
Linked-in: http://www.linkedin.com/in/ucheogbuji
Articles: http://uche.ogbuji.net/tech/publications/
Friendfeed: http://friendfeed.com/uche
Twitter: http://twitter.com/uogbuji
http://www.google.com/profiles/uche.ogbuji