W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1998

Re: Update to draft-ietf-webdav-dublin-core

From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
Date: Thu, 8 Oct 1998 15:23:51 -0400
Message-Id: <9810081923.AA13672@tantalum>
To: francis@netscape.com
Cc: w3c-dist-auth@w3.org, meta2@net.lut.ac.uk
   <geoff> The first is: Should there be an XML DTD for WebDAV properties?  I
   believe the answer is "yes", and not only should complex properties be
   describable in XML,

   <john> WebDAV properties are already represented in XML
   (when they go over the wire, at least

Yes, the prop XML element defined in section 11.11 ...

   <john> --there's an ongoing, nicely irrelevant, dispute over
   whether properties *are* XML :-).

I *think* the dispute was on the update protocol for this information
(which is a relevant dispute) rather than on the storage format of properties
on the server (which would be irrelevant in a protocol discussion).  I'll
admit that it was at times hard to tell ... (:-).

   <geoff> but an entire object, even a collection object,
   should have an XML representation.

   <john> What advantages would this representation have over the existing MIME
   representation?

It makes it easier to do incremental update in a simple uniform way.
Without the XML DTD for collections, it would not be feasible to use
an XML-based incremental update protocols for incremental update of
collections.  I'd guess the same is true for searching protocols, but
I'll let the DASL folks comment on that.

Let me re-emphasize that I'm not suggesting that we replace Mime with
XML, but rather that we define the appropriate set of XML elements so
that various XML-based protocols (such as incremental update and search)
can be applied to collections.

   <geoff> The second is: Should the only way to update a WebDAV object be by
   specifying the full XML description of the new object?

   <john> Incremental updates would be nice, but we don't need them in the base protocol,
   since they can be replaced (less efficiently) via a sequence of
   LOCK/PROPFIND/PROPPATCH/UNLOCK.

I'm not as concerned at what level of the protocol they are defined
(base or otherwise), as I am that they *are* defined, since
incremental update is needed for the protocol to be useful for large
collections.  And this leads to the desire to do incremental update
in a uniform fashion (similarly, for searching).

Cheers,
Geoff
Received on Thursday, 8 October 1998 15:23:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:48 GMT