Stripped the issue marker, this seems more about general process.
On Mon, 10 Dec 2007 21:14:16 +0100, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
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.
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
