AW: Conceptual requirements

Rob:
Well, I am interested in technolgies that are inter.
Digitally interactive.
I'll keep track
Henning
-----Ursprüngliche Nachricht-----
Von:	Rob Glidden [SMTP:robg@quadramix.com]
Gesendet am:	Donnerstag, 29. Oktober 1998 01:32
An:	Henning Timcke; Simon Gibbs
Cc:	www-tv@w3.org; Philipp Hoschka; Rodger Lea; djz@corp.webtv.net
Betreff:	Re: Conceptual requirements

Henning wrote:

>This does not mean the the viewer must be logged on to the Internet, but
this means the viewer has to >be logged on to something that allows him to
interact, to send back a mouse click or something similar, >to buy. I'd like
to know what you have in mind and how this would differ from I-Net
architecture.

No, a "backchannel" back to a server or the internet is not required for
"Broadcast Web" content to be "consumed" (i.e. viewed and interacted with).

This is the first conceptual leap of "Web on TV" -- the viewer may not
necessarily be connected to the Internet!

Watching television cannot be required to be "hooked up to the Internet" at
all times -- it won't fly technically (at least not for a time frame
relevant to business planning) and not from a business model.

Of course, in the "buy-me button" example -- there may be many reasons to
get the viewer to log back to the backchannel -- but maybe it is just an ad
for a special at the local grocery store -- with no need to log back for it
to be comercially meaninful.

This is why they call it broadcasting.

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: Wednesday, October 28, 1998 11:47 AM
Subject: AW: Conceptual requirements


Rob:
>[>]  Connection must not be on the same wire, but any kind of two way
connection must be established for a relevant time intervall.


To be clear, I hope we are talking about the same thing.  I am talking about
the scenario where the viewer is watching digital television, and the buy me
button is embedded in the broadcast stream (as HTML+media data?) -- the
viewer would not have to log onto the Internet (or do anything else) for the
buy-me button to appear on the screen, be selected and display further
information.
>From my point of view this is not a qustion of digital tv or analog tv.
What I am thinking about is scenario where there is - in any way - a end to
end and back topology implemented. This does not mean the the viewer must be
logged on to the Internet, but this means the viewer has to be logged on to
something that allows him to interact, to send back a mouse click or
something similar, to buy. I'd like to know what you have in mind and how
this would differ from I-Net architecture.
Henning

-----Ursprüngliche Nachricht-----
Von: Rob Glidden [SMTP:robg@quadramix.com]
Gesendet am: Montag, 26. Oktober 1998 22:34
An: Henning Timcke; Simon Gibbs
Cc: www-tv@w3.org; Philipp Hoschka; Rodger Lea; djz@corp.webtv.net
Betreff: 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 11:50 AM
Subject: AW: Conceptual requirements

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


To parse what?  XML fragments in the stream?


>Is there coke.commercial.html somewhere?
>[>]  yes


Where?  Embedded in the broadcast stream?

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


To be clear, I hope we are talking about the same thing.  I am talking about
the scenario where the viewer is watching digital television, and the buy me
button is embedded in the broadcast stream (as HTML+media data?) -- the
viewer would not have to log onto the Internet (or do anything else) for the
buy-me button to appear on the screen, be selected and display further
information.

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


Does it say -- Alert! new session to be launched?  Or alert -- new web page
for this channel?

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

But broadcast advertising business models seem to dictate that the button
should only stay on the screen during the commercial, not during the next
commercial.

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


Definitely not one universal buy-me button.

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

But there is no host-- only a broadcast stream.

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


Wouldn't the button have to be rebroadcast several times during the
commercial?  If the viewer is not watching at the beginning, then it could
not be put in the cache.

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


Why?  Why not bounce all over the screen, if that's what the advertiser
wants to do?
Why does the button have to be an imagemap?  Can't be a div tag or 3D
object?

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


How does the button tell the client where to put itself on the screen?  The
client couldn't know this in advance, or hardwire the location in a
standard.


>>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 Friday, 30 October 1998 12:28:34 UTC