Re: ISSUE-43: change to "common baseline"?

On Mar 19, 2006, at 3:59 AM, Anne van Kesteren wrote:

>
> On Sat, 18 Mar 2006 14:36:34 +0100, Jonas Sicking  
> <jonas@sicking.cc> wrote:
>> Would it really break backwards compatibility for ECMA-script  
>> implementations to change onreadystatechange from being a Function  
>> to being an EventListener?
>>
>> A function following the version 1 spec will not take any  
>> arguments. Such a function should work fine as an EventListener in  
>> version 2, it just would not get access to the Event object.
>>
>> Or are you worried about other bindings?
>
> The thing is that web browsers (as in Opera, Firefox, Safari,  
> Internet Explorer) are not the only browsers that will implement  
> this specification. For new implementations (SVG viewers for  
> example) it makes no sense to follow version 1.0 of the  
> specification in the case that version 2.0 would "contradict" it.  
> Now that doesn't make sense to me.
>
> The specification should just state what should be implemented. If  
> that isn't the case in some implementations they simply have to be  
> fixed. In the end we need two conforming implementations anyway.  
> (Or, whatever we decide for CR exit critera.)
>
> Things like "UAs SHOULD support send() without arguments" are also  
> just no good for exactly those reasons. It's fine for UAs to be non- 
> conformant to every part of the specification. Those things are  
> called bugs. Bugs should not affect the specification imho, only  
> some non-normative appendix on authoring guidelines. (Sorry for not  
> objecting earlier.)

I'm going to duck the specific issues for now and raise the question  
of what we are trying to do with this spec.

Specifications have many purposes, but here are two important ones:

1) It is a contract between implementations of the specification and  
users of the specification (i.e. content/apps). The contract is, "if  
you only rely on behavior that is required of implementations, then  
your content will work across implementations."

2) It is a contract among different implementations of the  
specification to implement things in an interoperable way, so that  
more content behaves the same across different implementations.

As I understand it, the goal for XMLHttpRequest 1.0 was entirely to  
satisfy goal #1, and defer progress on goal #2 to a later  
specification. So far, the thought has been to combine tighter  
specifications for some things that may be optional for 1.0 with  
additions of new features, in an XMLHttpRequest 2.0. This creates a  
tension, because it is useful to document an interoperable subset of  
existing de facto behavior, but on the other hand it would be a shame  
to have to wait a long time for a tighter specification that would  
improve the interoperability of implementations.

But maybe it would help resolve some of the tension by planning on a  
quick follow-on XMLHttpRequest 1.1 that does nothing but turn all the  
SHOULDs to MUSTs, without trying to add features. In fact, XHR 1.0  
could define a conformance class of "unconditionally conformant  
implementation" for implementations that satisfy all the SHOULD-level  
conformance criteria as well as the MUST-level ones. HTTP 1.1 defines  
such a conformance class for example.

Regards,
Maciej

Received on Monday, 20 March 2006 22:59:44 UTC