- From: David Singer <singer@apple.com>
- Date: Mon, 23 Apr 2012 17:59:19 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Glenn Maynard <glenn@zewt.org>, public-texttracks@w3.org
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.
>> 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).
>> or (c) consists of the
>> termination sequence (a single period) must be escaped by having a "\"
>> pre-pended. On receipt, gather the lines up to the final terminator (".")
>> and remove all leading "\" characters.
>
> We haven't introduced an escape character at this stage.
That's what I am doing!
> The only
> place where we'd need one is if we really needed a multi-line value
> with a "." on a single line. Is this case sufficiently likely to have
> to deal with it? Is there a way around it with a UTF-8 char?
no. why worry? this completes it.
>
>
>> 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).
David Singer
Multimedia and Software Standards, Apple Inc.
Received on Tuesday, 24 April 2012 00:59:49 UTC