Re: meta-data in the VTT file header, a strawman proposal

On Fri, Apr 20, 2012 at 11:41 PM, Glenn Maynard <glenn@zewt.org> wrote:
> (I'm not familiar with YAML, but on first glance it looks complex...)

Actually, the wiki page is much more complex than it actually is. It's
almost identical to JSON but without the quotes and curly braces,
instead using white space and indentation (more like python).


> On Fri, Apr 20, 2012 at 12:01 AM, David Singer <singer@apple.com> wrote:
>>
>> On Apr 20, 2012, at 13:09 , Glenn Maynard wrote:
>> > (Still, it's ugly that embedding a stylesheet would end up looking messy
>> > in a plain text editor.  You don't really want to flatten a whole stylesheet
>> > into one line.  We should be able to find an approach with none of the
>> > negatives: clean in plain text, round-trips all text, while remaining
>> > simple…)
>>
>> Yes, I think we want some readability.  And maybe assuming all values
>> could be on one line is bad.
>
>
> (I agree with the first, but the second isn't a problem: any JSON document
> can be stored on one line.)

I believe David wanted to make sure valued don't *have* to be on one
line, which your proposal seemed to suggest?


>> A terminator-and-escape syntax ensures exact recovery of the original
>> input, whereas with 822 one cannot tell the difference between lines that
>> originally started with a blank, and lines that had one added for 822
>> compatibility.
>
>
> If you specify that continuation lines always have *exactly* one U+0020
> space character added (instead of one or more of any whitespace, as in 822),
> then you can tell the difference: you just remove the one space.  That's how
> patch files work.
>
> Key: value
>  value
>   value2
>
> would decode to "value\nvalue\n value".


Incidentally, multi-line in HTTP headers also require white space at the start.


>> ouch. that's fragile; lines that appear to be empty but actually consist
>> of a single white-space. We're laying ourselves open to endless
>> misunderstanding if blank lines 'appear' OK but actually need to have an
>> invisible space character in them.
>
>
> You can avoid this problem by treating lines containing only whitespace as
> if they're empty (which I'm guessing--haven't checked--is probably what
> WebVTT already does for its existing significant-blank-lines, for exactly
> this reason).

I believe David is saying that we actually *want* to be able to use
empty lines in multi-line values, but that they currently cause the
end of the metadata section parsing in WebVTT. Thus, we need a way to
escape this processing.

I am not sure we can, though, without changing the parsing of WebVTT.


> On Fri, Apr 20, 2012 at 2:10 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> wrote:
>>
>> How about the "|" sign as the single value of a metadata field says
>> that from there on the next lines are a multi-line value. Then we can
>> end it with a single line that just has a "." on it (like SMTP bodys)
>> (or again a "|" if you prefer). I think that could work out quite
>> readable.
>>
>> For example:
>>
>> Kind:  captions
>> Initial-Timestamp: 1000
>> Style: |
>> p {
>>  font-size: 100px;
>> }
>> .class {
>>  text-color: red;
>> }
>> .
>> NexField: whatever
>
>
> I haven't spent much time thinking about this yet, but I see two benefits at
> first glance: you can paste in CSS from another file without having to add a
> space to each line, and you don't have to fold the first line onto the
> Header: line (which is a bit ugly).

Yeah, I liked that about it, too.


> I assume that blank lines would still
> be disallowed (so parsers uninterested in headers can skip over them
> trivially)?

Yes, I don't think we can fool the WebVTT parser into ignoring blank lines....

Cheers,
Silvia.

Received on Saturday, 21 April 2012 04:00:03 UTC