- From: Jim Davis <jdavis@parc.xerox.com>
- Date: Mon, 12 Oct 1998 09:27:16 PDT
- To: WebDAV WG <w3c-dist-auth@w3.org>
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