Re: ISSUE-119: names lengthComputable and total

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.

> 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.

>> 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".

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. Allowing a  
Final JSR spec which cut and pasted a W3C Working Draft  to affect  
what may change on the W3C side subverts the W3C Process. Clearly,  
agreements to note what W3C specs are a work in progress are not  
enough to prevent this.

So I'd like to request that Sun not copy immature Web API WG  
specifications into JSRs in the future.

Regards,
Maciej

Received on Monday, 10 December 2007 20:14:35 UTC