Time [was Re: Where are we?]
From: Michael A. Dolan (miked@tbt.com)
Date: Mon, Oct 11 1999
Message-Id: <3.0.5.32.19991011073530.009f3c10@cts.com>
Date: Mon, 11 Oct 1999 07:35:30 -0700
To: <www-tv@w3c.org>
From: "Michael A. Dolan" <miked@tbt.com>
Subject: Time [was Re: Where are we?]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 01:13 PM 10/10/99 +0200, Harald Tveit Alvestrand wrote:
>At 11:57 10.10.99 +0100, Jack Lang wrote:
>>Harald:
>>
>>Unfortunately the slot has been delayed by ten minutes, as the
earlier news
>>program was extended.
>
>and in that case, the currently popular ShowView scheme breaks too.
>IMNSHO, the Right Thing to do, architecturally, is to establish two
>orthogonal name spaces:
>
>- TV transmission stream and time slot
>- Information content, such as "series episode" or "today's news"
>
>Then it's possible to build an association service that is able to
transmit
>things like:
>
> content://international.syndicates.com/TheLucyShow/Episode497/
will be
> transmitted on tv-
channel://bbc1.bbc.co.uk/19990422:2200+0000:30min
The binding of program to service is likely to be done outside of URI
scheme(s), as in the SI information of the transport. So having
pairs of URI's like this will not add to the object identification if
what you really want is the program (as opposed to the service at the
above times). I think these are unrelated, but independently useful,
schemes.
Also, as Jack pointed out, time is a very slippery animal, and the
above time usage, while not totally un-useful, is a hint at best. Is
the above in UTC or someone's local time? What final emission
station service does this identify? This is important since even
though BBC sent it out on its satellite at 2200 UTC, the broadcaster
had their favorite cooking show on at the time, and thus time-delayed
it for your local area, or perhaps dropped it entirely. So, this URI
says, at best, "if you receive BBC1 locally, you may find something
of interest at 2200 UTC".
>I think that's where we should end up; but since there's no
consensus (that
>I can hear) in this group that we should go straight there, we
should just
>make sure we don't block the possibility of ending up there.
>
>I think that's where we should end up; but since there's no
consensus (that
>I can hear) in this group that we should go straight there, we
should just
>make sure we don't block the possibility of ending up there.
I've always thought time may be useful, just not nearly as much as
everyone thinks.
Mike
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQA/AwUBOAH1sSl9dIG/haQGEQKmKwCffe0oap78z4MlK+D16YdQFX77XIgAoNVW
+zxqBx3oL6tRmQxO5G+x312w
=8uER
-----END PGP SIGNATURE-----
------------------------------------------------------
Michael A. Dolan, Representing DIRECTV, (619)445-9070
PO Box 1673 Alpine, CA 91903 FAX: (619)445-6122