RE: one more requirement

From: Dan Zigmond (
Date: Wed, Jan 06 1999

Message-ID: <15AAE0EBDCC9D1119FFA00805F85642E012CA30F@WNI-MSG-02>
From: Dan Zigmond <>
To: "'Gomer Thomas'" <>, WWW TV List <>
Date: Wed, 6 Jan 1999 12:44:40 -0800 
Subject: RE: one more requirement

At the risk of degenerating into a purely philosophical debate, I'm not sure
I agree that the "tv:" URL doesn't describe an "image."  The television
broadcast is an image of sorts, and certain behaves like an image in terms
of page layout.  (In other words, you can put it anywhere on an HTML page
where you can put an image, and image attributes around position and size
make perfect sense for television broadcasts.)  One of the big advantages of
using a URI for TV broadcasts was that it can then integrate so well with
the rest of HTML.  For example, the OBJECT tag provides a nice way of
authoring content that can either include a TV broadcast or not, depending
on the client:

<OBJECT src="tv:">

<OBJECT src="">



It also provides a natural URI for "pure TV"; when you want to get rid of
all enhanced content and go back a full-screen television image, you simply
go to the "page" described by "tv:" itself.
At the very least, a television broadcast seems just like any other video. 
So a <TV> tag makes sense only if you also imagine a <VIDEO> tag.  If you
believe ordinary video clips should be embedded in HTML using the OBJECT tag
with URIs pointing to the source of the video, then using this technique for
television as well seems to make sense.

Dan Zigmond 
Senior Manager, Interactive Television Technology 
WebTV Networks, Inc. 


-----Original Message-----
From: Gomer Thomas []
Sent: Wednesday, January 06, 1999 12:22 PM
To: WWW TV List
Subject: Re: one more requirement

Mike - 

To add these to the application scenario list we need enough detail to
understand the application scenarios. How are these URIs used? Where do they
come from? How is the application supposed to treat them? 

My understanding is that they typically appear in HTML pages. I think one
example given in the WebTV internet draft is <img src=tv:>. Presumably the
HTML engine rendering the HTML page is supposed to play the currently tuned
channel in the space defined by the other parameters of the img tag, or use
some default size if no size parameters are specified? Where would the HTML
page typically come from in this scenario? A web site? VBI line 21 of an
NTSC broadcast channel? I.e., what is the context within which a designation
such as "7" or "abc" should be interpreted? 

I do not believe that we need to proserve legacy syntax, but I do believe
that we need to ensure that the application requirements met by that syntax
is met in some way within our framework. 

For example, my own personal view is that the syntax <img src=tv:> is
unfortunate. It says to put in an image space something which is not an
image in the usual sense, and it uses the syntax of a URI for something
which is not identifying anything. If I had been part of the original design
team, I would have recommended syntax more like the following for your three

*	<tv> 

*	<tv chan=7> or possibly <tv src=ntsc://7> 

*	<tv network=abc> or possibly <tv src=ntsc://abc> 

and for the other example sometimes given in this context: 

*	<tv station=wnyc> or possibly <tv src=ntsc:wnyc> (but how to
distinguish network from station?) 

This proposed "tv" tag could of course have other appropriate attributes for
specifying size, volume level, closed captioning, etc., or perhaps
parameters like volume level and closed captioning could be specified by
queries at the end of the URI. 

Michael A. Dolan wrote: 

I think we should add to the application scenario list (or requirements, 
whichever is more appropriate) the existing commercial practice for "tv" 
URI's in existing (NTSC) broadcast systems.  This list may not be complete, 
but the ones I know about are: 

        tv:                    [reference to the currently tuned channel] 
        tv:<channel_number>    tv:7 
        tv:<network_name>      tv:abc 

This syntax obviously presumes a specific transport and is very limited in 
scope, but one could envision a more complex scheme where this syntax falls 
out as valid *relative* URI's. 

In any event, I think this syntax should be addressed and accommodated if 
possible as we move forward with our designs. 


Michael A. Dolan, Representing DIRECTV,  (619)445-9070   FAX: (619)445-6122 
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901

Gomer Thomas 
40 Washington Road 
Princeton Junction, NJ 08550 
phone: 609-716-3513 
fax: 609-716-3503