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

I think that addressing nested properties weakens the proposal from the
original, and that the possibility that they will be used actually makes
the basic approach less plausible.


>2.2 Property Names
>
>A WebDAV property representing a Dublin Core element has the same name
>as the Dublin Core element label.

This _seems_ good.

>2.3 Property Format
>
>Since a WebDAV property can occur on a resource only once, while a
>content item may bear more than one instance of a Dublin Core element,
>some mechanism is needed to represent the multivalued elements in the
>singlevalued property syntax.

This is the kicker however... I'm not up to speed on DASL, but let me lay
out the implications as I see them.

If DASL can express queries on the XML content within a property, then
queries like:

find Author name="Lord Dimwit Flathead"

will work, because we can turn them into something like:

find DUBLIN:Creator containing <li>="Lord Dimwit Flathead"

If it supports no such feature, we have already lost searchability of
multiple valued Dublin attributes anyway, since only signle values will be
effectively searchable at the server end.

The alternative is to have a single property: DAV:DublinMetadata that
contains the entire XML representation of the meta-data. That will, I am
pretty sure, be defined eventually by the Dublin core folks, and we simply
need to reserve the attribute, and describe its purpose.

This also means that we will probably be able to leverage the XML Query
language  to help solve this problem, once it and the Dublin core DTD are
done.

>  Since WebDAV properties are expressed
>in XML, there is a simple mechanism available: an ordered list
>element, where each list item corresponds to an element.  For example,
>the Creator elements of [DUBLIN] might be expressed as follows:

This is actually rather unpleasant: the use of ordered list tags from
another DTD to indicate multiple values is a pretty serious case of tag
abuse. If we need multiple values, and stay within this kind of apporoach,
let's use the power XML gives us and define a meaningful tag, rather than
implying that we're using HTML (which we're not), and ignoring an
opportunity to use meaningful names.

I'd prefer something like:

<DUBLIN:Creator xmlns:DUBLIN="SomeURI">
  <value>S. Weibel, OCLC Online Computer Library Center, Inc.</value>
  <value>J. Kunze, University of California, San Francisco</value>
  <value>C. Lagoze, Cornell University</value>
  <value>M. Wolf, Reuters Limited</value>
</DUBLIN:Creator>


><DUBLIN:Creator>
> <ol>
>  <li>S. Weibel, OCLC Online Computer Library Center, Inc.</li>
>  <li>J. Kunze, University of California, San Francisco</li>
>  <li>C. Lagoze, Cornell University</li>
>  <li>M. Wolf, Reuters Limited</li>
> </ol>
></DUBLIN:Creator>
>
>(assuming that a namespace declaration PI has appeared to define
>DUBLIN: to refer to the Dublin Core namespace.)

A namespace declaration needs to be part of the property, and so should
appear in the example.

>2.4 Subelements
>
>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 this happens, the multiple value problem gets a lot worse: for 3
creators, there will need to be six values, if each creator has two
attributes. We either start having to store structured values anyway (in
which case straight XML from the beginning is probably a better approach),
or we start needing to store parallel synchronized lists in different
properties, which is a pain for clients, and harder for servers (and pretty
much requires a big implementation, as it won't work with simple dead
property storage, which seems pretty bad to me.

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

It seems to me that we need one property to hold an XML description of
Dublin meta-data, according to a DTD that they will write. We can't solve
the rest of the problem here.


  -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Wednesday, 7 October 1998 09:39:57 UTC