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

[please note - beyond what one can set in a browser, my experience with mime
types ends with 'text/xml'.]

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


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, 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". 

>    * 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.

>    * 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. which i would take to mean that
uri's suffice - which i would expect any http-capable server to support... ?

Received on Thursday, 14 January 1999 15:48:13 UTC