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

james anderson wrote:

> while  i won't assert, given a cursory reading of rfc 1521, that multipart is
> obsolete, i wouldn't deny it either.

I would certainly deny it.  RFC1521 is six years old; it was replaced by RFCs
2045-2049 three years ago.  Multipart/related was updated just last August
(RFC2387); multipart/form-data was defined in RFC2388.  MIME objects can be signed
and encrypted (S/MIME [RFC1847] and the upcoming PGPMIME).

> John Stracke wrote:
> >
> >
> > Advantages of doing structured documents as multipart/related instead of
> > collections:
> >
> >    * There are obviously going to be types of structured documents;
> >      multipart/related already has a mechanism and namespace for specifying
> >      these types.
>
> as does xml - dtd's - or whatever schema form follows on. xml has the
> disadvantage that it does not permit inline encoding variations,

I believe this is a crippling disadvantage; if you want to publish a compound
document, encoding everything inline is really useful, because it means that people
can download a single resource and know they got the whole thing.

> but it does
> permit references to arbitrary external encodings (including those covered by
> mime types) and it does offer better means to discover document structure.
>
> >    * Given a multipart/related document with external parts, there's an
> >      obvious way to serialize the document for transport.
>
> xml is incomplete in this regard, but only in the sense the the possible
> semantics of links is not yet "ratified".

I think I'm missing something; above, you say that XML doesn't permit inline
encoding variations.  Serializing the compound requires the ability to include
components inline.

> >    * 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.
>
> wouldn't href="..." or imgsrc="..." accomplish the same thing.

Then why have a compound document at all? Why not just use XML?

> >    * 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
> >      references.
>
> i have to look back at the webdav spec for this....
> i'm not sure what the issue is in this paragraph. "reference" does not appear
> to be a special term w.r.t dav collections.

See the advanced collections work.

> which i would take to mean that
> uri's suffice - which i would expect any http-capable server to support... ?

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
|francis@ecal.com|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal, Inc.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

Received on Wednesday, 3 March 1999 09:03:37 UTC