RE: Workshop feedback sought

From: Riikonen Tommi NRC/Tre (
Date: Thu, Jul 09 1998

From: (Riikonen Tommi NRC/Tre)
To: (EXT Phoschka), (www-tv)
Message-ID: <>
Date: Thu, 09 Jul 1998 15:51:53 +0200
Subject: RE: Workshop feedback sought

Hi Philipp and all others,

Thanks for organizing the workshop on very important issues. It is really 
important to get standards  for accessing the TV-related  services from HTML 
and some kind of profile for broadcast HTML. W3C's active role in 
participating these issues is definetly needed to get things going on and 

Answers and comments:

> From: EXT Phoschka
> To: www-tv
> Subject: Workshop feedback sought
> Date: 6. Julyta 1998 9:53
> Technical review
> ----------------
> The following topics had high priority:
> 1. New URL-scheme for TV channels [high]
>     (new URL for content in TV services)
>      broadcast-specific data on the Web (SI/PSI-like metadata:
>       schedule, etc.)
> 6. interaction mechanisms for streaming media, linking [10]
> 7. controlling streaming media [6]

URL-scheme for pointing to broadcast services is needed. So, not only a
pointing mechanism to TV channels but a wider concept is needed.
Dan's television URL is targeted only for changing the TV channel from HTML
and as such it might be hard to expand for more common use.

It is not W3C's task to define the URL-scheme's name, but we can can give
valuable input what should the structure look like and what attributes or
parameters are needed. One starting point is to take the DAVIC's DVB URL
specification as a base and then extend it to fullfill our needs. (I am 
now about digital TV/broadcast services, but maybe a mechanism to tune or
switch to analog TV channels is needed too)

The following content types are accessible via the DVB URL:
• Audiovisual broadcast services in DVB Transport Streams
• Files in DVB Data Carousels
• File objects in DVB Object Carousels
• Stream objects in DVB Object Carousels

Part 9 of the DAVIC 1.3 specification ( 
defines the DVB URL syntax as follows:


The <original_network_id>, <transport_stream_id>, <service_id>, <event_id> 
and <component_tag> are the values represented as hexadecimal strings 
without any "0x" prefix (for example, "4d2e").

Depending on the service the following part of the URL ("/<...>") may 
contain a more detailed specifier that identifies the desired part of the 
service. For example, if the service contains a data carousel, the last part 
of the URL may contain the file name.

Any DVB service containing audio and/or video components can be accessed via 
the DVB URL. The service is uniquely identified by the DVB SI parameters 
original_network_id, transport_stream_id and service_id. A data component in 
a DVB service can also be accessed, provided that the data component is 
either a Data Carousel or an Object Carousel.


Pointing from web HTML content  to broadcast stream is also a needed 
In the broadcasted SI/PSI data there is no possibility to transmit very 
large and
content rich (e.g. lots of images, texts video clips) data. That is where 
web content - broadcast or not - comes valuable. And a very important 
is to point to the actual TV program from this HTML content to get watching 
TV program. Think for example DirecTV's online EPG at It would be nice to get to
tuned to the channel just by pressing the corresponding HTML link.


Controlling streaming media. Yep, we absolutely need a common standard set
of functions to control the the streaming media. One approach is the way I 
in the workshop, but the most important is to get agreed of a standardized, 
or in case
of W3C a recommended way of controlling the media.

> 2. Broadcast HTML (tv-related profile of CSS, HTML, etc.) [high]
> 4. Default style sheet for TV [high]

Needed, because TVs are not as capable as PC to represent different
complicated HTML content. And this way by having broadcast HTML
compatible content we can be quite sure that it looks also good on TV. This
is a good task for W3C to define the HTML profile, or do we need separate

TV style sheet sounds a good idea if current CSS implementation allows to
do all kind of modifications that might bee needed to fit the HTML nicely to
TV screen. One problem is the resource & performance requirements that
CSS support sets. Often the CPU and memory resources are very limited in
the set-top box environment.

> 3. Authoring guidelines [high]
> 8. filtering/transforming data for specific devices
>     device profiles [6]
>      (re-processing color palettes, guidelines for ~,...)

Nice to have one, but not W3C's task. We would be very delighted if for 
HTML Writer's Guild could generate these guidelines. We can give input to 
kind of work anyway from our own experience.

Filtering and transforming sounds very device specific things and are 
hard to define in the standardized way.

> 5. Metadata description/transport [10]

Good idea, but maybe not currently the most important. Aren't there already
other groups thinking these issues in other concepts... Maybe we can gain 
from their outputs.

> 9. accurate layout control[5]

Good and bad. Of course it would be nice to define precisely where the 
appear, but in the same way we loose HTML's "proportionality". How for 
changing the font size affects to the content... However layout control in 
some level
is needed.

> Questions
> ---------

Do we continue to use the wwwtv e-mail list for all things and technical 
or should we create separate groups for discussing different things?

>From the discussions we can later probably form an interest group or a 
group to get these issues further.

> Organisational review
> --------------------
> - Did the workshop fullfill your expectations ?
> - What did you get out of it ?
> - What should be done differently next time ?

Yes, it was good get people under the same roof to think these issues and 
their own ideas. Hopefully some real actions are the final results. The 
was also a good place to create synergy between different parties.

Tommi Riikonen & Kimmo Djupsjöbacka
Nokia Multimedia Network Terminals