Re: Metadata in the VTT file header (bug 15851), use cases (and a need to close this)

On Thu, 30 Aug 2012, David Singer wrote:
> On Aug 30, 2012, at 10:22 , Ian Hickson <ian@hixie.ch> wrote:
> >>> 
> >>> As in:
> >>> 
> >>>  WEBVTT
> >>> 
> >>>  00:11.000 --> 00:13.000
> >>>  <v Roger Bingham>We are in New York City
> >>> 
> >>>  OFFSET -01:00.000
> >>> 
> >>>  01:13.000 --> 01:16.000
> >>>  <v Roger Bingham>We're actually at the Lucern Hotel, just down the 
> >>> 
> >>> ...or some such.
> >> 
> >> I can't see how you could do that in a backwards-compatible fashion.  
> > 
> > I don't understand. Backwards-compatible with what?
> 
> Existing parsers will try to parse that OFFSET line as a cue, and 
> fail/complain.  That's a compatibility failure.

This is incorrect. If they follow the spec, they will ignore that line.

I would be far more concerned that existing parsers will treat the file as 
having completely the wrong timestamps. That seems to make the feature 
completely incompatible with any existing UAs. But that's true regardless 
of where the offset is placed -- at the top of the file in the currently- 
ignored header, in a currently-ignored block anywhere in the file, in the 
<track> element, in the media stream container, etc.


> >> I disagree that special casing every new piece of data (inline 
> >> styles, URLs to external stylesheets, language tags, "kind" tags) is 
> >> less complex than defining the format once so parsers don't have to 
> >> keep changing.
> > 
> > The complex part of adding CSS to WebVTT implementations is not the 
> > syntax for adding a new block to the WebVTT parser. That part is 
> > trivial.
> 
> Not if you don't want to break existing implementations, or invalidate 
> existing files.

It would not break existing implementations.

It would not invalidate existing files.


> Setting a stage where we can see where and how we can add features in a 
> backwards-compatible way is something you, and the rest of us, do quite 
> often, in many places.  Having general parsing rules is quite common in 
> many standards, including ones you have written.

Yes. We have those. That's entirely different than providing a syntax for 
use for arbitrary purposes.


> > The solution is not to try to come up with an uber-meta-language that 
> > solves all possible future problems (except all the ones we didn't 
> > think of -- e.g. XML totally fails at non-tree data structures). The 
> > solution is to just not change the language very often.
> 
> No-one is trying to come up with an uber-meta-metalanguage, just a way 
> to parse the VTT header.

We can disagree as to the size of the proposal, but it's still a 
metalanguage that is being proposed.


> > It's not a standard. Doesn't have to be. It's vendor-proprietary data 
> > that differs from vendor to vendor.
> 
> We have an interop question here, not an internal vendor question.

Please file bugs with these interop use cases and concrete examples.


> >> It is indeed conceivable that many proprietary name-value tags will 
> >> be created in addition to the small set that we have suggested for 
> >> kind, language, label, in-band style sheet, and external style sheet. 
> >> And indeed the CEA608 document that I've proposed already shows some 
> >> that are typically used by caption providers.
> > 
> > This is the disaster that IMHO we must avert.
> 
> Preferably by defining the syntax, and then the names, which is what the 
> rest of us are trying to do.

If the discussion were about defining names, then that would be fine. 
You'll notice I have no objection to addressing specific use cases like 
the language thing, the style thing, the offset thing.

My objection is to defining syntax _without_ names.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 30 August 2012 19:14:48 UTC