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 Sunday, 25 October 1998 15:33:24 UTC