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

I believe there are three related questions being discussed in this
thread.

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, but an entire object, even a collection object,
should have an XML representation.  This of course does not imply
that this is how a server should implement a WebDAV object, but just that
it be describeable as such.

The second is: Should the only way to update a WebDAV object be by
specifying the full XML description of the new object?  I believe the
answer is "no", and that there must be methods in the protocol for
incremental update (I think that's the essence of Larry's point,
although I probably would have avoided the terms "ugly" and "awkward",
as bordering on ad hominem :-).

The third is: what should that incremental update protocol look like?
I believe that the answer to this question should be a general
protocol for incremental update of XML documents.  So even if for
expediency, we define special purpose "incremental update" protocols
for WebDAV objects, we should have the general case in mind, with the
intention of eventual unification.

Cheers,
Geoff

   From: "Larry Masinter" <masinter@parc.xerox.com>

   I don't like your conclusion to have a 'single property', since
   the separate properties of Dublin core are themselves quite reasonably
   mapped to independent repository properties, and the implementation
   which maps multiple repository properties to a single DAV property will
   be ugly, awkward, and slow. Updates will be especially awkward; the
   client, to update the 'author', would have to read the entire
   metadata set, modify it, and write the entire set back.

   It seems, rather, that the WebDAV property model should acknowledge
   the possibility that property values are structured (or not), and that
   the structure can be simple (ordered or unordered list) or more complex
   (elements and subelements).

   I believe that WebDAV and Dublin Core need each other: one cannot
   succeed without the other. WebDAV without a common framework for
   document attributes will be unworkable, and Dublin Core without
   authoring tools will have significantly weaker deployment.

   If making these two things work together requires some recasting of
   WebDAV property structure and/or Dublin Core structures, so be it.

   As far as the design choices go, my personal opinions are:

   a) WebDAV needs to support multiple values for some properties.
      This will make clients more complex, but it seems unavoidable.
      If a property *can* be multivalued, then it probably should be
      always returned as multi-valued.

   b) bytes on the wire matter. <ol><li> are shorter than <value>.
      This might not be the case for general XML, but these attributes
      are supposed to be short. And at this point, <ol><li> are
      as meaningful as <value>.

   > >As of this writing, the Dublin Core group is debating how and whether
   > >to provide subelements (that is, a technique for structuring metadata
   > >elements).  Since subelements are not yet standardized, this document
   > >cannot yet give a definitive answer on how to integrate them into
   > >WebDAV; a future document may be needed.

   If WebDAV has some requirements for how Dublin Core defines subelements,
   it might actually help focus the Dublin Core debate by providing
   a criteria other than esthetics for making one design choice over another.

   > >One approach under consideration, set out in [GUENTHER], is to use
   > >structured element names (e.g., Creator becomes structured into
   > >Creator.PersonalName and Creator.CorporateName); if this approach is
   > >adopted, then this document can be applied unchanged, because
   > >Creator.CorporateName is a perfectly legal XML tag name.  Alternative
   > >approaches could include storing structured data in an element; this
   > >approach would require a future document specifying a mapping from
   > >that structure into XML.
   > 
   > This solve the property naming problem, but not the fact that we need a way
   > to synchronize several such values into a single creator. Never mind that
   > creators will not have defined values for each property, making it even
   > harder to cope with.

   Harder, but not impossible. The other alternative is to have structured
   values themselves, just as <ol><li></li><li></li></ol> would be structured.

Received on Thursday, 8 October 1998 09:11:45 UTC