Re: Conceptual requirements

I think basic application scenarios can bring this into focus.

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
Coke.
When the commercial is over, the button disappears.

Questions:

How does the client know to launch the buy-me button?
What is put in the cache, and how is it queried?
How does the clent know to remove the buy-me button?
What if the viewer tunes in halfway through the commercial?
What if the viewer wants to save the local store address?

Requirements:

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

Rob

-----Original Message-----
From: Henning Timcke <henning.timcke@werft22.com>
To: 'Rob Glidden' <robg@quadramix.com>; Simon Gibbs
<simon@arch.sel.sony.com>
Cc: www-tv@w3.org <www-tv@w3.org>; Philipp Hoschka
<Philipp.Hoschka@sophia.inria.fr>; Rodger Lea <rodger@arch.sel.sony.com>;
'djz@corp.webtv.net' <djz@corp.webtv.net>
Date: Sunday, October 25, 1998 12:38 PM
Subject: Conceptual requirements


>Rob:
>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
information)
>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
needed).
>
>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
http://www.ora.com/centers/gff/specs.htm.
>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*.
>
>
>
>Henning
>
>
>
>-----Ursprüngliche Nachricht-----
>Von: Rob Glidden [SMTP:robg@quadramix.com]
>Gesendet am: Mittwoch, 21. Oktober 1998 21:33
>An: Henning Timcke; Simon Gibbs
>Cc: www-tv@w3.org; Philipp Hoschka; Rodger Lea
>Betreff: Re: AW: work on url for television started
>
>
>-----Original Message-----
>From: Henning Timcke <henning.timcke@werft22.com>
>To: 'Rob Glidden' <robg@quadramix.com>; Simon Gibbs
><simon@arch.sel.sony.com>
>Cc: www-tv@w3.org <www-tv@w3.org>; Philipp Hoschka
><Philipp.Hoschka@sophia.inria.fr>; Rodger Lea <rodger@arch.sel.sony.com>
>Date: Wednesday, October 21, 1998 11:12 AM
>Subject: AW: AW: work on url for television started
>
>
>>Rob:
>>I will try
>>Where do I find information about data carousels ?
>>Henning
>
>
>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:
>
>http://toocan.philabs.research.philips.com/misc/atsc/t3s16/
>
>A faq on DSM-CC is at
>http://drogo.cselt.stet.it/mpeg/faq/faq_dsm-cc.htm
>
>An Introduction to Digital Storage Media - Command and Control (DSM-CC)
>http://drogo.cselt.stet.it/mpeg/documents/dsmcc.htm
>
>Rob
>
>
>>
>>
>>
>>-----Ursprüngliche Nachricht-----
>>Von: Rob Glidden [SMTP:robg@quadramix.com]
>>Gesendet am: Mittwoch, 21. Oktober 1998 19:25
>>An: Henning Timcke; Simon Gibbs
>>Cc: www-tv@w3.org; Philipp Hoschka; Rodger Lea
>>Betreff: Re: AW: work on url for television started
>>
>>Henning:
>>
>>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
>>available
>>
>>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
as
>>low level exposing of the syntax of things like MPEG transport streams.
>>
>>Rob
>>
>
>

Received on Monday, 26 October 1998 12:13:59 UTC