- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Tue, 16 Feb 1999 22:33:31 PST
- To: "Michael A. Dolan" <miked@tbt.com>, "Warner ten Kate" <tenkate@natlab.research.philips.com>
- Cc: <www-tv@w3.org>, "Roy Fielding" <fielding@ics.uci.edu>
> I am trying to (after the fact) work on coming up with an acceptable > definition of tv:. It has limited function, but it has proven very useful > in practice. I misunderstood the question. I thought you were trying to design something that would actually work well, starting with the existing definition of 'tv:'. It sounds like you just want to describe what you have. I think you can do that, and the best thing to do is to describe its limitations and shortcomings, rather than to make up some reason why it's really great as is. > If the tv: syntax is that hopelessly offensive to everyone, I will stop > trying to defend it. But that doesn't make it go away. It is in current > public practice, and its use will grow a lot over the next year - well > before any other transport-independent scheme I know of is > deployed publicly. It's not "offensive", it just doesn't work very well. It would be useful to define something else that would work better -- e.g., be well-defined in the context of a system with more than one TV tuner, for example, or for documents that were saved from TV onto a PC's disk. But that's not what you have. > So, I think it is, in fact, a valuable exercise to try to define it in > terms that might be acceptable to everyone in *some* context. My > assumption is that this list is the right forum for that discussion (even > though I was *not* the person who initiated this thread). It would be acceptable if you included in the description of "tv:" all of the ways that it fails to behave as well as most other kinds of URLs. There are other URL schemes that have problems, too, so... that's OK. Just don't write it up in a way that would encourage other URL designers to copy it. "news:" has problems, for example, in that its meaning depends a lot on the context from which it is invoked, and the configuration of the user that invoked it. (That's one of the reasons why "news:" isn't used much.) > FYI, I took a definitional tact (URN) that was not in fact the original > author's intent for tv: in the hopes that there was *some* definition that > was clear and acceptable to everyone. I don't think the URN tack is helpful. > Else it is relegated to an "informational" (RFC). Probably that is the _best_ way to publish the definition, though. > But such an outcome is not in the best interest of > the users of tv: as it will remain open to endless debate and some > interpretation (especially if its context is ill-defined). And, > not having it standardized makes referencing the tv: URI > problematic for certain other standards bodies. I personally think that the best interest of the users of "tv:" would be to define a different kind of referencing mechanism that didn't have so many operational problems. Since you don't want to do that -- you want to leave "tv:" as meaning what the current users of "tv:" use it for -- then you're stuck with second best. Publishing a definition of "tv:" as an Informational RFC doesn't leave it open to endless debate or interpretation -- unless the document is poorly written. And I'm dubious about the assertion that other standards bodies can't possibly reference "informational" RFCs. You might even be able to get away with standards-track in IETF; I don't know. At a minimum, I think you'd have to do a better job of dealing with the technical ambiguities of the meaning of "tv:" outside of the context of a particular mode of transmission, and that seems difficult to me. > I would *love* to continue the bigger TV object naming > discussion, and have given the subject a *lot* of thought. > But I would (independently) like to close on defining tv: > for the reasons stated above. > So, in summary of where I think we are is that we have > established that to put live TV in an HTML page, you need > a URI scheme(s) (or at least noone objected to Werner and > my premise statements to this). Oh! No, I think that's nonsense. Of course you don't need a separate URI scheme. I gave you several counter-proposals, for that matter; a URI that referenced the context of transmission that was independent of "tv:", a MIME type which was invoked either by a HTTP URL or even a "data:" URL, etc. > If you believe that tv: is useful, Sure, it's useful > and will continue to be used no matter what, No, certainly not "no matter what". If you defined something better, and convinced current content authors and implementors that it was better, you could migrate away from "tv:" to a newer method. > and that it should be well-defined as soon as possible > by experts, If it _can_ be well-defined while retaining backward compatibility. Your arguments about continuing to use "tv:" have to do with the current installed base. So you can't actually change it in ways that are incompatible with the installed base and retain any advantage. > then the primary question is: can we specify tv: in > *some* manner that is well-defined within the requirements > of a URI. What if the answer is "no"? > I solicit your expert help on this specific task. > > Mike > > At 09:54 AM 2/14/99 PST, Larry Masinter wrote: > >The questions of "what is a URN" or "what is a URL" tend to > >lean away from engineering and toward philosophy or even > >religion. > > > >I suggest a different approach. Imagine, for a moment, the > >possibility that an author might want to create content > >which is intended to be delivered MORE THAN ONE WAY. That > >is, not JUST by 'tv', but, say, the same content delivered > >EITHER by 'tv' OR via HTTP on a (forfend) regular old PC. > > > >But what would a regular old PC do with this "tv" URL? > >Clearly it doesn't mean "turn on the TV now and watch it". > >There's some other semantics that is actually wanted; > >you're invoking some image which is inherited from the > >context, I suppose. I'm not entirely sure. > > > >I urge you to think out of the box and come up with > >a design that's actually useful in multiple contexts. > >Sometimes you get boxed in by imagining a world in which > >everyone is just watching interacting with web pages > >while watching their TV. > > > >But people don't just watch the web. They save it, store it, > >forward it, mail it, put it in databases, search it. > >How could you design something that would work in all > >those other scenarios, at least as well as today's > >'best practice' URL uses? Don't create a design that's > >_only_ useful for "www-tv". > > > >Larry > ------------------------------------------------------------------ > 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 Wednesday, 17 February 1999 01:33:41 UTC