- From: Philip Jägenstedt <philipj@opera.com>
- Date: Tue, 10 Sep 2013 09:42:54 +0200
- To: Glenn Adams <glenn@skynav.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Cyril Concolato <cyril.concolato@telecom-paristech.fr>, public-html <public-html@w3.org>
On Mon, Sep 9, 2013 at 3:50 PM, Glenn Adams <glenn@skynav.com> wrote: > > On Mon, Sep 9, 2013 at 3:27 AM, Philip Jägenstedt <philipj@opera.com> wrote: >> >> On Sun, Sep 8, 2013 at 6:02 AM, Glenn Adams <glenn@skynav.com> wrote: >> > >> > On Sat, Sep 7, 2013 at 5:27 PM, Silvia Pfeiffer >> > <silviapfeiffer1@gmail.com> >> > wrote: >> >> >> >> I don't follow. Can you give an example of a serialized TTML document >> >> entity ? I thought it was XML and not binary? >> >> > (1) it can be encoded in either UTF-8, UTF-16, or any other encoding, >> > and >> > contains its encoding declaration, so this effectively requires binary >> > (octet stream) transparency; >> >> After parsing TTML, all attributes text nodes in the DOM would already >> be decoded to the internal Unicode encoding (probably UTF-16) so >> exposing any of the text from TTML would not require a binary >> representation. > > > The key phrase here is "after parsing" TTML. One can't take an unparsed, > arbitrary encoded XML file and stuff it into WebVTT metadata text without > parsing (as an entity, entailing decoding bytes as characters) and without > escaping LF/CRs. The devil's advocate would suggest just parsing and re-serializing to get any XML content into a .text property. However, I hope that whoever wants to support TTML just adds a TTMLCue without a .text property, instead exposing the cue root node as a .node property directly. Philip
Received on Tuesday, 10 September 2013 07:43:24 UTC