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

Hi Sunava,

Thanks for sending this feedback.

Here are my high-level comments:

1) I am strongly opposed to greatly weakening the implementation  
conformance requirements. Changing the spec requirements so that  
existing implementations, even if they vary significantly in behavior,  
are already conforming. The reason we have specifications is to enable  
better interoperability. If the specification simply rubber stamps all  
existing implementations, which differ enough to cause  
interoperability problems, then we will do nothing to achieve this  
goal. There is a possible alternate goal of documenting for authors  
what current implementations do and giving them enough information to  
target the interoperable subset. But it turned out in the course of  
developing the spec that there were enough individually small  
differences to make such an excercise fruitless.

2) I am strongly opposed to requiring a whole new interface to be  
invented solely to add new methods and properties, for the following  
reasons:
     (a) This is contrary to the way other W3C specs have evolved. DOM  
Level 2 builds on top of DOM Level 1, it doesn't define a brand new  
set of different objects. We don't have window.document2 to access a  
DOM2-capable DOM. This has proven to be a successful strategy. In the  
meantime, "DOM Level 0" (not really a DOM level but a de facto set of  
incompatible interfaces) continues to lack formal specifications for  
many details and remains a major area of interoperability problems  
between browsers. Given this, I think your citation of DOM Level 0  
does not appear to present a good model for future standards.
     (b) Feature testing for individual properties and methods, and  
using library code to make up the difference, is a simple, well - 
understood and time-tested technique. It is simpler than having  
alternate access for completely different interfaces, which is likely  
to slow adoption relative to extending the interface and promoting  
feature testing.
     (c) Supporting two different interfaces with major overlap  
increases implementation complexity.


To address some specific points:

On Sep 25, 2007, at 7:35 PM, Sunava Dutta wrote:

> 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.

There are a number of ways to mitigate the compatibility risk to IE  
that don't involve watering down the spec that much:

A) Microsoft could document the differences IE has relative to the  
spec, and explain which are essential for compatibility. The spec  
could be changed to be closer to IE. This would help preserving your  
compatibility while also improving interoperability for other user  
agents, which is far better than just failing to define the behavior.  
Unspecified or underspecified behavior is what brought the web to the  
current poor state of interoperability it now suffers, and I consider  
it unacceptable to continue such practices in a modern spec.

B) Microsoft already has an IE-specific legacy interface that could be  
used for a 100% backwards-compatible version of XHR: new  
ActiveXObject("Microsoft.XMLHTTP"). Support for the new  
XMLHttpRequest() syntax is new to IE7, therefore it is likely that old  
or even new IE-specific content uses the ActiveXObject syntax. Content  
that exclusively uses the XMLHttpRequest syntax is  more likely to  
depend on Firefox behavior. Therefore it seems unlikely the  
compatibility risk with XHR is that severe, indeed, it might be  
outweighed by the sites that would newly work.

C) If Microsoft is unwilling to either change its code or document its  
behavior in detail, then it seems like your best bet would be not to  
claim conformance to the spec. This would be unfortunate but would at  
least honestly advertise the lack of interoperability. Meanwhile other  
implementations could continue to converge behavior based on the spec.

> ·        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.

I fail to see how defining a whole new object would make this any  
better. Are you saying IE is willing to add brand new interfaces, but  
unwilling to add completely new methods and properties to existing  
interfaces? In this case, wouldn't that require adding a brand new  
interface to the Window object, thus contradicting your point?  
Contrary to what you say, I think defining a whole new object will  
slow adoption more than new properties that are easily tested for from  
script, and easily emulated by library code when missing.


> ·        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.

Some of these requirements could perhaps be relaxed, but some seem  
normative references seem required. The alternatives I can think of to  
normatively referencing the relevant XML specifications would be  
either to copy and paste their contents, or to leave XML parsing  
undefined. Both of these approaches seem unacceptable. I hope you  
would not similarly object to referencing RFC2616.

Regards,
Maciej