AW: Conceptual requirements

From: Henning Timcke (
Date: Mon, Oct 26 1998

Message-ID: <>
From: Henning Timcke <>
To: "'Rob Glidden'" <>, Simon Gibbs <>
Cc: "" <>, Philipp Hoschka <>, Rodger Lea <>, "" <>
Date: Mon, 26 Oct 1998 18:47:28 +0100
Subject: AW: Conceptual requirements

Great idea to seek focus with basic application scenarios

Here a basic solution (without superimpose)

For example, the "buy-me button" scenario:

A Coke commercial comes on.
During the commercial, a "buy-me button" appears on-screen.
If the viewer selects it, further information appears about a local sale on
When the commercial is over, the button disappears.


How does the client know to launch the buy-me button?
[>]  The coke commercial has a PI to request the by-me button from 
What is put in the cache, and how is it queried?
[>]  The buy me coke button is put in the cache or retrieved from cache 
How does the clent know to remove the buy-me button?
[>]  From the Synchronization part of the buy-me button
What if the viewer tunes in halfway through the commercial?
[>] Synchronization must  allow to multiple request within an intervall
What if the viewer wants to save the local store address?
[>]  The commercial must also send a "save address" button

As you can see it's a matter of deciding at what exact time on a timeline what happens. So that something can happen in the right time: the commercial as well has to be made in a matter that allows interaction with the user.

With superimpose all that is needed is a transparent imagemap.

The client or viewer must be able to act like the early mosaic-browser.
Cache can be within RAM (Basic Viewer) or on a PCMCIA like device (Personalized Viewer).
I'd like to have my personal cache with me.



Open-standard end-to-end solution
Robust, stable, and deployable architecture


-----Original Message-----
From: Henning Timcke <>
To: 'Rob Glidden' <>; Simon Gibbs
Cc: <>; Philipp Hoschka
<>; Rodger Lea <>;
'' <>
Date: Sunday, October 25, 1998 12:38 PM
Subject: Conceptual requirements

>I propose to use XML Processing instructions (PIs).
>All the cached data should report their statuses to an application.
>This application checks the caches and computes their relevance
>(distance to time, accuracy of information, time to live downloaded).
>Another application should mark the cached data with approriate
>What has to be worked out is the relevance of the delivery time.
>How many caches have to be established by reasons of topology (bandwith
>I think it is of importance to get some things on the same level of
abstraction and to sort them out:
>1. How TV is made
>2. How TV is broadcasted
>In the far future there will be no difference, but in the near future there
will be many differences. For the present: we have to know on what level of
differentiation the fileformats are. Is there a collection of all
fileformats in use somewhere, beyond
>From a very conceptual point of view TV is only a Webpage (HTML or SMIL)
with full screen resolution and zero net congestion.
>For example an HTML Page with animated Gif's and with an embedded Realvideo
or an MPEG Stream can look the same as an HTML Page with an MPEG 7 Stream.
And an HTML Page with an Full Screen RealVideo can be just an MPEG Stream of
Content made as a SMIL.
>A workaround might be to superimpose the signal of normal TV with the
signal of a webbroswer.
>Simon wrote:
>>Here are some of the things that I would like
>>to see supported:
>>A URL/URI/URN that allows a browser to locate and access
>>content obtainable from the following devices:
>>- consumer AV equipment (CD, MD, DV, DVD etc)
>>- DTV receivers and set-top boxes
>>I'm also assuming that there is a network connection
>>of some form between the browser and the device in question.
>>This connection can carry both control information and content.
>>From my point of view all the contents can be addressed as URLs, all the
data has a fileformat and a filename. Live streams can be addressed with a
mechanism analog to the Real System, were a live stream has already an URL.
>And, of course it is true, when Dan Zigmond writes:
>World-Wide Web browsers are starting to appear on a variety of
>consumer electronic devices, such as television sets and television
>set-top boxes, which are capable of receiving television programming
>from either terrestrial broadcast, satellite broadcast, or cable. On
>these devices, some of the URL schemes described in [1] are
>inappropriate. For example, many of these devices lack local storage,
>so the "file" scheme is of little use.
>But, my TV (Monitor) and my VHS Recorder are not the same, conceptually,
except they are both local devices.
>My TV cannot use the file scheme (no storage device!) but my VHS Recorder
can (storage device!).
>Inapproriate is to locate content that has no filename and no fileformat.
>What my questions are:
>What, if we had a topology that allows to manage all existend content into
URL conformance (e.g Regional Real Server Stations (TV within a cablenetwork
works even without IP (VOD), we build such an environement (with DNS and IP)
for Orbit'98 on MPEG and RS G2 and an additional MPEG hardware decoder) )
>What happens to the content broadcasted ?
>Shall the content be storable on the client side at all ?
>If any broadcasted content was in the proposed scheme of tv:<broadacst>
>what fileformat will be used ?
>Still I believe: if the content has a fileformat and a filename we need
nothing else to build on than XML and UR*.
>-----Ursprüngliche Nachricht-----
>Von: Rob Glidden []
>Gesendet am: Mittwoch, 21. Oktober 1998 21:33
>An: Henning Timcke; Simon Gibbs
>Cc:; Philipp Hoschka; Rodger Lea
>Betreff: Re: AW: work on url for television started
>-----Original Message-----
>From: Henning Timcke <>
>To: 'Rob Glidden' <>; Simon Gibbs
>Cc: <>; Philipp Hoschka
><>; Rodger Lea <>
>Date: Wednesday, October 21, 1998 11:12 AM
>Subject: AW: AW: work on url for television started
>>I will try
>>Where do I find information about data carousels ?
>Conceptually -- data carousels are "constantly refreshed client-side caches
>of broadcast data objects".  Think of tuning in to a TV channel -- if it is
>a web page -- how often does the web page have to be rebroadcast so you can
>see it when you tune into it?  Does all of the page have to be rebroadcast
>every second?  how about just the top level page more often, with images
>refreshed every few seconds (for example..)
>For background
>ATSC Specialist Group T3/S16 for Interactive Service Protocols:
>A faq on DSM-CC is at
>An Introduction to Digital Storage Media - Command and Control (DSM-CC)
>>-----Ursprüngliche Nachricht-----
>>Von: Rob Glidden []
>>Gesendet am: Mittwoch, 21. Oktober 1998 19:25
>>An: Henning Timcke; Simon Gibbs
>>Cc:; Philipp Hoschka; Rodger Lea
>>Betreff: Re: AW: work on url for television started
>>Yes, I think assistance would be helpful. Could you elaborate a little on
>>how XML could meet these kinds of requirements?
>>1) "referencing cache data"  -- in transient caches and data carousels
>>2) "querying caches"  -- to determine what is currently in them and
>>3) "supporting session management"  -- i.e. identifying, launching,
>>subscribing, terminating multiple streaming sessions.
>>I think a key challenge if finding the right level of abstraction -- some
>>people think of all this a high-level, authoring issue, some think of it
>>low level exposing of the syntax of things like MPEG transport streams.