• From: "Pete Cordell" <petexmldev@c...>
• To: "Uche Ogbuji" <uche@o...>,<xml-dev@l...>
• Date: Thu, 16 Dec 2010 17:00:35 -0000

+1

Pete Cordell
----- Original Message ----- 
From: "Uche Ogbuji" <uche@o...>
To: <xml-dev@l...>
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
> 

• References:
  • Never mind the browser, let's do MicroXML
    • From: Uche Ogbuji <uche@o...>