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
