Re: about tv:

At 09:52 AM 2/11/99 +0100, Warner ten Kate wrote:
>
>> However it is a good URN.
>
>It isn't in my association of "good":
>a URN is supposed to be a persistent resource identifier. 
>"current TV channel" is rather context dependent, so not persistent.

On the assumption that a URN can resolve to more than one URL, one could
argue that the URN, tv:, conceptually resolves to all channels being
broadcast everywhere in the universe.  A lengthy, but persistent list (or
more persistent than dvb: transport ID's, so be careful).  The receiver
then chooses which of the channels this has relevance to it, which
eventually resolves to the "current channel" on the "selected receiver".
Very context dependent - but definable.

>> 2. There isn't a scheme proposed yet (that I have seen) that addresses the
>> multiple tuner issue.
>
>At least the dvb: scheme addresses that issue, namely by abstracting
>from that. The scheme identifies a resource, that's independent
>of the number of tuners your device contains.

Independent, yes, but how does the dvb: URL help handle multiple tuners -
either both tuners on the same network, or connected to different networks?
 I have nothing against dvb:.  Just that it is probably not a good argument
in contrast to tv:.  It has the same multiple tuner problems all the rest do.

>You assume there is other information available containing 
>the "currently tuned to" (that information has probably 
>caused the tuning). 

Yes, of course.  It is *very* context dependent.

>I don't have the proper solution, but I think we should 
>look whether relative URLs are of use here. Something 
>along the lines that the base-URL sets the context: the 
>currently tuned TV-channel and its associated HTML pages
>(I mean the pages which are transmitted along with the video). 
>
>The TV-channel is at the root defined by that base URL, so 
>a reference like src="tv" could do, without colon suffix.
>The colon will conflict with the relative URL parsing rules. 
>"tv" is the 'file' name of the video stream located at the 
>root - probably names like src="video" and src="lang-en" 
>are more useful. I am not sure whether we can specify 
>default names here (with default semantics).

I've given some thought to relative URLs.  The problem is that there can be
only one BASE in any context.  The BASE of an HTML page (that might contain
a need for tv:-like functionality) will necessarily be something other than
the tuner one needs to reference.  It will have to be content-related,
possibly even as far back as the authoring station, but minimally unrelated
to tuning a channel.

You assume that the URL scheme for all HTML pages must be
transport-dependent, which I maintain is bad in the grand object naming
scheme of things.  The URI scheme(s) must be transport-independent and
usable by authors unrelated to where the content ends up.  Therefore, the
BASE will almost never be related to tuning, and thus relative URI's cannot
really be used.  {Sure wish they could, though.]

>Having just src="tv:" in a HTML page provides the author
>any guarantee the tv stream is displayed he had in mind.
>It is a scheme which works fine within a constrained
>environment like a single analog TV channel with 
>VBI data transmission. There are not much alternatives there.

I disagree that it is quite this limited.  The context can be determined
without having a BASE URI.  For example, on any transport, the context can
easily be the channel on which the page that has the reference arrived at
the receiver.

	Mike

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

Received on Thursday, 11 February 1999 09:47:17 UTC