W3C home > Mailing lists > Public > public-tt@w3.org > January 2003

RE: TT Content Buffering and Timing Scenarios

From: Erik Hodge <ehodge@real.com>
Date: Thu, 30 Jan 2003 15:25:31 -0800
Message-Id: <5.1.0.14.2.20030130151432.03222440@mail.real.com>
To: "Glenn A. Adams" <glenn@xfsi.com>
Cc: "W3C TT Public" <public-tt@w3.org>

Sounds good.  This solves the problem of communicating most of, if not
all of, the state of each packet's text attributes to the client side
in case one or more prior packets are lost or are seeked past.  This
approach would thus greatly simplify designing the wire format for
live TT.

         - Erik

At 04:52 PM 1/30/2003 -0500, Glenn A. Adams wrote:

>See inline.
>
> > -----Original Message-----
> > From: Erik Hodge [mailto:ehodge@real.com]
> > Sent: Thursday, January 30, 2003 3:42 PM
> > To: Glenn A. Adams
> > Cc: W3C TT Public
> > Subject: RE: TT Content Buffering and Timing Scenarios
>
> > Let's say the live stream is coming from a computer on which someone
> > is typing some speaker's words and transmitting each sentence as soon
> > as it is typed.
> > (1) At time zero they type, "<moderator><strong>Good evening.
> > Welcome to the Food Show."  This then gets sent (streamed) at 6s.
> > (2) At 6 seconds they type, "Tonight we will be discussing which
> > wines go best with different snack foods." This gets sent at 14s.
> > (3) At 14 seconds they type, "With me today are Phillip McGlass,
> > editor of Wine About Magazine, and Don Nutt, editor of Junk Food
> > Magazine</moderator>", which gets sent at 23 seconds.
> > ...etc.
>
>This may be what the user types, but it would have to be expanded
>by the system prior to transmission into something like:
>
><tt:access-unit start="6s">
><tt:moderator>
><tt:strong>
>Good evening.
>Welcome to the Food Show.
></tt:strong>
></tt:moderator>
></tt:access-unit>
>
><tt:access-unit start="14s">
><tt:moderator>
><tt:strong>
>Tonight we will be discussing which
>wines go best with different snack foods.
></tt:strong>
></tt:moderator>
></tt:access-unit>
>
><tt:access-unit start="23s">
><tt:moderator>
><tt:strong>
>With me today are Phillip McGlass,
>editor of Wine About Magazine, and Don Nutt, editor of Junk Food
>Magazine
></tt:strong>
></tt:moderator>
></tt:access-unit>
>
>If the authoring station is going to allow direct user
>entry of semantic/style markup, and there is an expectation
>that that markup would be preserved, and, further, the
>authoring station allows for short cuts such as automatic
>closing of elements, then there clearly would need to
>be some underlying, post-processing to make it well
>formed and valid.
>
>See XML 1.0 (2nd Ed.), Section 4.3.2 [1], partially
>quoted here:
>
>"The document entity is well-formed if it matches the production
>labeled document. An external general parsed entity is well-formed if
>it matches the production labeled extParsedEnt. All external
>parameter entities are well-formed by definition.
>
>
>Well-Formed External Parsed Entity
>[78]    extParsedEnt    ::=    TextDecl? content
>
>...
>
>A consequence of well-formedness in entities is that the logical and
>physical structures in an XML document are properly nested; no
>start-tag, end-tag, empty-element tag, element, comment, processing
>instruction, character reference, or entity reference can begin in
>one entity and end in another."
>
>So, no matter whether each access unit is an entire XML document or
>is a top-level element of a streamed external entity, the access unit
>must satisfy production [43] of XML.
>
>Regards,
>Glenn
>
>[1] http://www.w3.org/TR/REC-xml#wf-entities
Received on Thursday, 30 January 2003 19:32:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 November 2009 22:41:25 GMT