On Dec 10, 2007, at 11:16 AM, Charles McCathieNevile wrote:
On Mon, 10 Dec 2007 17:54:49 +0100, Maciej Stachowiak
<[EMAIL PROTECTED]> 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
