FW: Feedback from the IE Team: Web API XHR Draft

Re-summarizing the points of our feedback regarding the XHR draft for the public list.

*        Interoperability/Compatibility for v1 spec for XHR is critical if the spec is to achieve consensus.  XHR was first implemented a decade ago, and a huge amount of existing content relies upon the stability of the existing implementation.  The v1 XHR spec should seek to ensure interoperability between the existing client implementations and the deployed base of content.

*        All new functionality/features should be specified in a new Level of the XHR specification. This will permit developers the freedom that comes with a new object without the risk of incompatibility with the hundreds of millions of existing browsers that implement XHR today. As you know, the purpose of versioning is to guarantee this compatibility while ensuring that innovation can proceed without risk.  This reminds me of the DOM L1 vs DOM L0, where the DOM L1 spec was engineering to include all new functionality over the DOM L0 which was assumed to be baseline interoperable across browsers.

*        The thread below has more details and specific instances.
Thanks!


From: Sunava Dutta
Sent: Tuesday, August 28, 2007 4:20 PM
To: Anne van Kesteren
Cc: Chris Wilson; Cyra Richardson; Doug Stamper; Zhenbin Xu; Levent Besik; Eric Lawrence; Marc Silbey
Subject: Feedback from the IE Team: Web API XHR Draft


Hello Anne,

I've taken a pass at the spec and have a few comments below...



*        As you can imagine, we have a huge commitments to developers who build on IE and maintain legacy sites on IE. Compatibility consequently is not optional for us. We can't break existing compat. The object in its current form has been out there for years, is very widely deployed and browsers like FF model our implementation.

o   The challenge arising from the existing draft comes in the level of detail defined in the spec. For example, a number of algorithms specified in the spec (such as that for the open call) do not allow for accommodating different UA's. For a new specification this would be great. For a spec that is based on existing technology that's widely implemented around IE's behavior this is a challenge since IE does not adhere to the algorithm.

o   The spec specifies the table of the errors that should be returned and the exact text and type of the errors. The types and text of errors inherit from other W3C specs that we don't support. We return our own errors here that do not match syntactically the errors the W3C defines although they are thrown for the same events. Specifying the exact text of the error is not recommended.

o   If we were to make changes (not possible)  we would still leave web developers maintaining the majority of sites out there with the legacy XHR that's compatible with IE while trying to support the new one creating manageability problems.

o    Our testing load to simply verify compliance to the W3C draft is too great given the level of detail, the stability of our implementation and the fact that the draft is a moving target.

o   The ask here is the level of granularity/ and specificity be reduced. It's currently too authoritative in depth. We had signed off on your draft last year. This was mostly compatible with IE and FF while being helpful for web developers. A simple description of the open call and the types of parameters allowed, including which ones are optional would be great.

*        The current draft introduces new entities to the object. We're ok with creating a new object (or versioned XHR object) in order to ensure that the standards can advance. However, a vast majority of developers will not be able to reliably use this as the millions of pages build around current IE XHR will not support them. This consequently will be a adoption blocker for the standard.

o   Ensure all new entities like constants, flags etc are versioned or in a new object.

*        The draft frequently cross references specifications in the W3C.For example, the spec makes references to the DOM 3 events and core, namespaces in XML, Window Object 1.0 etc (Some of which are drafts themselves). We fail to see the value in implicitly embedding other large specs. Simplicity and standing on its own would be good.





http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8#text-response-entity-body


--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer
One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418
FAX# (425) 936-7329