- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 28 Sep 2012 12:33:37 +1000
- 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 ".". Silvia.
Received on Friday, 28 September 2012 02:34:24 UTC