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

At 08:38 PM 10/9/98 PDT, David G. Durand wrote:
>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.

True, search is no harder, but updates are far worse:
 1. The client has to send the entire property just to change one piece of
a field.  This is a nuisance.
 2. It is impossible to enforce selective access to fields.  This is terrible.

As I see it, there are three proposals:
 1. monolithic.
 2. structured properties (e.g. list values)
 3. flattened.

Monolithic is bad for the reasons I just explained.  "flattened" was
proposed (I suppose) in case DASL did not have structured query, but it
will, so there's no need for it (and besides, as David points out, it's a
nuisance to manage.)

Proposal 2 is convenient, natural, and has no disadvantages.  

Other than the choice of names for the separator tags (you don't like
re-using li), what's the problem with, e.g.

<creator>
 <li><person>Kenneth Starr</person></li>
 <li><person>Ringo Starr</person></li>
 <li><person>Brenda Starr</person></li>
</creator>

This approach allows one to distinguish corporate authors from human beings
by using <person> vs. <corporation>

It allows one to express sub-structure of the person name, if known

<creator>
 <li><person><lname>Starr</lname><fname>Kenneth</fname></person></li>
 <li><person><lname>Starr</lname><fname>Ringo</fname></person></li>
</creator>

It allows one to add new tags in the future, if need be:

<creator>
 <li><person>Doug Lenat</person></li>
 <li><program>Cyc</program></li>
</creator>

Note that I'm treating creator as implicitly a list holder, so no <ol> is
needed.  That way I can require that the immediate contents are only <li>,
even for single element lists, thus:

<creator>
 <li>Kronos</li>
</creator>

never

<creator>Kronos</creator>

This is because these two are structurally different.  I would only want to
have to support one, and since the explicitly structured one (with the li)
is more general, that's the one to prefer.

Lest there be doubt on the point,
<lname>Starr</lname><fname>Kenneth</fname> is structurally different from
"Kenneth Starr" too, but this reflects a difference  in knowledge.  The
former makes a definite assertion about the creator's last name, but the
latter doesn't.  I see plenty of names on the net where I don't know which
is fname and which is lname (e.g. when dealing with non-European names)

Finally, if hierarchically qualified tag names are needed, e.g. to
distinguish a corporate author from a person author, these should be
expressed by nesting, not by compound names, because nested names preserve
the semantic "kind of" relation, but names themselves are opaque.  That is,
a nested tag like
 <person><pseudonym>Mark Twain</pseudonym></person>
can be used by a program that does not know about the distinction between a
pseudonym and any other name a person might have, but a tag like
 <person.pseudonym>Mark Twain</person.pseudonym>
conveys no such information.

Received on Monday, 12 October 1998 12:38:09 UTC