Re: Unsound ECMAScript objects

On Sun, 31 Oct 2004, Jim Ley wrote:
>> 
>> If you see any issues with the way these methods are defined above, 
>> please send them to whatwg@whatwg.org. (Assuming you want them fixed, 
>> anyway.)
> 
> Equally with the WHAT-WG specification you cite specifically saying "It 
> is very wrong to cite this as anything other than a work in progress. Do 
> not implement this in a production product. " It is not usable by 
> another specification.

SVG 1.2 says much the same thing. It's a clause intended to deter 
implementations from implementing drafts, not a clause intended to ensure 
working groups reinvent new ways of doing old things.


> > > it is also inappropriate for use in anything but ecmascript (or 
> > > other scripting languages). Not using Events etc.
> > 
> > I urge you to re-examine the definitions cited above, as they do use 
> > DOM events and should in fact be compatible with most languages.
> 
> If they use DOM events, then they're not re-using existing 
> implementations - and it's more confusing to have similarly named but 
> different implementations than it is to have something with a completely 
> new name.

The Web Apps draft specifies an interface known as XMLHttpRequest which is 
intentionally compatible with existing UAs. It also defines that objects 
implementing that interface must implement the EventTarget interface. This 
is a superset of the existing functionality. There's no "different" 
implementation here, it's just an additional interface for compatibility 
with W3C recommendations.


> > > --we have 4 non-interopable implementations
> > 
> > Please let me know which areas you believe are non-interoperable, so that
> > I may file bugs on the relevant implementations and get them fixed.
> 
> They're not bugs, there's no specification

Yes there is, we were discussing it. It is in a draft stage, just like the 
SVG 1.2 interface.

In any case, incompatibility with IE on an interface first implemented by 
IE which was implemented in other UAs in order to be compatible with IE is 
always a bug.


> > Is this interface exactly URIRequest? If not, then apparently the 
> > working group does not consider compatibility with that subset to be 
> > important, and in that case using XMLHttpRequest or DOM3 Load and Save 
> > instead of reinventing a new API would seem to be a better solution.
> 
> but as you've just acknowledged XMLHTTPRequest needs work, there's no 
> fully existing interopable ones and you need to redefine things in terms 
> of DOM events, breaking backwards compatibility anyway.

As I have already explained, the use of DOM Events does not break 
backwards compatibility.


> DOM 3 L+S isn't a solution in this as it doesn't meet the requirements 
> to set http headers etc. and is tied to XML.

It would seem, in that case, to be much more sensible to extend DOM3 Load 
and Save in the few ways required to handle the use cases it does not 
handle, than it would to reinvent a whole new interface.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 31 October 2004 20:29:48 UTC