- From: Warner ten Kate <tenkate@natlab.research.philips.com>
- Date: Mon, 23 Nov 1998 18:33:14 +0100
- To: Henning Timcke <henning.timcke@werft22.com>
- Cc: www-tv <www-tv@w3.org>
Henning Timcke wrote: > What is your answer to the URL's on tape ? I have some difficulty in understanding your questions. I also wonder where URIs come into play. If you have proposals, please, come forward. > Okay, please tell me more: > store locally on tape ? > How will the extra-information be stored that tells at what time on the tape the URL is ? > Do you intend to use diffrent methods as in HTTP ? When saying 'what time on the tape' are you referring to the physical position on that tape ? I suppose the same concepts and mechanisms can be used as when referencing content on a tape or in a Broadcast stream, Particularly, when the tape uses the broadcast format as "file system" (e.g., MPEG TS). It is up to the tape device design how to arrange (fast) access across a tape. Possibly, the tape is arranged with additional information to assist the driver. Anyhow, that seems to me outside the scope of the URI. To keep this focus I think it helps if we talk in terms of storage devices. > I propose to use XML to handle the hooks neccessary. I am not sure I understand what you suggest here. What hooks ? And how would you use XML ? I assume you mean to use XML for specifying the application language. That also seems outside our current scope of discussing URIs. > Time Code could be used as is and another *Time* Code should be developed: > topology relevant time for download. I do not understand this phrase: What 'Time code' are you referring to? For what and how could it be used 'as is' ? What is the other ' *Time* Code ' What do you mean by 'topology relevant time' ? What topology are you referring to ? (position on tape ?) Before answering all this, can you think of what the consequences are for URIs: are we missing a requirement ? Warner.
Received on Monday, 23 November 1998 12:33:22 UTC