Re: Conceptual requirements

-----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: Monday, October 26, 1998 9:57 AM
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
>Coke.
>When the commercial is over, the button disappears.
>
>Questions:
>
>How does the client know to launch the buy-me button?
>[>]  The coke commercial has a PI to request the by-me button from
http://buy.coke.com


How does the client know the coke commercial has an XML Processing
Instruction in the first place?  Is there coke.commercial.html somewhere?

And why http?  The TV may not be connected to the Internet.

>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


But how does the client know it is there, and it should do something with
it?

>How does the clent know to remove the buy-me button?
>[>]  From the Synchronization part of the buy-me button


So buy-me buttons stay up as long as the content creator wants them to?
Can't they be automatically killed if you change channels or another
commercial comes on?

>What if the viewer tunes in halfway through the commercial?
>[>] Synchronization must  allow to multiple request within an intervall


Could you elaborate?  Multiple requests to where?

>What if the viewer wants to save the local store address?
>[>]  The commercial must also send a "save address" button


This seems to make sense to me -- otherwise broadcasters will fill the cache
with junk.

>
>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.


What if the button rotates or bounces?
How will the client know where on the screen to put the button?

>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.
>
>Henning
>
>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 14:13:11 UTC