Re: [VTT] Consensus call: publish VTT under the 2014 Process?

Yes, well, this is mostly re-hashing old stuff.

A Rec version does supply a fixed reference, but anything with a stable URL can do that. A Rec version provides a version that can be referenced normatively by anyone that needs documents of a certain status and so on to be able to reference them, and means that VTT is not at an automatic disadvantage if it doesn’t have a Rec.

A Rec. is also forcing us to confront the fact that we need a good test suite, interoperable implementations, and the ability to convert from other formats (notably TTML).  We shouldn’t need a Rec. to make us do that, of course, but it does help us focus on which precise version we’re trying to do that around.

I think the use of multiple publication vehicles has the potential to improve online media accessibility, while discussion of multiple vehicles is a distraction and does nothing for accessibility. I’d rather we focused on making the spec. the best it can be, on test suites, quality interoperable implementations, and so on, than on discussing the insides of our teacups. 

Anyway, the question was “should we use the old or new Rec. process?” not re-opening the whole Rec-track discussion. Please can we stay focused on the question?


On Sep 4, 2014, at 15:41 , Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 4 Sep 2014, Loretta Guarino Reid wrote:
>> 
>> I would really like a fixed-point version of the spec.
> 
> There's at least 166 fixed-point versions of the spec. For example, here's 
> version 1.23 (25 April 2012):
> 
>   http://dev.w3.org/cvsweb/~checkout~/html5/webvtt/Overview.html?rev=1.23;content-type=text%2Fhtml
> 
> Here's version 1.166 (2 September 2014):
> 
>   http://dev.w3.org/cvsweb/~checkout~/html5/webvtt/Overview.html?rev=1.166;content-type=text%2Fhtml
> 
> There's also patent-licensed-covered version from February:
> 
>   http://dev.w3.org/html5/webvtt/e0a5a82bd5be3501e7649a949fcce4c7b83a427c.html
> 
> 
>> It is fine for the spec to continue to evolve, but the range of 
>> implementations of WebVTT in different browsers has me pulling my hair 
>> out
> 
> The spec evolving actually helps that problem, it doesn't hurt it. If the 
> spec didn't change, it would mean that the browsers would have no guidance 
> on how to converge when the spec is known to be wrong.
> 
> 
>> and it is hard to file bugs against behavior that doesn't match the spec 
>> as the spec continues to move.
> 
> This would not be solved by having a snapshot of the spec. You could tell 
> people today to implement version 1.166 of the spec. The problem is that 
> when a bug is found in that version, the implementors aren't going to want 
> to implement it. They'll want to implement the fixed version, 1.167.
> 
> 
>> I think issuing a REC version of WebVTT is the easiest way to define a 
>> fixed version.
> 
> That's definitely not the easiest way; the easiest way is the way we've 
> already done it: just archive every version ever made.
> 
> 
> I _think_ what you're _actually_ asking for is "stop making changes to the 
> spec". That is something we should definitely do -- once something has 
> shipped, the spec should match that and that part of hte spec should never 
> change again. If the spec is changing in ways that make deployed 
> interoperable implementations non-compliant, then that's a big issue.
> 
> But a REC wouldn't stop that, since even having a REC wouldn't stop the 
> spec from continuing to evolve, just like having version 1.23 didn't stop 
> the spec from continuing to evolve. Fundamentally, we always need 
> somewhere to fix bugs that are found, and somewhere to put new features 
> that people ask for and that browsers want to implement.
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Thursday, 4 September 2014 23:06:18 UTC