Re[2]: More comments on updated timed-text document

On Tue, 19 Mar 2002, Erik Hodge wrote:
> I want to re-emphasize the requirement that whatever TT is, it
> should not be confined to being download-before-playback data.
> TT files will be placed on Web servers and their contents easily
> indexed and searchable, but they may also end up residing in
> more-secure locations and their contents delivered to clients in
> a just-in-time fashion, i.e., "streamed".  In the latter case,
> their contents would not show up in search engines.  In either
> case, the delivery mechanism would not affect the end user's
> ability to select and copy the presented text.

I'd like to add to what Erik says here.  I think a requirement should be
that the group comes up with a streaming model for the text.  That doesn't
necessarily mean that this group is responsible for the actual RTP
packetization, though that would be a very useful exercise.  Rather, this
group needs to think about how this format works in absense of a complete
document.

This means several things:
* Server load:  servers are often responsible for serving to thousands of
  clients.  Therefore, CPU load of an individual TT instance must be
  small. The server cannot be expected to parse an entire document before
  sending.
* Client access to the document - the client may only have access to a
  small window of the document, and furthermore, if this group doesn't
  define the packetization, then the client may be limited by the
  packetization format chosen.
  *  DOM access may be impossible if the information to reconstruct the
     DOM is not transmitted on the wire.
  *  Random access to the DOM may be limited by the client's access to the
     limited window of data
* Speaking of the DOM:  is the format going embody a method of changing
  the DOM over time (with "streaming DOM" commands to the client), or have
  a static DOM for which a sandwich model exists (ala SMIL Animation).

I would strongly suggest that this group either defines the packet format
or coordinate closely with a group that will define a packet format (for
example, in the IETF).  Otherwise, I doubt that this group's format will
be compelling enough to motivate vendor interest.

Example of a packetization format:
http://www.ietf.org/internet-drafts/draft-westerlund-avt-rtp-static-media-01.txt

Rob


> At 16:20 03/19/2002 +0100, Chris Lilley wrote:
> >EH> With TT, we may want to enable the author to describe in the TT file
> >EH> whether or not the user agent should allow selection+copying of the
> >EH> presented text at any point in the presentation.
> >
> >
> >Ah, ok, the 'pulling the wool over the eyes' school of copy
> >protection. It suffices for impressing clients, but offers no actual
> >security at all in practice.
> >
> >There were calls for that sort of thing in SVG, but we declined
> >because it gives the appearance of solving a problem without actually
> >doing anything.
> >
> >In addition, it compromises accessibility to not be able to select text.
> >
> >Would the text be barred from being indexed, too? Would it not show up
> >in search engines?
> >
> >--
> >  Chris                            mailto:chris@w3.org
>
>

Received on Tuesday, 19 March 2002 15:01:16 UTC