AW: Conceptual requirements

Good questions
I'll think about them during the week, here some spontaneous ideas.


>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?  
[>]  The client must have minimal parser functionality
Is there coke.commercial.html somewhere?
[>]  yes

And why http?  
[>]  could be pnm or rpm
The TV may not be connected to the Internet.
[>]  This is the point: connected or not.
No connection to an end -to-end net: no interaction
[>]  Connection must not be on the same wire, but any kind of two way connection must be established for a relevant time intervall. 
 
>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?
[>]  The parser tells to the client
>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?
[>]  Of course
Can't they be automatically killed if you change channels or another
commercial comes on?
[>]  Do you think of an one-buy-me-button-fits-all ?
I think any commercial will have it's own buttons.
>What if the viewer tunes in halfway through the commercial?
>[>] Synchronization must  allow to multiple request within an intervall


Could you elaborate?   [>]  I would like to work on this (where time comes in and how to change from absolute time layers to , maybe on saturday I will find some time to type out what's in my mind.  Multiple requests to where ? [>]  From the host through the parser to the client. Similar to the Content refresh mechanism in the meta tag. During a given period (the time intervall defining the total appereance of the what-ever-now-button) the button has constantly to be on the screen, if not it must be rerequest: when your zapping you must get the information: Hey, some few seconds ago, there appeared a button right here, get it now, it has to disappear in 4 seconds from now on)


>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?
[>] It has to bounce within the polygon area of the imagemaps hotspot 
How will the client know where on the screen to put the button?
[>]  This has to be coordinated during the design phase of the commercial.
The client just has to know the coordinates of event areas and what to do we this areas are selected for action.
>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:44:31 UTC