- From: Larry Masinter <masinter@Adobe.COM>
- Date: Thu, 1 Feb 2001 00:48:34 -0500 (EST)
- To: <www-xml-packaging@w3.org>
- Cc: "Matt Paul" <mpaul@Adobe.COM>, "Jim King" <jking@Adobe.COM>, "jan stinchfield" <jstinchfield@home.com>
With regard to the 'catalog problem', I was pointed to where Multipart/Related doesn't help: > > > >http://www.w3.org/1999/07/xml-pkg234/Overview#collecting > >Bullet items 1 and 3 require a client-side decision to determine which > >components of a collection are needed. How does the client make this decision? A catalog of "needed components" for any document root sounds like an interesting thing to have, but (a) I think it might be a very hard thing to generate from existing content, in general (b) It's separable from the rest of the packaging issues I mean, you could deliver manifests which give lists of ("what other resources do you need to access before you can meaningfully render/process/index/search/<mumble> this document?") without ever packaging the resources together into a single bundle. And you can package together some subset of resource entities which may or may not be useful if you want to render/process/index/search/whatever the whole without ever having a manifest: the sender writes what the sender wants to write, and the receiver takes what it gets, without any negotiation. I'm not sure any of the other problems are as easily separable. Part of the problem with creating a 'catalog' is that there might be different catalogs for different purposes. If you're going to feed it all into a text-to-speech converter, maybe you don't need the CSS-for-printing. Larry
Received on Thursday, 1 February 2001 03:37:12 UTC