Re: Never mind the browser, let's do MicroXML
+1 Pete Cordell ----- Original Message ----- From: "Uche Ogbuji" <firstname.lastname@example.org> To: <email@example.com> Sent: Thursday, December 16, 2010 4:18 PM Subject: Never mind the browser, let's do MicroXML >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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format