- From: Gavin Thomas Nicol <gtn@ebt.com>
- Date: Thu, 1 Feb 2001 10:10:46 -0500
- To: "Larry Masinter" <masinter@Adobe.COM>, <www-xml-packaging@w3.org>
- Cc: "Matt Paul" <mpaul@Adobe.COM>, "Jim King" <jking@Adobe.COM>, "jan stinchfield" <jstinchfield@home.com>
> 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.
In actual fact, this is one of the primary benefits. In the catalog
scenario (and this has been tested with running metamail code), you
get:
1) The ability to send some, or part of the entire set of
content.
2) The ability to analyze the packing list so that the processor
can determine which components are needed or not.
3) Somewhat similar to this is the ability to analyze the packing
list for security holes, and prompt a user.
4) The ability to, without parsing *all* the content, determine what
the minimal packaging set is.
5) URL aliasing so you don't have to rewrite the content (like
HTML mail requires for CID references) in order to resolve
references to packaged content.
6) Packaging *format* independence. The catalog will work in
multipart/related, plain multipart, or even in an XML syntax.
Logically, as you not, the catalog is independent of the packaging
scheme. Practically, you need a catalog in order to really use a
packaging scheme... in leiu of an explicit catalog, you create
one implicitly through the references.
As I said, this has been tested using metamail. A fair while ago
I prototyped an system for packing and unpacking SGML documents into
multipart/related mail.
Received on Thursday, 1 February 2001 10:05:12 UTC