IE8 XDomainRequest conspiracy theory

UPDATE: This conspiracy theory has been debunked. Microsoft said they would implement various aspects of the access-control spec in IE8. For what it’s worth, those Microsoft guys are ok with me 🙂

I love conspiracy theories… particularly when I get to make one up! Here is my conspiracy theory for how Microsoft will try to force both the W3C and other browser makers to adopt IE8‘s XDomainRequest mechanism/API.

A bit of background first: the Web Applications Working Group (WAF) has been working on a spec that allows browsers to do cross-domain requests (basically for creating mashups securely). The spec is called Access-Control, and has been in development for three years. The spec was being edited by Anne van Kesteren of Opera Software, but under heavy influence from Hixie of Google, Jonas Sicking from Mozilla, and Maciej Stachowiak from Apple, to name a few people/companies. Marc Silbey, the representative from Microsoft to the working group, was also participating for a while, but he dropped off the radar as Microsoft shifted into high gear during development of IE8 (actually, Microsoft assigned 3 people to participate in WAF, but only Marc did). A few months ago, to coincide with the release of the IE8 beta, Microsoft announced XDomainRequest… aspects of which look, in a lot of ways, very similar to Access-Control, but with some key differences.Then, to the shock of the working group, they brought XDomainRequest to the W3C for standardization knowing full well that WAF had been working on Access-Control for over three years!

Naturally, Microsoft’s actions pissed a lot of people off because, as I stated in an email, they are just ignoring over three years of work into the Access-Control spec, they created their own proposal and implementation in secret and now are attempting to fast track it through standardization ignoring due process.

To which, Sunava Dutta, from Microsoft, responded by saying “incorrect” and prompting Chris Wilson, Chief Architect of IE, to respond:

You know, there is an idea that perhaps we’re not IGNORING the work on Access Control, and perhaps we simply disagree with some of it.

Which prompted me to respond:

…If Microsoft would have found the time to collaborate [in the WAF WG], all this stuff could have been resolved progressively and the [Access-Control] spec would probably be done by now (as has been shown, the MS proposal has just as many issues, if not more, than the Access-control spec; so trying to do it in-house did not yield a more adequate solution).

Which beckons the question, why did Microsoft stop participating in WAF to go off and create their own version of access-control? And here is the conspiracy theory:

  1. Microsoft joins the WAF working group in 2007
  2. Microsoft “borrows” Access-Control idea
  3. Microsoft implements its own XDomainRequest mechanism in IE8beta
  4. Mozilla implements Access-Contol in FireFox 3, but then pulls the feature at the last minute (consequently leaving a gap in the cross-domain request space for Microsoft to jump in)
  5. Microsoft delays Access-Control work by sending in comments a year late (just before it was about to go to Last Call) and putting in their XDomainRequest proposal for standardization. Meanwhile…
  6. Microsoft rolls out IE8, quickly gains market share (no help from Vista, of course 🙂 )
  7. Other browsers must now implement Microsoft’s solution/spec because business and developers start using it
  8. Microsoft’s spec become a W3C Recommendation, Access-Control spec dies in the ass.

We are currently at point 5, with Microsoft using delay tactics to slow down standardization of Access-Control.

Why do I care? I’ve only contributed to Access-Control from the sidelines by attending face-to-face meetings and asking Anne dumb questions. However, a lot of C02 has been wasted flying everyone to meetings to talk about this spec; that’s thousands of dollars and thousands of kilos of C02 going to waste. Another thing that annoys me is, as I already stated, that Microsoft has every chance to provide feedback to the working group to fix/discuss any issues they’ve had with the Access-Control spec.

Widget spec is now Widget Specs

In an effort to expedite the standardization of widgets, the Web Application Formats Working Group yesterday decided to split the Widgets 1.0 Specification into three (or more) specs:

Other specs may also follow, particularly:

Other documents are still under development too:

We are aiming to have all these done (ie. Last Call) by October. However, now that the document split has happened, I should be able to get the packaging format done fairly quickly.

We have more or less now settled on the configuration language format. The elements are going to be:

  • <widget width=”” height=”” id=””>
    • <title: the title/name of a widget
    • <description> a description
    • <author email=”” url=””> some details about the author
    • <license> paste your GPL here! 🙂
    • <icon src=””> the icon
    • <access network=”true|false” plugins=”true|false”> if your widget need to get online
    • <content src=””> some file in the widget archive

Only <widget> and <content> are mandatory at this point.

The processing model for the XML is going to be quite forgiving. The only thing that will cause an error, is not having a well-formed document.  For example, the following the following would result in “The Awesome Super Dude Widget” as the title:

<widget xmlns="">
     The <blink>Awesome</blink> 
     <author email="">Super Dude</author> Widget</title>

The unrecognized elements are simply ignored, but their text content is extracted. This makes processing more forgiving and allows for extensibility and some graceful degradation. I also want to push that the widget should function if the namespace is omitted.

We are also currently investigating how we are going to deal with internationalization in the configuration document format. We are looking at following ideas from the Best Practices for XML Internationalization.

WAF and WebAPI are dead. Long Live WebApps Working Group!

The charters of both  the W3C Web Application Formats and WebAPI Working Groups have now expired (as of the 15th of November, 2007) meaning they are effectively dead (although still twitching!). From their ashes will rise a new merged working group called the Web Applications Working group… hopefully by the 31 of January.

According to the new proposed charter, the missions of the new working group is to:

…is to provide specifications that enable improved client-side application development on the Web, including specifications both for application programming interfaces (APIs) for client-side development and for markup vocabularies for describing and controlling client-side application behavior.

The new Web Applications Working Group is chartered with the continual development of the following specifications:

Specification FPWD LC CR PR Rec
ClipOps spec 2007-Q2 2008-Q4 2009-Q2 2009-Q4 2010
DOM 3 Core bis spec          
DOM 3 Events spec 2007-Q2 2008-Q2 2008-Q4 2009-Q4 2010
Element Traversal spec 2007-Q2 2007-Q4 2008-Q2 2008-Q4 2008
Access Control spec 2006-Q2 2008-Q1 2008-Q3 2009-Q4 2010
File Upload spec 2007-Q2 2008-Q2 2008-Q4 2009-Q4 2010
Language Bindings spec 2007-Q2 2008-Q2 2008-Q4 2009-Q4 2010
MAXIM spec 2008-Q1 2008-Q3 2008-Q4 2009-Q2 2009
Network API spec 2008-Q2 2009-Q1 2009-Q3 2010-Q2 2010
Progress Events spec 2007-Q2 2008-Q2 2008-Q3 2009-Q2 2009
Selectors API spec 2007-Q2 2007-Q4 2008-Q2 2008-Q4 2008
XHR Object spec 2007-Q2 2008-Q2 2008-Q4 2009-Q4 2010
Widgets spec 2006-Q4 2008-Q4 2009-Q1 2009-Q3 2009-Q4
Widgets Requirements 2006-Q3 2008-Q4 2009-Q1 2009-Q3 2009-Q4
Window Object spec 2007-Q2 2008-Q2 2008-Q4 2009-Q4 2010
XBL2 spec 2006-Q2 2010 2011 2013 2013
XBL2 Primer 2007-Q3 2010 2011 2013 2013

Another cool thing about the new working group is that it is modeled on the HTML Working Group, meaning that is open, transparent (no secret chats on the members list) and anyone will be able to participate via the public mailing list.

I’ll continue to edit the Widget Spec and Requirements, and possibly continue to help out with the XBL Primer.  I’ll continue to be part of this new working group for a least 1 year, as I my PhD program ends in March 2009… and hopefully longer, if someone gives me a job to continue working on specs! 😉