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

At 1:04 PM -0400 10/8/98, John Stracke wrote:
>"David G. Durand" wrote:
>
>> 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.
>
>But this applies to any structured DAV property.  The DASL group has discussed
>the possibility of searching structured properties, and (as far as I can
>tell) has not given up yet (there's a proposal on the table from Alan,
>though I
>don't see any responses on the list).

Exactly. If there's a general searching mechanism that can solve this, it
could search a monolithic property as easily as a multiple-valued property.

I like Larry's arguments for separate properties for each DC item, but I
still worry about the multiple value problem, especially in conjunction
with nesting properties (since there may be multiple values at several
levels, flattening to a single level of properties still seems hard, and
error prone.
>But this will make things even less searchable, and much less manageable.
>
>> 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.
>
>What's wrong with defining <ol> in a property (or at least a Dublin Core
>property) to have the meaning we need?

Nothing in itself, it's just that choosing an unnatural name seems silly to
me. ol and li have widely accepted meanings, and I don't see that we get
very much by punning on the HTML tags.

>> 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.
>
>I disagree--the DAV server just sees them as separate dead properties; it
>doesn't
>have to know that there's any relationship among them.

>> This solve the property naming problem, but not the fact that we need a way
>> to synchronize several such values into a single creator.
>
>OK, here's your straight line: Why?
>

Any way that relationship is maintained it's going to be error prone to
determine how they relate: we can't assume, for example, that the various
sub-elements of a  multiply occurring item like Creator are even all
present, so if they are stored on separate properties we either need a way
to note how they correspond, or use explicit null values for any
unspecified properties, so that the various lists are all the same length.

Enforcing this kind of parallel list structure across multiple properties
seems very clumsy as a client-managed operation (they must all be locked to
make an update), and hard to implement on the server side.


Example:

<creator><firstname>Joe</firstname></creator>
<creator><lastname>Botticelli</lastname></creator>

This two-creator set of names does not flatten well, as we get (naively)
the following properties:

creator.firstname = <ol><li>joe</li></ol>
creator.lastname = <ol><li>Botticelli</li></ol>

but there is not 1 creator "Joe Botticelli"

So we can go instead for something like this:

creator.firstname = <ol><li>joe</li><li></li></ol>
creator.lastname = <ol><li></li><li>Botticelli</li></ol>

any update to any creator tag must lock and update all properties of the
form creator.*

or we could have:

creator = <creator><value><firstname>joe</firstname></value>
                   <value><lastname>Botticelli</lastname></value></creator>

This of course, is just 1 step flatter than putting the whole DC thing on
one property. For simple seraching this might be worth it, but I think that
any further flattening of a hierarchy is going to be vary hard to make work
in a flat namespace like DAV properties.

In anything that works well for hierarchically nested items, some search
smarts are going to be needed for effective retrieval. So I think that the
best idea may still be putting the whole meta-description in one property,
or splitting only the top level.

In other words, I am sensitive to the notion of why splitting the
properties makes some sense, but I'm not convinced that it will work very
well.

   -- 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 Friday, 9 October 1998 23:30:40 UTC