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

"Geoffrey M. Clemm" wrote (6 weeks ago, sorry--I've been busy with a new job here--so
I'll include the whole message for context):

>    From: John Stracke <francis@appoint.net>
>
>    "Geoffrey M. Clemm" wrote:
>
>    > Given that WebDAV already makes significant use of XML, I would propose
>    > that using XML as the compound document format should be the default choice
>    > unless proven deficient for that purpose.
>
>    Hmm.  Does there already exist an XML DTD for compound documents?
>
> XML provides the mechanisms for specifying "immediate" data and references
> to other resources.  A DTD just specifies a particular type of
> compound document (or at least, specifies its syntax).

>  Providing
> a MIME namespace and DTD's to support interoperability between MIME and
> XML would be fine, but that's very different from using MIME as the
> structured document format for WebDAV.
>
>    > I realize that emveryone has their favorite alternative to XML (and MIME
>    > certainly has its advantages), but it's rather late in the game to switch
>    > from XML to MIME, and depending on both XML *and* some other structured
>    > document format (such as MIME) is a complexity I'd prefer to avoid if at
>    > all possible.
>
>    We already depend on MIME at least a little bit, because we're based on HTTP.
>
> Can you be more specific?  I don't remember ever feeling the need to read
> any MIME spec to understand some part of WebDAV (and I read a *large*
> number of specs during my recusive descent into WebDAV-world :-).

Every HTTP entity body is a MIME object.  This means that the body of any ordinary DAV
resource (non-collection, non-reference) has to be expressed in some way that fits into
MIME.

>    My feeling is that, while XML is a good format for single documents, there is no
>    good reason to use it to duplicate the MIME mechanisms.
>
> A good reason would be if XML already provides the required MIME
> functionality, and is already an explicit and widely used component of
> WebDAV, then the spec is needlessly complicated by introducing MIME.
>
>     MIME is more widely
>     deployed, understood, and supported; and it already does what we want.
>
> There are many things that are widely deployed, understood, and supported
> than XML (and certainly than WebDAV), but selecting an additional redundant
> format just because it is widely deployed is a major step against
> interoperability.

Except that (I assert) it's already deployed in the DAV implementations.

>   Plus, as a
>    (blech) political point, any working group that attempts to reimplement MIME is
>    going to face objections from the IETF community, asking why they didn't stick
>    with the protocol that was already there.
>
> We are sticking with a protocol that was already there ... it's just that
> it is XML, and not MIME.  So I need to see a convincing argument
> that MIME provides essential functionality not already provided by XML.
>
> To emphasize, I'm not saying there is no such argument that could be
> made -- it's just that I haven't seen it, and I subscribe strongly to the
> "keep it out of the spec until proven necessary" philosophy.

OK, so here's my argument:

Every document (ordinary resource) that DAV can manage can be expressed as a MIME
object.  The MIME multipart syntax provides a mechanism for aggregating MIME objects in
various ways (multipart/mixed for an array, multipart/alternative for a union,
multipart/related for a struct).  So, if we adopt MIME multiparts as our compound
document format, our compound documents will be able to contain any sort of document
that DAV can handle.  On the other hand, if we use XML, then the only documents that
can be contained (inline) will be documents which have an XML encoding.  Maybe we can
come up with a universal encoding (stick in the body of the object as a CDATA), but it
will need to be able to express any Content-* header on the MIME object, which means
that it's essentially tunneling MIME inside of XML.  (<looks expectantly at Yaron, the
declared enemy of tunneling> ;-)

(I believe that inline is essential because I think an important type of compound
document is going to be a collection: to populate a collection, do a MKCOL with a
compound document that represents a collection.)

>    (And God help any working group that
>    reimplements MIME and omits an obscure feature in a subclause in RFC 31415926536.
>    :-)

(Clarification: I'm not saying that a DAV server or client would have to implement all
these features; I'm just saying that the *spec* should have them, or it's not going to
be accepted as a replacement for MIME.)

> Which illustrates why I would resist seeing MIME as a required part of the
> WebDAV spec (:-).

Yeah, but I'm not sure it's really a problem.  A DAV structured document syntax would
probably be done by defining a particular MIME type (say, application/dav) which gets
placed into a multipart/related and points to other MIME objects (either parts of the
multipart, or external resources).  All the DAV server has to understand is the
application/dav syntax.  We can even specify that particular MIME features are not
mandatory (for example, non-URI-based external-body specifiers).

--
/=============================================================\
|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