- 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