was Re: names lengthComputable and total

Stripped the issue marker, this seems more about general process.

On Mon, 10 Dec 2007 21:14:16 +0100, Maciej Stachowiak <mjs@apple.com>  
wrote:

> On Dec 10, 2007, at 11:16 AM, Charles McCathieNevile wrote:
>
>> On Mon, 10 Dec 2007 17:54:49 +0100, Maciej Stachowiak <mjs@apple.com>  
>> wrote:
>>
>>> What would look compelling to me is web content depending on the  
>>> specific names. That's more important than whether someone shipped an  
>>> implementation.
>>
>> That could indeed be a much more compelling argument. Can you show that  
>> such content does or does not exist?
>
> As far as I know, it does not. I think the burden of proof would be on  
> anyone who wants to claim it does. I don't think anyone is claiming  
> this, though.

I would imagine that some content exists, and if we hassled Ikivo we might  
find it. But I don't imagine a significant body of content (although it is  
theoretically possible).

>> Having an implementation that is difficult to change, shipped in  
>> millions of devices, does seem like an argument of some strength in the  
>> absence of a strong counter argument.
>
> I don't think the API we design for the Web should be driven by non-Web  
> uses like JSR-280. It's nice when they can benefit, sure, but the W3C's  
> mission is the Web.

That would be about my take on it too. It is also nice when we benefit  
 from similarity in work they have done, so it is not entirely one-way.

The fact that there is also web implementation (Ikivo is used in Web  
browsers as well as web-like products) is significant IMHO.

>>> I'll admit that method naming isn't the biggest issue. But it seems  
>>> like bad precedent to start giving weight to external standards that  
>>> copy very early stage W3C standards, as this subverts the W3C's own  
>>> standards process, which runs by different rules than the Java  
>>> Community Process.
>>
>> The base specification has been around for a long time (we inherited it  
>> from SVG), and it was pretty baked already. People have implemented,  
>> people have written it up (although it is only draft), and based other  
>> stuff on it. Others have just chosen equally bad names for the same  
>> thing. And fundamentally, this naming issue doesn't seem to be a really  
>> big deal.
>
> The spec has been significantly reworked since it started.  
> lengthComputable in particularly was removed entirely for a while and  
> added back in March 2007. The whole event design was changed  
> significantly based in part on my feedback. I'm not sure we can consider  
> it "pretty baked".

YMMV

> This specific issue isn't that big a deal. However, in the past in other  
> working groups, the argument "we can't change this because it's in  
> JSR-something-or-other" was used many times to reject comments that  
> pointed out serious substantive problems with the spec.

What other working groups do is a rough guide to what we might do. I am  
sympathetic to JSRs, but I waited until I had confirmation of the non-JSR  
work before making a "final" decision here (and as we have agreed, the  
issue is hardly a big one). I have equally been happy to run against JSR  
when it seemed the right decision.

So I think we are in broad agreement. (The devil, of course, will always  
be in the details, and those will come out case by case).

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Received on Monday, 10 December 2007 20:36:04 UTC