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

Hi Sunava,

Glad to get feedback from Microsoft on the spec.

I do however fully agree with Maciej here. If all we developed was a 
spec with a basic description of the various functions and what 
arguments they accept, we would not be accomplishing anything here. 
There are plenty of tutorials on the web that contain that information. 
In fact, I'm sure microsoft host a number of good ones.

The only thing such a spec would accomplish would be to allow the 
various UAs out there to claim that they conform to some sort of 
standard, which of course in and of itself has no value to anyone. Our 
goal is to increase interoperability on the web, and I don't see how 
that would be helped without describing in detail how XHR is implemented.

I would also be interested to know which specific things in the spec 
microsoft is worried will cause interoperability problems? The spec was 
specifically designed with compatibility with existing content in mind, 
so if there are things in there that will "break the web" then we should 
fix the spec.

Also, not wanting to change implementations of existing APIs is a much 
bigger problem than versioning the spec does will help you with. What 
happens if the initial release of the new version contains bugs? Will 
you not be able to fix those bugs in the next release without 
introducing a XHR2? If so, it seems very hard for a web author to get an 
instance of XHR across multiple browsers as he might need XHR3 in IE, 
XHR5 in Firefox, XHR4.5 in Opera etc.

If microsoft is worried about breaking existing customers if they make 
any changes to their implementation, and need versioning in order to be 
comfortable making any changes, I suggest versioning is added on a 
higher level. For example a top-level attribute indicating which version 
of IEs engine is desired.

Best Regards,
Jonas Sicking

Maciej Stachowiak wrote:
> 
> 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
>

Received on Wednesday, 26 September 2007 23:10:43 UTC