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

On Tue, Apr 24, 2012 at 10:59 AM, David Singer <singer@apple.com> wrote:
>
> On Apr 23, 2012, at 17:46 , Silvia Pfeiffer wrote:
>
>>> Yes.  Then all we need to add is
>>> "In multi-line values, a line that either (a) starts with the escape
>>> character
>>
>> There is no escape character. I don't think we need one.
>
> You absolutely need one.  Otherwise neither value lines consisting of "." nor blank lines are possible.

True.


>>> or (b) is blank (safer, visually blank)
>>
>> We can't do blank lines or we break the WEBVTT parsing algorithm. I
>> think we will have to just accept that WebVTT headers can't have blank
>> lines.
>
> No, I am saying that *input* blank lines are escaped so they are no longer blank so the VTT parsing does NOT fail.  Forbidding blank value lines is too restrictive.  I could probably live without "." lines (but even SMTP handles this).

OK. I guess I'm ok with "\" as the escape character.


>>> If we want total flexibility, remove the line-break before the "." line, so
>>> you can end without the line-end character if you want to (you can always
>>> put it back explicitly with an escaped blank line).
>>
>> I think that's not so easy to parse and visually see as just "." on a
>> line by itself. And it's easy to forget it at the end of a line, so
>> I'd rather just have it there on a line by itself.
>
> No, you're missing me.
>
> Glenn's example:
>> Key: |
>>     Value
>> .
>>
>> Key: |
>> |
>> .
>
> These both have a value that has a final line-end character.  So
>
> Key: *
> has a one-character value, and
> Key: |
> |
> .
> has a two-character (|\n) value.  This is fixable; the termination is the string "\n.\n" and it's all removed.  If you want a final \n, put it in specifically (escaped).

Yeah, I think that the BNF that I suggested did that. But then, BNFs
are hard to read, so indeed that was the intention. :-)

Cheers,
Silvia.

Received on Tuesday, 24 April 2012 01:09:27 UTC