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

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 01:33:16 UTC