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

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 
talking
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 (http://www.davic.org/DOWN1.htm) 
defines the DVB URL syntax as follows:

dvb://<original_network_id>.<transport_stream_id>[.<service_id>[.<component_  
tag>][;<event_id>]][/<...>]

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 
feature.
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 
traditional
web content - broadcast or not - comes valuable. And a very important 
feature
is to point to the actual TV program from this HTML content to get watching 
the
TV program. Think for example DirecTV's online EPG at 
http://www.directv.com/misc/pgm_guide/guide.html. 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 
presented
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
profiles...

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 
example
HTML Writer's Guild could generate these guidelines. We can give input to 
this
kind of work anyway from our own experience.

Filtering and transforming sounds very device specific things and are 
probably
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 
later
from their outputs.

> 9. accurate layout control[5]

Good and bad. Of course it would be nice to define precisely where the 
objects
appear, but in the same way we loose HTML's "proportionality". How for 
example
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 
questions
or should we create separate groups for discussing different things?

>From the discussions we can later probably form an interest group or a 
working
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 
present
their own ideas. Hopefully some real actions are the final results. The 
workshop
was also a good place to create synergy between different parties.

Sincerely,
Tommi Riikonen & Kimmo Djupsjöbacka
Nokia Multimedia Network Terminals

Received on Thursday, 9 July 1998 08:50:19 UTC