Re: structured documents [draft-hopmann-collection-props-00.txt]

"Slein, Judith A" wrote:

> multipart/related might be part of an implementation of compound documents
> -- the way to represent its content when you want to transport the whole
> compound document together -- but I doubt that it provides everything people
> will want.  For example, normally you expect to be able to operate both on

> the compound document as a whole and on each of its components individually.

But, for that, you can create a multipart/related whose body parts are stored
externally, using a message/external-body (or perhaps just a Content-Location:,
though that's apparently not part of MIME proper).

Advantages of doing structured documents as multipart/related instead of

   * There are obviously going to be types of structured documents;
     multipart/related already has a mechanism and namespace for specifying
     these types.
   * Given a multipart/related document with externall parts, there's an
     obvious way to serialize the document for transport.
   * Structural sharing: if two structured documents use the same image (for
     example), and the DAV server doesn't support references, then a
     collections-based approach requires that that image be copied, since
     there's no way for a client to tell the server to have it show up in both
     collections.  With a multipart/related approach, you just have both
     documents reference the same image.
   * Cross-server documents: with multipart/related, the external body parts
     can live anywhere on the Net (well, anywhere accessible to the client,
     anyway ;-).  With collections, this works only if the DAV server supports

(Mind you, I hope references will be pretty common; but, if we don't have to
depend on them, we shouldn't.)

|John Francis Stracke| |S/MIME & HTML OK|
|Xton, Mists, West   |NT's lack of reliability is only surpassed|
|My LAN, my opinions.| by its lack of scalability. -- John Kirch|

[This message was sent using an evaluation copy of
IMail Server for Windows NT, a product of Ipswitch, Inc.]

Received on Wednesday, 13 January 1999 11:33:16 UTC