RE: Workshop feedback sought

Philipp,

Do we yet have any idea whether or how this effort in W3C will move forward?

Regards,
Jeff

Broadcast Architecture
Intel Architecture Labs
Intel, Corp.
jeffrey.huckins@intel.com
503.264.9488

On Thursday, July 09, 1998 6:52 AM, tommi.riikonen@mnt.nokia.com
[SMTP:tommi.riikonen@mnt.nokia.com] wrote:
> 
> 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 11:40:50 UTC