W3C home > Mailing lists > Public > public-texttracks@w3.org > September 2012

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 28 Sep 2012 12:33:37 +1000
Message-ID: <CAHp8n2nPGooBxYW6KU4Yp06RwGW0EnFXbrEM9uOTo2AdG5XWwA@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: David Singer <singer@apple.com>, Simon Pieters <simonp@opera.com>, public-texttracks <public-texttracks@w3.org>
On Fri, Sep 28, 2012 at 12:26 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Thu, Sep 27, 2012 at 8:52 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> wrote:
>> Then we have to be careful that a multiline value can't have a
>> "name"-colon inside it, since this implies the start of a new metadata
>> header field.
> Only a period would end a header block.
> Foo:
> a b
> c: d
> .
> Bar:
> e f
> .
> would result in two values, Foo and Bar.  The "c: d" within the block would
> simply be parsed as part of the block.  These aren't complete examples, of
> course.  I'm omitting things like the mechanism to indicate a multiline
> header.

OK, there are two mechanisms we are discussing: one is to end the
header parsing and one to define multi-value metadata fields.

Are you suggesting to use the same mechanism to end both?

> (This does reduce the error-recovery a bit: if you forget to end a header
> block, then the whole file, cues and all, will be interpreted as part of the
> header.  I think that's fine: that's not nearly as subtle a mistake as
> omitting the blank line, since the whole file is consumed as a header, not
> just the first cue.)

To make this less likely, I suggested using "##" as the end marker.
It's more in your face and less easy to forget than a simple ".".

Received on Friday, 28 September 2012 02:34:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:20 UTC