Re: about tv:

Michael A. Dolan wrote:
> 
> 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.  

Yes, but being a URN would imply all those channels are delivering 
the same content then. 

As this seems to bring us into a debate what a URN is, 
I cc-ed Larry Masinter: I hope you don't mind, and can 
help us to resolve.


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

I don't think the "list" is the resource to be identified, but the
content broadcast at the current channel as received by the present 
receiver (let's assume there is only one tuner). So the question of 
persistence relates to the content.


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

The dvb: scheme identifies a resource (some content, or a content
stream), it doesn't say (identify) which tuner to be used for that. 
The selection of tuner is left to the receiver: the receiver has 
to take care to return the content identified.


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

Yes, by definition. But one could define multiple contexts (namespaces).


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

Seems to be your assumption I assume that :)


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

IMO, URIs should never be related to tuning (process), but to 
the content (accessible through tuning).


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

Sounds like a BASE.
I was not suggesting the BASE is specified in the HTML document (neither 
that it isn't). For instance, it could be something specified by the
transport system and by that making the (relative) URLs to become
transport
independent. We could further think of a default mechanism specifying
the 
value of the BASE.
As I said in my previous mail, the video of the current channel could be
modeled as a resource "tv" at the root of the hierarchy identified by
that (default) BASE. (Neglecting possible ambiguities in what video is
meant.) The colon suffix would be in conflict with that model.

--

In this conversation we start talking about URN and end with URL.
A namespace qualified by "tv:" encompasses probably another content 
set than content that can be accessed via a "tv:" scheme: 
- content not currently broadcast can still belong to the tv: namespace.
  I.e. there are more items in the URN set.
- content can be broadcast by several channels.
  I.e. there are more locations in the URL set.


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

Warner.

--
Philips Research Labs. WY21 ++ New Media Systems & Applications
Prof. Holstlaan 4 ++ 5656 AA  Eindhoven ++ The Netherlands
Phone: +31 4027 44830
Fax:   +31 4027 44648    tenkate@natlab.research.philips.com

Received on Sunday, 14 February 1999 09:25:33 UTC