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
