- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 20 Apr 2012 11:51:44 +1000
- To: Glenn Maynard <glenn@zewt.org>
- Cc: David Singer <singer@apple.com>, public-texttracks@w3.org
On Fri, Apr 20, 2012 at 8:54 AM, Glenn Maynard <glenn@zewt.org> wrote:
> On Thu, Apr 19, 2012 at 3:29 AM, David Singer <singer@apple.com> wrote:
>>
>> it makes style-sheets readable, and aren't line-breaks significant in
>> style-sheets?
>>
>> And we don't *want* actual empty lines, as simple parsers will think the
>> cue-text is coming next.
>
>
> I guess it's worth throwing out there: it could use JSON, with the added
> restriction that newlines are not allowed as part of whitespace between
> tokens. For example:
>
> Kind: "captions"
> Initial-Timestamp: 1000
> Style: "p { font-size: 100px; }\n.class { text-color: red; }"
>
> This has a couple advantages: values are typed, complex types can be
> represented (if there's any call for that; there may not be), and it handles
> things like newlines for us without needing to actually store them
> directly. It's easy to parse: each entry is a single line, and everyone
> already has a JSON parser for the rest of the work.
>
> The main disadvantage is that, for multiline blocks, it's cosmetically
> ugly. If you're editing with an editor, then this is no problem, though: it
> would decode the string and display it as multiline.
>
> (I could probably think up a workaround for this to allow newlines even
> though JSON doesn't, but that might negate the benefits, since then you
> couldn't read a whole header simply by reading a single line.)
The difference between JSON and the RFC822 *header* specification is
that JSON requires quotation marks around strings and does not allow
newlines in values.
Thus, IMO, RFC822 headers are actually an improvement over JSON.
Similarly to JSON, everyone has a RFC822 header parser available. All
values are inherently strings, but converted to their proper type by
interpretation of the name.
Silvia.
Received on Friday, 20 April 2012 01:52:33 UTC