RE: FYI: new NotInW3CSpecYet keyword added to bugzilla

Maciej Stachowiak wrote:
> 
> If Rob wanted to submit this draft to the Working Group, we would give
> it due consideration. If this draft was accepted as a W3C draft, but
> Rob wanted to still maintain a separate draft that had some extra
> material, we would probably be inclined to let bugs on that extra
> material go in bugzilla too.
> 
> Currently, this particular document has no relation to any W3C draft,
> so it doesn't seem particularly useful to track its issues in W3C
> space.

It is worth pointing out that WebSRT has no relation to any W3C Draft
either, nor has it been submitted to this or any other W3C Working Group
for consideration AFAIK (and when it comes to media in HTML5 I like to
think I am following along pretty closely). In fact it was for this reason
that Michael created the new keyword of "NotInW3CSpecYet" - because WebSRT
is NOT IN THE W3C SPEC YET ("...and may never be, and that is not under
the HTML WG decision policy and may never be.") 

WebSRT, like Rob's HTML 4.1 is the work product of essentially one author,
and in fact HTML 4.1 has been crafted very much like WebSRT, where *at
this time* the author is the final arbitrator of what stays and what goes,
and neither are (I believe) under the current W3C IP policy rules that
cover HTML5. The fact that Rob's work is less known amongst developers
than WebSRT should not be the grounds for consideration.

So it seems that it is indeed a very reasonable request that the W3C
consider sharing bugzilla for HTML-based work that is happening outside of
the actual W3C space, given that this is the case for WHAT WG, a group
that is not chartered under W3C rules, is not obligated to follow W3C
consensus policy, and works autonomous to the W3C... just like html4all. I
can understand that Michael and the W3C executive may want to think about
this for a day or so before reaching a decision, as it does establish a
precedent and might open the flood-gates for numerous other requests (and
so considerations regarding scalability, signal-to-noise, and use of
resources need to be contemplated), however the reasoning that you have
suggested should *NOT* be one of the factors under consideration, as it
establishes a double standard and in fact un-does the whole point of
creating the NotInW3CSpecYet keyword in the first place.

WebSRT is not a W3C work effort (nor has there been a request made to
consider it as such), and is not yet under consideration by the W3C for
inclusion in the HTML5 Draft in any formal way, and that point must be
clearly understood.

JF

Received on Tuesday, 14 September 2010 15:54:17 UTC